Building .NET Applications for AWS

Amazon Web Services (AWS) is a member of the .NET Foundation and is a major proponent of .NET development and .NET developers.  AWS engineers are currently supporting several different .NET open source products with the support for those projects, and others, continuing to grow. 

This support includes most modern .NET platforms, including the recently released version of .NET Core, v3.1.

As its name implies, AWS provides a large set of online services ranging from infrastructure solutions such as virtual machines and container management to storage products to purpose-built or managed databases with many, many more. 

Since these are all cloud-based services, all interaction is done through API calls (generally RESTful).  A developer can choose to interact directly with these APIs, however AWS recognizes that this adds complexity to a project and so provides language or framework-specific software development kits (SDK) that perform all of this interaction for the developer. 

All of the AWS SDKs provide support for API lifecycle consideration such as credential management, retries, data marshaling, and serialization; all of which save time and effort for a developer looking to interact with AWS services and products.

One example of a framework-specific SDK is the AWS Software Development Kit for .NET.

.NET Software Development Kit

In November 2009, AWS released the initial AWS Software Development Kit for .NET (SDK).  The SDK gives .NET applications a framework that allows them easy access to AWS services. 

AWS updates the .NET SDK daily, so it is a rare situation when AWS releases a new feature or service and the SDK is not updated that day.  The .NET SDK simplifies the use of AWS services by providing a set of libraries in a way that is consistent and familiar for .NET developers. 

Every AWS service that is accessible through an API has an SDK that is available through NuGet from nuget.org.  The service-specific SDKs follow the naming pattern of AWSSDK.ServiceName, as shown in Figure 1.

Figure 1- NuGet configuration in JetBrains Rider after searching for AWS

There are also some higher-level abstractions to help developers better manage some common tasks such as logging, transferring files, and providing authentication. These higher-level abstractions have a different naming convention, AWS.AbstractionName.  An example of one of these abstractions is AWS.Logger.  This SDK is a higher-level library that wraps common .NET logging libraries, giving them the capability to save log entries directly into AWS’ monitoring and observability service, CloudWatch.  You can see the different AWS.Logger NuGet packages in Figure 2.

Figure 2 - Visual Studio 2019 NuGet Package Manager after searching for AWS.Logger.

When you install an API-specific AWSSDK package, you will generally see that there are two packages being installed, AWSSDK.Core and AWSSDK.ServiceName as shown in Figure 3.

Figure 3- Installing AWSSDK.S3 package in Visual Studio

All service packages depend on a common core library that does the marshaling, request signing, and other tasks to enable sending API requests to, and receiving responses from, AWS. The service-specific packages simply expose the service API and related model classes.  The same may happen if you install a higher-level SDK.  Figure 2, above, shows a package named AWS.Logger.Core.  Installing any of the other AWS.Logger packages will also install the Core package.  Note, this is not true across all of the higher-level SDKs.

Reviewing the package and .dlls will show that the .dll and the package have the same name.  Thus, adding the AWSSDK.S3 package to a project will result in adding AWSSDK.S3.dll to the \bin directory.  One thing to note, however, is that while the namespace is similar to the package and .dll name, they are not identical.  While the .dll name is AWSSDK.S3.dll, as Figure 4 shows, the namespace used when accessing that functionality is Amazon.S3.

Figure 4 - Visual Studio Object Browser for AWSSDK.S3.

Working with the SDK is similar to working with any other project reference.  For example, the AWS service shown in Figure 4 is S3, also known as Amazon Simple Storage Service.  S3 is an object storage service that offers scalability, data availability, security, and performance.  The following code example demonstrates using the SDK to persist a file to S3:

/// <summary>Example running in an ASP.NET MVC web application that synchronously saves a file to S3</summary>
using Amazon;
using Amazon.S3;
using Amazon.S3.Model;

