LambdaException: Could not find the required '*.deps.json' from functions in different assembly

[zahycs]

I'm facing an issue organizing handlers/functions in several projects and having one serverless template project, this is the project that we will deploy, projects are organized as following :

• AWS Serverless Application (project1), this project contains the serverless.yaml with several handlers, handlers exist in different projects.
• 4 Class libraries projects (Lib1.. Lib4 ), every project contains 1 or more functions.

the Package created and uploaded to S3 bucket contains all assemblies (lib1..Lib4, and project1) but only one deps.json file : Project1.deps.json

Invoking any function from any of the referenced assemblies ( lib1.. lib4) throws :
{ "errorType": "LambdaException", "errorMessage": "Could not find the required 'lib1.deps.json'. This file should be present at the root of the deployment package." }

Is there a solution to such situation? adding all functions in one project is something we can't afford as it will be very difficult to maintain

[vellozzi]

You might be able to copy the deps.json file once for each assembly and name the copy accordingly. It's something you'd have to do manually once you have the deployment zip though.

I have some ideas on how that can be solved. But I need to see if it's feasible and schedule the work. Let me look into it.

In the meantime, let me know if that workaround is doable.

[zahycs]

@vellozzi thank you , yes it's indeed doable , we needed also to include *.runtimeconfig.json for each assembly.
another workaround is to add all lambdaEntry.cs to your main assembly and configure your endpoints/proxy functions in serverless.template to point to the main assembly.

Here is a powershell script to apply the workaround suggested by @vellozzi

############################################################
$PackageName = 'MyApp.Services.ApiGateway.zip' # your main assembly package name
$GatewayDeps = 'MyApp.Services.ApiGateway.deps.json';
$GatewayRuntimeConfig='MyApp.Services.ApiGateway.runtimeconfig.json';
$ExpandDestination= 'unzipped';
$TargetAssembliesFilter={$.name -like "MyApp.Services.*" };

Write-Host Expanding package $PackageName to folder $ExpandDestination
Expand-Archive -Path $PackageName -DestinationPath $ExpandDestination

$serviceAssemblies = Get-ChildItem -Path $ExpandDestination -Recurse -Include *.dll | Where-Object $TargetAssembliesFilter

foreach ($element in $serviceAssemblies) {
Write-Host copying deps.json and runtimeconfig.json for assembly $element.Name
# Copy deps.json for current assembly
Copy-Item "$($ExpandDestination)$($GatewayDeps)" -Destination "$($ExpandDestination)$($element.Name.Substring(0,$element.Name.IndexOf(".dll"))).deps.json";

 # Copy deps.json for current assembly 
 Copy-Item "$($ExpandDestination)\$($GatewayRuntimeConfig)"  -Destination "$($ExpandDestination)\$($element.Name.Substring(0,$element.Name.IndexOf(".dll"))).runtimeconfig.json";

}

If(Test-path $PackageName) {Remove-item $PackageName}
$location = Get-Location;

Add-Type -assembly "system.io.compression.filesystem"
Write-Host "Zipping $($location)$($ExpandDestination) to $($location)$($PackageName)"
[io.compression.zipfile]::CreateFromDirectory("$($location)$($ExpandDestination)", "$($location)$($PackageName)",1,0)**
###################################################################

[normj]

With version 3.1.0 of Amazon.Lambda.Tools, the dotnet lambda command, it has been updated so that during deployment you could upload your projects individually which could help avoid this issue.

In your serverless-template for each AWS::Serverless::Function or AWS::Lambda::Function you can set the CodeUri or S3Key to the different projects for each Lambda function and the dotnet lambda deploy-serverless command will take care of uploading each project individually with their own deps.json file.

The AWS Toolkit for Visual Studio hasn't been updated yet with this code so for now you will need to do the deployment from the commandline.

[vellozzi]

This week we deployed a fallback mechanism to help with this situation.

Before the fix, if your handler was Assembly::Namespace.Class::Function AWS Lmabda would require a file named Assembly.deps.json to be present in your deployment package.
After the fix that was just deployed if Assembly.deps.json is not found then AWS Lambda will look for any .deps.json files in the root of the deployment package. If there is exactly one .deps.json file it will use that one.

[ztittle]

If anyone runs into this issue again, I finally found out what was going after banging my head against the wall for over a day. In my build server configuration, I run bamboo as a service. This has an unfortunate side effect of creating files by default with the wrong permissions (0027), which only sets the group and user permissions. Apparently, AWS Lambda needs the files to have the 'other' permission +r set so that it can see the file.

I know the tool attempts to chmod before zipping, but it skips the .deps.json file. I feel that the tool should be a bit more robust and set the other read permission for all files.

fyi you can set default permissions using the following command

umask 0002 prior to running the dotnet lambda deploy-serverless command.

more info on bamboo https://confluence.atlassian.com/bamkb/how-to-configure-the-default-umask-for-bamboo-server-and-remote-agents-958455246.html

https://stackoverflow.com/questions/41975808/set-umask-for-tomcat8-via-tomcat-service