How do you limit or control publishing artifacts for the AWS Visual Studio Toolkit?

Question

I am creating a lambda with c# several different ways (serverless, lambda, with/without tests) and I end up with a lot of items in the publishing artifacts .zip file that really don't need to be there. If I'm deploying the Lambda and there is a test project in the solution, I right click on the project -> Publish to AWS, follow the prompts and it ends up zipping the xunit libraries along with many localized versions of Microsoft.TestPlatform and Microsoft.VisualStudio.TestPlatform artifacts. The output will look similar to the following:

... zipping: xunit.abstractions.dll
... zipping: xunit.assert.dll
... zipping: xunit.core.dll
... zipping: xunit.execution.dotnet.dll
... zipping: xunit.runner.reporters.netcoreapp10.dll
... zipping: xunit.runner.utility.netcoreapp10.dll
... zipping: xunit.runner.visualstudio.dotnetcore.testadapter.dll
... zipping: cs/Microsoft.TestPlatform.CommunicationUtilities.resources.dll
... zipping: cs/Microsoft.TestPlatform.CoreUtilities.resources.dll
... zipping: cs/Microsoft.TestPlatform.CrossPlatEngine.resources.dll
... zipping: cs/Microsoft.VisualStudio.TestPlatform.Common.resources.dll
... zipping: cs/Microsoft.VisualStudio.TestPlatform.ObjectModel.resources.dll
... zipping: de/Microsoft.TestPlatform.CommunicationUtilities.resources.dll
... zipping: de/Microsoft.TestPlatform.CoreUtilities.resources.dll
... zipping: de/Microsoft.TestPlatform.CrossPlatEngine.resources.dll
... zipping: de/Microsoft.VisualStudio.TestPlatform.Common.resources.dll
... zipping: de/Microsoft.VisualStudio.TestPlatform.ObjectModel.resources.dll
... zipping: es/Microsoft.TestPlatform.CommunicationUtilities.resources.dll
... zipping: es/Microsoft.TestPlatform.CoreUtilities.resources.dll
... zipping: es/Microsoft.TestPlatform.CrossPlatEngine.resources.dll
... zipping: es/Microsoft.VisualStudio.TestPlatform.Common.resources.dll
... zipping: es/Microsoft.VisualStudio.TestPlatform.ObjectModel.resources.dll
... zipping: fr/Microsoft.TestPlatform.CommunicationUtilities.resources.dll
... zipping: fr/Microsoft.TestPlatform.CoreUtilities.resources.dll
... zipping: fr/Microsoft.TestPlatform.CrossPlatEngine.resources.dll
... zipping: fr/Microsoft.VisualStudio.TestPlatform.Common.resources.dll
... zipping: fr/Microsoft.VisualStudio.TestPlatform.ObjectModel.resources.dll
... zipping: it/Microsoft.TestPlatform.CommunicationUtilities.resources.dll
... zipping: it/Microsoft.TestPlatform.CoreUtilities.resources.dll
... zipping: it/Microsoft.TestPlatform.CrossPlatEngine.resources.dll
... zipping: it/Microsoft.VisualStudio.TestPlatform.Common.resources.dll
... zipping: it/Microsoft.VisualStudio.TestPlatform.ObjectModel.resources.dll
... zipping: ja/Microsoft.TestPlatform.CommunicationUtilities.resources.dll
... zipping: ja/Microsoft.TestPlatform.CoreUtilities.resources.dll
... zipping: ja/Microsoft.TestPlatform.CrossPlatEngine.resources.dll
... zipping: ja/Microsoft.VisualStudio.TestPlatform.Common.resources.dll
... zipping: ja/Microsoft.VisualStudio.TestPlatform.ObjectModel.resources.dll
... zipping: ko/Microsoft.TestPlatform.CommunicationUtilities.resources.dll
... zipping: ko/Microsoft.TestPlatform.CoreUtilities.resources.dll
... zipping: ko/Microsoft.TestPlatform.CrossPlatEngine.resources.dll
... zipping: ko/Microsoft.VisualStudio.TestPlatform.Common.resources.dll
... zipping: ko/Microsoft.VisualStudio.TestPlatform.ObjectModel.resources.dll
... zipping: pl/Microsoft.TestPlatform.CommunicationUtilities.resources.dll
... zipping: pl/Microsoft.TestPlatform.CoreUtilities.resources.dll
... zipping: pl/Microsoft.TestPlatform.CrossPlatEngine.resources.dll
... zipping: pl/Microsoft.VisualStudio.TestPlatform.Common.resources.dll
... zipping: pl/Microsoft.VisualStudio.TestPlatform.ObjectModel.resources.dll
... zipping: pt-BR/Microsoft.TestPlatform.CommunicationUtilities.resources.dll
... zipping: pt-BR/Microsoft.TestPlatform.CoreUtilities.resources.dll
... zipping: pt-BR/Microsoft.TestPlatform.CrossPlatEngine.resources.dll
... zipping: pt-BR/Microsoft.VisualStudio.TestPlatform.Common.resources.dll
... zipping: pt-BR/Microsoft.VisualStudio.TestPlatform.ObjectModel.resources.dll
... zipping: ru/Microsoft.TestPlatform.CommunicationUtilities.resources.dll
... zipping: ru/Microsoft.TestPlatform.CoreUtilities.resources.dll
... zipping: ru/Microsoft.TestPlatform.CrossPlatEngine.resources.dll
... zipping: ru/Microsoft.VisualStudio.TestPlatform.Common.resources.dll
... zipping: ru/Microsoft.VisualStudio.TestPlatform.ObjectModel.resources.dll
... zipping: tr/Microsoft.TestPlatform.CommunicationUtilities.resources.dll
... zipping: tr/Microsoft.TestPlatform.CoreUtilities.resources.dll
... zipping: tr/Microsoft.TestPlatform.CrossPlatEngine.resources.dll
... zipping: tr/Microsoft.VisualStudio.TestPlatform.Common.resources.dll
... zipping: tr/Microsoft.VisualStudio.TestPlatform.ObjectModel.resources.dll
... zipping: zh-Hans/Microsoft.TestPlatform.CommunicationUtilities.resources.dll
... zipping: zh-Hans/Microsoft.TestPlatform.CoreUtilities.resources.dll
... zipping: zh-Hans/Microsoft.TestPlatform.CrossPlatEngine.resources.dll
... zipping: zh-Hans/Microsoft.VisualStudio.TestPlatform.Common.resources.dll
... zipping: zh-Hans/Microsoft.VisualStudio.TestPlatform.ObjectModel.resources.dll
... zipping: zh-Hant/Microsoft.TestPlatform.CommunicationUtilities.resources.dll
... zipping: zh-Hant/Microsoft.TestPlatform.CoreUtilities.resources.dll
... zipping: zh-Hant/Microsoft.TestPlatform.CrossPlatEngine.resources.dll
... zipping: zh-Hant/Microsoft.VisualStudio.TestPlatform.Common.resources.dll
... zipping: zh-Hant/Microsoft.VisualStudio.TestPlatform.ObjectModel.resources.dll