public async Task<string> SaveAsync(string path)
{   
    try
    {
        string fileName = "NDC-Booth.jpg";
        string filePath = Path.Combine(path, fileName);
        RegionEndpoint bucketRegion = RegionEndpoint.USWest2;

        var putRequest = new PutObjectRequest
        {
            BucketName = "infoq-article-bucket",
            Key = fileName,
            ContentType = "image/jpeg",
            FilePath = filePath
        };

        putRequest.Metadata.Add("x-amz-meta-title", "2020 AWS Booth at NDC London");

        using (IAmazonS3 client = new AmazonS3Client(bucketRegion))
        {
    var results = await client.PutObjectAsync(putRequest).ConfigureAwait(false);
           return results.ETag;            
        }
    }
    catch (AmazonS3Exception e)
    {
        logger.Error("Amazon error saving to S3", e);
    }
    catch (Exception e)
    {
        logger.Error("Unknown error saving to S3", e);
    }
    return null;
}     

This simple example copies an image from the local web directory and puts it in S3.  By using the SDK, you do not have to worry about managing authentication, verification, or retries, and it just works.  In addition, while this example uses an asynchronous method, a synchronous version that does not return a Task is also available for those cases where a synchronous approach would be more appropriate.  In that case, your synchronous method would look more like:

public string Save(string path)
{
…
using (IAmazonS3 client = new AmazonS3Client(bucketRegion))
       {
            var response1 = client.PutObject(putRequest);
            return response.ETag;
       }
	…
}

Your calling method would have to change as well because of the change in return type.  For those of you working in .NET Core, asynchronous communication is the standard, however synchronous communication was common in earlier .NET applications.

AWS Toolkits

As you can see, the SDK helps developers interact with AWS services from within their .NET application.  However, developers use SDK programmatically, so it does not support personal interaction with AWS services.  That is where the Toolkits come in.  Each of the major IDEs used by .NET developers for developing their applications has their own Toolkit.  There are currently Toolkits for Visual Studio, VS Code, and JetBrains Rider.  These toolkits are extensions designed to help create, debug, and deploy .NET applications on AWS.

You can install the toolkit through the IDE.  In Visual Studio, it will be through the Extensions > Manage extensions > Visual Studio Marketplace as shown in Figure 5.

Figure 5 - Adding the AWS Toolkit to Visual Studio 2019

In JetBrains’ Rider, you install the toolkit through the Configure > Plugins link on the opening splash screen, as shown in Figure 6.

Figure 6 - Add AWS Toolkit to JetBrains Rider

After installation, the toolkit gives you access to AWS services through the IDE.  For example, when working in Visual Studio, the toolkit provides you an additional module, the AWS Explorer. After opening the AWS Explorer, you will see a list of different AWS services with which you will be able to work.  Most of these allow you to create or delete items as well as modify some of the properties of those items.  Figure 7 shows the file uploaded from the previous code sample.

Figure 7 - Using the toolkit to look at an uploaded file in an S3 bucket

The various toolkits have different levels of maturity and support.  The VS Code and JetBrains toolkits, for example, focus on serverless development so do not have the same list of services available in their AWS Explorers windows.  Figure 8 shows the AWS Explorer window in JetBrains Rider and VS Code together.

Figure 8 - AWS Explorer windows in JetBrains Rider and VS Code

The toolkits provide more functionality to the IDE than the ability to manage some of the AWS services.  Another feature that the toolkit brings is the addition of additional project templates, as shown in Figure 9.

Figure 9 - Visual Studio 2019 New Project dialogue filtered to AWS templates

There are nine templates added in Visual Studio, mostly around creating AWS serverless applications or Lambda projects in C#, F#, and node.js; all languages supported by Visual Studio and AWS.  JetBrains Rider has an additional template as well, “AWS Serverless Application.”  That there are only serverless application templates created is appropriate; this is the only new “application type” in AWS as all of the rest of the server-side applications created in .NET are already supported.

The last set of features provided by the toolkit is help around deploying the .NET application.  The assistance provided by the toolkit is dependent upon the type of project and application with which you are working.  An ASP.NET Core application will have an option to “Publish to AWS Elastic Beanstalk.”  If that same application has Docker support enabled within the .NET solution then they will get an additional deployment option of “Publish Container to AWS.” You can see what this looks like in Figure 10.

Figure 10 - Publish options when working in a "Docker-ized" ASP.NET Core application

