'dotnet lambda package' throws 'ArgumentNullException' when running for a project with multiple target frameworks
See original GitHub issueDescription
When running dotnet lambda package
for a csproj that has multitargetting enabled, a ArgumentNullException
exception is throw and the process crashes.
Specifying the -f
cmdline option with either netcoreapp3.1
or net5.0
works as expected.
I’d expect either it to work seamlessly, or to return a proper message saying that the target framework needs to be specified.
Reproduction Steps
- Create an API lambda project targeting Net Core 3.1 and Net 5.0
Section of csproj:
<TargetFrameworks>netcoreapp3.1;net5.0</TargetFrameworks>
- Run
dotnet lambda package
in the projects folder - Observe exception is quickly thrown
Logs
Amazon Lambda Tools for .NET Core applications (5.0.0) Project Home: https://github.com/aws/aws-extensions-for-dotnet-cli, https://github.com/aws/aws-lambda-dotnet
Unknown error executing command: Value cannot be null. Parameter name: paths at System.IO.Path.Combine(String[] paths) at Amazon.Lambda.Tools.LambdaPackager.CreateApplicationBundle(LambdaToolsDefaults defaults, IToolLogger logger, String workingDirectory, String projectLocation, String configuration, String targetFramework, String msbuildParameters, Boolean disableVersionCheck, LayerPackageInfo layerPackageInfo, String& publishLocation, String& zipArchivePath) in C:\codebuild\tmp\output\src845572623\src\src\Amazon.Lambda.Tools\LambdaPackager.cs:line 76 at Amazon.Lambda.Tools.Commands.PackageCommand.PerformActionAsync() at Amazon.Common.DotNetCli.Tools.Commands.BaseCommand`1.ExecuteAsync() in C:\codebuild\tmp\output\src845572623\src\src\Amazon.Common.DotNetCli.Tools\Commands\BaseCommand.cs:line 46
Environment
- OS Info: Windows 10
- Build Environment: Visual Studio 16.8.2 Developer Command Prompt, Amazon.Lambda.Tools 5.0.0
- Targeted .NET Platform: netcoreapp3.1 and net5.0
Resolution
- 👋 I can/would-like-to implement a fix for this problem myself
This is a 🐛 bug-report
Issue Analytics
- State:
- Created 3 years ago
- Comments:8 (5 by maintainers)
Top GitHub Comments
Hi @julealgon,
Good morning.
I had discussion with the development team and based on their findings, it would not be a simple change in the error message. The code is shared and refactoring it for the error message to include additional checks would impact the overall design and would not be feasible. While I cannot provide the specific details, but it’s good that exception is not thrown anymore for the mentioned scenario. Hence, closing this issue.
Thanks, Ashish
Pull request out for prompting the user if tool doesn’t figure out the target framework. https://github.com/aws/aws-extensions-for-dotnet-cli/pull/151