1. Is there a way to limit what files go into the zip folder that gets sent to AWS?
2. Is there a way to exclude localized libraries?
3. Can I exclude other projects that are not dependencies?
4. Can I keep all my projects to be in the same solution and be able to publish using the built in mechanisms without sending extraneous projects?

The problem I have is that it inflates the size of the deploy package and the files are never used, so it impacts my s3 storage costs, causes slower lambda cold start times, and inefficiencies .

Searching the internet, Excluding Files and Folders from Deployment looked promising, but it didn't make any difference for me (perhaps I did something wrong?).

Answer 1

In Visual Studio you can Right-Click on Test Project properties and then in

• Build > Publish : Uncheck Publishing

Or edit the Test Project .csproj file and add:

<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
    <IsPublishable>False</IsPublishable>
</PropertyGroup>

Answer 2

This is probably not the right answer to your question, but I ran into something similar and wanted to provide more detail.

I am not using Visual Studio Professional. I have the AWS VS Toolkit for VS 2017, but it appears that the "Publish to AWS" project context menu item is only available in VS 2019.

I was working with a project that was created using the SAM CLI command

sam init -r dotnetcore2.1 -o sam-runtime-dotnetcore21

...which creates an example serverless project, complete with a .sln and two .csproj files. Structure looks something like:

src/
  HelloWorld/
    HelloWorld.csproj
    Program.cs
test/
  HelloWorld.Test/
    FunctionTest.cs
    HelloWorld.Tests.csproj
Solution.sln
template.yaml

If you run the following command from the root of the project (the same cwd as the Solution.sln and template.yaml file), you will end up with output from both the src and test projects in a single custom output location, which should be ./publish from the project root:

dotnet publish --output ../../publish

In order to get output from just the src project, excluding the test project, you can run the same command like so:

dotnet publish ./src/HelloWorld/HelloWorld.csproj --output ../../publish

Though I haven't verified, I assume the VS Pro 2019 tooling is just assembling dotnet publish commands and is not providing the correct csproj argument. You can always just run a custom dotnet publish command to build, then point your function code entry point at that output folder when packaging the lambda function code to s3.