aws-lambda-dotnet: Adding a library breaks dotnet lambda package and also visual tools

I have a Lambda function that works fine. If I deploy it to AWS with with the VS tools, it works fine. It’s all fine.

Then, if I add another .NET Core library project to the solution, everything blows up. The project is a .NET Core library that I’d like to share across Lambda functions. I can target .netstandard1.6 or netstandard1.5 on the library and I get the same errors. When using dotnet lambda package or the visual tools, every single object from the net standard classes isn’t found. System.Void, System.String etc etc.

I can add rhel.7-x64 to the csproj as a built target and it will build fine that way with the library for rhel.7-x64 just fine. I haven’t tried deploying it yet as a zip but I will try to do that even though it’s not the “right” way.

Any help here would be appreciated, it breaks in this way even if I add the library project to the .sln but don’t add a reference in the Lambda Function project.

Lambda function


<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netcoreapp1.0</TargetFramework>
    <DebugType>portable</DebugType>
    <AssemblyName>OmegaEventHandlerService</AssemblyName>
    <OutputType>Exe</OutputType>
    <PackageId>OmegaEventHandlerService</PackageId>
    <RuntimeFrameworkVersion>1.0.4</RuntimeFrameworkVersion>
    <PackageTargetFallback>$(PackageTargetFallback);dnxcore50</PackageTargetFallback>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="System.Net.NetworkInformation" Version="4.3.0" />
    <PackageReference Include="Microsoft.Extensions.Logging" Version="1.1.1" />
    <PackageReference Include="Npgsql" Version="3.2.2" />
    <PackageReference Include="Newtonsoft.Json" Version="10.0.1" />
    <PackageReference Include="System.Text.Encodings.Web" Version="4.3.0" />
    <PackageReference Include="Amazon.Lambda.Core" Version="1.0.0" />
    <PackageReference Include="Amazon.Lambda.Serialization.Json" Version="1.0.1" />
    <PackageReference Include="Amazon.Lambda.Tools" Version="1.4.0">
      <PrivateAssets>All</PrivateAssets>
    </PackageReference>
    <PackageReference Include="Amazon.Lambda.SNSEvents" Version="1.0.0" />
    <PackageReference Include="AWSSDK.SimpleNotificationService" Version="3.3.0.10" />
  </ItemGroup>

  <ItemGroup>
    <DotNetCliToolReference Include="Amazon.Lambda.Tools" Version="1.4.0" />
  </ItemGroup>

  <ItemGroup>
    <ProjectReference Include="..\OmegaCoreLib\OmegaCoreLib.csproj" />
  </ItemGroup>

</Project>

It breaks even without that last ItemGroup in there, just adding the library project into the sln breaks it.

LIbrary:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netstandard1.6</TargetFramework>
    <AssemblyName>OmegaCoreLib</AssemblyName>
  </PropertyGroup>

  <ItemGroup>
      <PackageReference Include="Amazon.Lambda.Core" Version="1.0.0" />
      <PackageReference Include="Amazon.Lambda.Serialization.Json" Version="1.0.1" />
      <PackageReference Include="Microsoft.Extensions.Logging" Version="1.1.1" />
      <PackageReference Include="AWSSDK.SimpleNotificationService" Version="3.3.0.10" />
      <PackageReference Include="Newtonsoft.Json" Version="10.0.1" />
      <PackageReference Include="Npgsql" Version="3.2.2" />
      <PackageReference Include="AWS.Logger.AspNetCore" Version="1.0.0" />
</ItemGroup>

</Project>

Some output that may be useful:

Executing publish command
Deleted previous publish folder
... invoking 'dotnet publish', working folder 'C:\Users\kk\Code\digital-pi\OmegaEventHandlerService\bin\Release\netcoreapp1.0\publish'
... publish: Microsoft (R) Build Engine version 15.1.548.43366
... publish: Copyright (C) Microsoft Corporation. All rights reserved.
... publish:   OmegaEventHandlerService -> C:\Users\kk\Code\digital-pi\OmegaEventHandlerService\bin\Release\netcoreapp1.0\OmegaEventHandlerService.dll
... publish: C:\Users\kk\AppData\Local\Temp\.NETCoreApp,Version=v1.0.AssemblyAttributes.cs(4,20): error CS0400: The type or namespace name 'System' could not be found in the global namespace (are you missing an assembly reference?) [C:\Users\kk\Code\digital-pi\OmegaCoreLib\OmegaCoreLib.csproj]
... publish: obj\Release\netcoreapp1.0\OmegaCoreLib.AssemblyInfo.cs(6,12): error CS0246: The type or namespace name 'System' could not be found (are you missing a using directive or an assembly reference?) [C:\Users\kk\Code\digital-pi\OmegaCoreLib\OmegaCoreLib.csproj]
... publish: obj\Release\netcoreapp1.0\OmegaCoreLib.AssemblyInfo.cs(7,12): error CS0246: The type or namespace name 'System' could not be found (are you missing a using directive or an assembly reference?) [C:\Users\kk\Code\digital-pi\OmegaCoreLib\OmegaCoreLib.csproj]

… thousands of lines later…

... publish: C:\Program Files\dotnet\sdk\1.0.0\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.Sdk.targets(92,5): error : Assets file 'C:\Users\kk\Code\digital-pi\OmegaCoreLib\obj\project.assets.json' doesn't have a target for '.NETCoreApp,Version=v1.0'. Ensure you have restored this project for TargetFramework='netcoreapp1.0' and RuntimeIdentifier=''. [C:\Users\kk\Code\digital-pi\OmegaCoreLib\OmegaCoreLib.csproj]

It seems like it is doing something where it’s not passing a RID to the build for the library.

The library accesses lambda core because it deals with lambda logging.

Anyway, this is driving me crazy and I’m not sure how to resolve it. Seems like a bug in the lambda tools as it’s happening even if I don’t add the reference to the library project.

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Reactions: 1
  • Comments: 18 (4 by maintainers)

Most upvoted comments

Unrelated to your question: some of the packages you are depending on (System.Net.NetworkInformation, System.Text.Encodings.Web, Npgsql) are versions that depend on .NET Core 1.1, while Lambda supports .NET Core 1.0. I’m not certain why these dependencies are not causing issues for you, but they may eventually. If they do, downgrade the dependencies to .NET Core 1.0 packages. For System.* packages this is 4.1, and for Npgsql it’s 3.1.10.