AWS Developer Blog

.NET Application Deployment Roundup

by Jim Flanagan | on | in .NET | Permalink | Comments |  Share

.NET Application Deployment Roundup

In this post, we talk about several customer questions that have come up in the AWS Forums.

Deploying MVC4 applications on AWS Elastic Beanstalk

Deploying MVC4 applications to an AWS Elastic Beanstalk environment is just as easy as deploying other types of .NET web applications, and does not require pre-installing any software on instances in order to work. All you need to do is to make sure that the necessary project references have Copy Local set to True. For example, setting Copy Local to False for System.Web.Mvc and System.Web.Razor will cause your application to work on your development system, but fail when it gets deployed to the instance.

New MVC4 projects created from the "ASP.NET MVC 4 Web Application" template in Visual Studio should have the references set up correctly for deploying to Elastic Beanstalk.

Deploying applications to the root

By default, Visual Studio configures web applications to be deployed to a virtual directory. For applications in virtual directories, the .NET Elastic Beanstalk container deploys the application into the virtual directory, then creates a URL rewrite rule to direct requests from http://my-app.elasticbeanstalk.com/ to http://my-app.elasticbeanstalk.com/MyApp. For some applications, this rewrite rule can cause issues, since you might have other reasons to deploy your application to the root level.

In Visual Studio 2010, you can change the deployment location with the following steps:

  • Open the Properties pane for the web application.
  • Navigate to the Package/Publish Web tab.
  • Edit the value of IIS Web site/application name to use on the destination server to be DefaultWebSite.

If your version of Visual Studio 2012 has Update 2 or later, this option will not be present in the Properties pane, but you can add the <DeployIisAppPath> to the appropriate <PropertyGroup> element in your .csproj file. If you want it to apply to all Configurations and Platforms and deploy at the root, you can include it in the <PropertyGroup> element, i.e.:

<PropertyGroup>
  .....
  <DeployIisAppPath>Default Web Site/</DeployIisAppPath>
</PropertyGroup>

Or for Release|AnyCPU build target:

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
  <DeployIisAppPath>Default Web Site/</DeployIisAppPath>
</PropertyGroup>

Avoid maintaining state on instances

The nature of Elastic Beanstalk environments is that instances can come and go over time. For that reason, you should design your application so that as instances are added or removed from your environment due to failures or scaling events, they have everything they need to correctly serve your application. Similarly, when instances are removed from the environment, you shouldn’t lose important state or data.

Maintaining application state across servers is a great use of AWS services, such as Amazon S3 for file content, or Amazon DynamoDB for key/value storage.

Using Visual Studio 2013 Preview

With the latest release of the AWS Toolkit for Visual Studio, the installer now supports installation of the toolkit and project templates into the preview editions of Visual Studio 2013. As with prior releases of the toolkit, professional or higher versions of the IDE support the AWS Explorer tool window, the AWS CloudFormation template editor, and a set of project templates for a variety of AWS services. For users with Express editions of the IDE, only the project templates are installed due to licensing restrictions for these editions.