Why can't 'dotnet lambda deploy-function' pull a package from an Azure DevOps artifact feed?

Question

I'm using the AWS deploy lambda task within Azure DevOps. Within the lambda function that gets deployed, it's setup to pull a package from an artifact feed within the same Azure DevOps repo/installation.

If I run NuGet restore in a previous step to the deploy then the package can be accessed fine however when it then hits the AWS Lambda .NET Core Deployment step it gets a 401 when trying to read from the same feed.

Does anyone know how I could configure the lambda release step to successfully read from a custom feed?

The specific error is:

Response status code does not indicate success: 401

Answer 1

I am having the same issue but hopefully I can offer a bit of a new angle on it.

Rather than using the AWS deploy lambda run we are packaging our lambdas and pushing them to S3 to allow CloudFormation to deploy them. This uses the AWS dotnet toolkit to construct the deployment package (which is what aws deploy lambda is doing in the background). The powershell step that performs this then looks like:

dotnet lambda package

The resultant package will then typically be generated inside of the bin/release folder beneath your project.

What this then lets you do is add the parameters --msbuild-parameters "--no-restore" to the packaging process which will not trigger the automatic restore step. Inside of Azure DevOps Build Pipelines you can set a build step before it to restore for all solutions or csproj files which will authenticate against your feed automatically. We also set the version number of the asssemblies and I wanted to get rid of an annoying warning so our current version of this call looks like:

dotnet lambda package ("/p:Version=" + $VersionNumber) "/p:PreserveCompilationContext=false" --msbuild-parameters "--no-restore"

The problem that I am now running into is that passing in the msbuild-parameters seems to set the framework to target red hat linux (rhel.7.2-x64) resulting in the following error:

publish: C:\Program Files\dotnet\sdk\2.1.500\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets(198,5): error NETSDK1047: Assets file 'C:\Agent\_work\1\s\Kiosk.Microservice.User.Lambda.Command\obj\project.assets.json' doesn't have a target for '.NETCoreApp,Version=v2.0/rhel.7.2-x64'. Ensure that restore has run and that you have included 'netcoreapp2.0' in the TargetFrameworks for your project. You may also need to include 'rhel.7.2-x64' in your project's RuntimeIdentifiers. [C:\Agent\_work\1\s\Kiosk.Microservice.User.Lambda.Command\Kiosk.Microservice.User.Lambda.Command.csproj]

I very explicitly want it to build for dotnetcore2.0 so I don't actually want to build for red hat linux.

This is where I am currently stuck as if I don't use the flag to stop the unauthenticated nuget restore step, I get the unauthorized error and I can't seem to pass dotnet.exe my feed credentials. If I do use the flag it builds for red hat Linux for no coherent reason. Hopefully this gets you at least a little farther!

Update: I now have my stuff working. I went and found the dotnet cli wrapper that dotnet lambda publish is actually using in the git repository for the toolset and duplicated its steps without the middleman. Because the msbuild-parameters flag was no longer used it didn't try to build it in red hat linux. I did also have to create the zip file afterwards as well but that is fairly trivial. The following is the powershell that is generating the new packages without the aws dotnet toolset:

# Run the build that will generate the proper files
dotnet publish --no-restore -f netcoreapp2.0 -c Release

# Create the path to the zip file
$PathToZip = $PathToCSProj + "\bin\Release\netcoreapp2.0\publish"

# Create the zip file
Compress-Archive -Path $PathToZip -DestinationPath ($PathToZip + $csproj[0].Name.trim(".csproj") + ".zip")

I hope this helps!