AWS Toolkit for Visual Studio now supports Visual Studio 2019

A new release of the AWS Toolkit for Visual Studio has been published to Visual Studio marketplace. This new release adds support for Visual Studio 2019. Visual Studio 2019 is currently in preview, however, Microsoft has announced the general availability (GA) release date to be April 2, 2019.

The AWS Toolkit for Visual Studio provides many features inside Visual Studio to help get your code running in AWS. This includes deploying ASP.NET and ASP.NET Core web applications to AWS Elastic Beanstalk, deploying containers to Amazon Elastic Container Service (Amazon ECS), or deploying .NET Core serverless applications with AWS Lambda and AWS CloudFormation.

The toolkit also contains an AWS Explorer tool window that can help you manage some of your most common developer resources, like Amazon S3 buckets and Amazon DynamoDB tables.

We have also had a couple recent releases for .NET Core Lambda support that was only available to our .NET Core Global Tool, Amazon.Lambda.Tools. With the new release of the AWS Toolkit for Visual Studio you can now take advantage of these new features within Visual Studio.

Lambda Custom .NET Core runtime

Support for using custom .NET Core runtimes with Lambda was released recently. This provides the ability to use any version of .NET Core in Lambda, such as .NET Core 2.2 or .NET Core 3.0 preview. Now that support has been added to the AWS Toolkit for Visual Studio.

You can create a Lambda project using .NET Core 2.2 by selecting the Custom Runtime Function blueprint. To use .NET Core 3.0 preview, just update the target framework of the project in the project properties.

When you right-click the project and choose Publish to AWS, as you would for any other Lambda project, you might notice some differences.

The Language Runtime box now says Custom .NET Core Runtime, and the Framework says netcoreapp3.0. Also, you no longer select an assembly, type, and method for the Lambda handler. Instead, there is an optional handler field. The handler is optional because in a custom runtime function, the .NET Core project is packaged up as an executable file, so the Main method is called to start the .NET process. You’re welcome to still set a value for the handler, which you can access in your code by using the _HANDLER environment variable.

Lambda layers

The Lambda layers feature was also added to Amazon.Lambda.Tools .NET Core Global Tool. This makes it easy to create a layer of your .NET assemblies and tell Lambda to deploy your project with a specified layer. That way the deployment bundle can have a reduced size. And if you choose to create the layer on an Amazon Linux environment, you can optimize the .NET assemblies added to the layer by having them pre-jitted. This can reduce your cold-start time. You can find out more about optimizing packages here..

You still need to create the layer with the Amazon.Lambda.Tools .NET Core Global Tool. But once you create the layer, you can reference the layer in your projects and Visual Studio will honor the layer when creating the deployment package.

Let’s do a quick walkthrough on how to use layers with Visual Studio. You’ll need to have Amazon.Lambda.Tools installed, which you can do by using the following command.

dotnet tool install -g Amazon.Lambda.Tools

If you already had it installed, make sure it’s at least version 3.2.0. If it isn’t, then use the following command to update.

dotnet tool update -g Amazon.Lambda.Tools

Then, in a console window, navigate to your project and execute the following command.

dotnet lambda publish-layer <layer-name> —layer-type runtime-package-store —s3-bucket <bucket>

This creates a layer and outputs an ARN for the new version of the layer, which should look something like this, depending on what you name your layer: arn:aws:lambda:us-west-2:123412341234:layer:DemoTest:1

If you used the Lambda projects template that deploys straight to the Lambda service, you can specify the layer in the aws-lambda-tools-defaults.json configuration file with the function-layers key. If you want to use multiple layers, use a comma-separated list.

{
    "profile"               : "default",
    "region"                : "us-west-2",
    "configuration"         : "Release",
    "framework"             : "netcoreapp2.1",
    "function-runtime"      : "dotnetcore2.1",
    "function-memory-size"  : 256,
    "function-timeout"      : 30,
    "function-handler"      : "DemoLayerTest::DemoLayerTest.Function::FunctionHandler",

    "function-layers"       : "arn:aws:lambda:us-west-2:123412341234:layer:DemoTest:1"
}

If you’re deploying with an AWS CloudFormation template, usually called the serverless.template file, then you need to specify the layer using the Layers property.

"Get" : {
    "Type" : "AWS::Serverless::Function",
    "Properties": {
        "Handler": "DemoLayerServerlessTest::DemoLayerServerlessTest.Functions::Get",
        "Runtime": "dotnetcore2.1",
        "CodeUri": "",
        
        "Layers" : ["arn:aws:lambda:us-west-2:123412341234:layer:DemoTest:1"],
        
        "MemorySize": 256,
        "Timeout": 30,
        "Role": null,
        "Policies": [ "AWSLambdaBasicExecutionRole" ],
        "Events": {
        }
    }
}

With the layer specified the deployment wizard in Visual Studio will pick up this layer setting. Visual Studio will make sure the layer information is passed down into the underlying dotnet publish command used by our tooling, so that the deployment bundle is created without the .NET assemblies that will be provided by the layers.

I imagine a typical scenario for layers is a common layer is created by one dev on a team or through automation, possibly using the optimization feature. Then that layer is shared with the rest of the team in their development environments.

A final note about layers and custom runtimes. Currently, you can’t use the layer feature with the custom runtimes feature. This is because a custom runtime is deployed as a self-contained application with all the required runtime assemblies of .NET Core included with the deployment package. The underlying call to dotnet publish used in self-contained mode doesn’t support passing in a manifest of assemblies to exclude.

Visual Studio new project wizard

Visual Studio 2019 contains a new redesign for the experience of creating projects. All of the features of this redesign are not available yet to Visual Studio extensions like the AWS Toolkit for Visual Studio.

For example, the Language, Platform, or Project type filters you can see here in the new project wizard are not accessible to custom project templates like the ones that AWS provides. If you select C# in the language filter, our C# project templates will not show up.

The Visual Studio team plans to address this issue for extensions in a future update to Visual Studio 2019, but the changes will not be in the initial GA version. Until this is addressed, the best way to find our AWS project templates is to use the search bar and either search for “AWS” or “Lambda”.

Conclusion

We have come a long way since the AWS Toolkit for Visual Studio was first released in 2011 for Visual Studio 2008 and 2010, with support for ASP.NET web apps. With serverless and container support, as well as the Elastic Beanstalk support for web applications, you can use the toolkit to deploy so many types of applications to AWS.

We enjoy getting your feedback on our Visual Studio support. You can reach out to us about the AWS Toolkit for Visual Studio on our .NET repository.

–Norm