Directory.build.props heirarchy is not respected

[toddlang]

Describe the bug

When packaging a lambda using dotnet lambda package, if the target project does not include a <TargetFramework> node (because it is defined in a Directory.build.props at a higher location) the packaging tool fails saying it does not know what framework to use.

Missing required parameter: --framework

Expected Behavior

The tool will understand that MSBuild can walk directories searching for Directory.build.props files to define these values.

Current Behavior

The tool fails to walk the folder heirarchy to find the values necessary for the build.

Reproduction Steps

Create a csproj file for a lambda without <TargetFramework>. In a directory higher (say, next to your sln file) define a 'Directory.build.props' file and add a <TargetFramework> node there.

This behaviour is all defined here: https://docs.microsoft.com/en-us/visualstudio/msbuild/customize-your-build?view=vs-2022

Possible Solution

No response

Additional Information/Context

No response

AWS .NET SDK and/or Package version used

dotnet lambda tools 5.3.0

Targeted .NET Platform

.Net 6

Operating System and version

Windows 10

[paul-michalik]

In connection with AWS SAM this is even worse. If you set for example your directories for temporary and binary directories, or the language version on global level via Directory.build.props then this is ignored by AWS SAM and by dotnet lambda commands.

[chrisoverzero]

This is something I've tackled in #183.

[ashovlin]

Small note: we explored using the new dotnet msbuild -getProperty that was introduced in 17.8 (8.0.1) to detect the target framework in our Lambda Annotations library. We ended up taking a different approach since we were inside a source generator and can access the TFM that way, but linking the abandoned code here in case it's useful.

Here's the commit for reference: https://github.com/aws/aws-lambda-dotnet/pull/1658/commits/357bf9963cb88081e22ff4cb409eac9a7a15cd6e