Choosing the “Publish to AWS Elastic Beanstalk” approach will have the toolkit walk you through deploying to an existing Elastic Beanstalk environment or help you configure a new Elastic Beanstalk application.  While not exactly a platform-as-a-service (PaaS), Elastic Beanstalk feels very similar to a PaaS because it removes the hard work from provisioning and configuring AWS resources.  Deploying to a new instance requires you to make several choices: (1) the type of EC2 (virtual machine) instance you would like to use, (2) whether or not you want to deploy to multiple instances, and (3) what type of load balancer to use if you do deploy to multiple instances.  You also can select various security settings or go with the default.  This is a good starting point for those wanting to toss a web application over the AWS wall and see what it looks like

Applications already set up to support Docker have additional capabilities.  These capabilities revolve around Amazon Elastic Container Service (ECS) and allow developers to have the application run as a service, a “run-right-now” task, or as a scheduled task.  You can also simply upload the container definition to the Elastic Container Registry so that it is available for selection when working within ECS.  If you are deploying a website, you will want to select the “service” option as shown below in Figure 11.

Figure 11 - Using Visual Studio to publish a container to AWS

Proceeding through the publish path will also give you the ability to define and select load balancers and permissions.  Once that is completed, your application will be available and can be managed the same as any other container – you can increase or decrease the amount of containers running behind the load balancer, set up auto-scaling, or perform any other container-specific tasks needed to ensure your application is available for consumption.

Other .NET Support

The .NET SDK and IDE-based toolkits are not the only tools that AWS has built to support .NET developers.  There are also AWS Tools for PowerShell, AWS Tools for Azure DevOps (previously called AWS Tools for Visual Studio Team Services), and AWS Extensions for the .NET CLI.  The AWS Tools for PowerShell let developers and administrators manage their AWS services and resources in the PowerShell scripting environment and support many of the same actions as the AWS SDK for .NET.  The PowerShell tools also support the automation of AWS service management, so that you can manage your AWS resources with the same PowerShell tools you use to manage your Windows, Linux, and MacOS environments.

The AWS Tools for Azure DevOps is not specific to .NET but is, instead, a set of extensions for on-premises Microsoft Team Foundation Server (TFS) and Azure DevOps that make it easy to deploy .NET applications using AWS.  You can use your existing build and release process to deploy applications directly to AWS Elastic Beanstalk or AWS Lambda as well as interact with other services such as Amazon S3 or AWS CodeDeploy. 

The AWS Extensions for .NET CLI are additional tool extensions focused on building and deploying .NET Core and ASP.NET Core applications.  Many of these commands are the same as used in the AWS Toolkit for Visual Studio so that you can test the initial deployment through Visual Studio and then use the command line to automate the deployment going forward.  There are three different sets of .NET CLI tool extensions, one for Amazon ECS, one for AWS Elastic Beanstalk, and one for AWS Lambda. 

AWS has been supporting .NET development for more than a decade.  As mentioned earlier, many of the AWS compute services, such as EC2 and Lambda, have support for various versions of .NET built into their systems.  Windows virtual machines or containers support all .NET frameworks while the Linux-based VMs, containers, and serverless environments all support .NET Core.  The SDKs provide programmatic support for AWS services, allowing developers to not worry about authentication, or retries, or other infrastructure concerns and instead focus on building their application. 

Other available tools include the IDE-specific toolkits that give developers the ability to interact with various AWS services from within the browser, the AWS Tools for PowerShell for managing AWS services within the PowerShell scripting environment, the AWS Tools for Visual Studio Team Service, and the AWS Extensions for .NET CLI.  All of these tools are updated regularly, some daily, to keep up with changes that happen in AWS services, changes that happen in the .NET Framework, and to help keep up as development paradigms change to better support the cloud.

AWS is also looking to hire experienced .NET developers across the world – please review open positions if you are interested in helping AWS get even better in the .NET space!

About the Author

Having over 25 years of experience in software development (more than 15 of which is .NET), Dr. Bill brings a pragmatic approach to software development. With much of that time spent in consulting and project-based work, he has worked on many different projects and used many different development designs and approaches. He recently switched to the dark side and uses his development experience in a product management role where he acts as a .NET Developer Advocate with AWS, helping AWS to build a better and more rich .NET developer experience.