Deploy to Azure ILB ASE using Visual Studio Online Services.

Few months back azure released a new offering called Application service environment. More details on it can be found here :

The Azure App Service Environment is an Azure App Service feature that provides a fully isolated and dedicated environment for securely running App Service apps at high scale. This capability can host your web apps, mobile apps, API apps, and functions.

App Service Environment, or ASE, have one new feature which was missing earlier. This is called as Internal ASE, which, allows you to deploy web application with an internet-accessible endpoint or with an IP address in your Virtual Network. This means you can create web apps like before but with no external endpoint.

However, since internal ASE is completed isolated, automated deployments and CI/CD pipelines need bit of work to setup. In Internal ASE, the publishing endpoint isn’t internet accessible. So, what we can do is make a build agent for VSTS in our v-net on the subnet that is internet accessible. And then let this agent, pull the code or build artefacts and deploy to ILB ASE. Since ILB ASE and our custom agent are on the same v-net, agent will be able to communicate to the internal ILB ASE deployment endpoint.

Please refer to below on how to implement this.

  1. Below is screenshot my test account. 3 main resources to point out here are the ilbasev2 (the ILB ASE environment), ilbasev2appname (the web app where I ll host my demo site) and jumpbox (VM hosted on the DMZ subnet to act as build agent and push to internal endpoint).


  1. Next we will login to the jump box and create VSTS build agent. I want to connect this agent to my VSTS account to make sure all the build and deployment is happening via this agent. Please refer to below URL on how to setup the agent. Since I will demo using a .net MVC application, I am going to create a windows agent.

Also make sure MSBuild is installed on this VM, so that we can build our MVC solution.

  1. Once above is done, navigate to Agent queues screen under settings as per the screenshot below in your VSTS account and confirm that agent is setup correctly and connected to VSTS.


  1. Next we will make our build definition. We will create a simple build definition which will pull our demo MVC application code, restore packages and publish the artefact. The only thing to note here is the MSBuild argument. In case you are using a self-signed certificate for ILB ASE, you may want to add additional argument with MSBuild to make sure you don’t get any certificate related issues during build. The argument to use is ‘AllowUntrustedCertificate’ with value true.

The other way to go around self-signed certificate is to just manually install the certificate in your build agent server trusted certificate folder.

More details on that here :


  1. Once the build definition is setup, we can queue to execute it. Before we do that one important thing is to set the Agent Queue. Make sure it is the build agent that we have setup earlier. That will make sure our build agent is working as expected for later steps. We may use the hosted agent for builds too though for this step.


  1. Below is what you see if everything is working ok.


  1. Next we focus on release and deployment to ILB ASE. Below is a simple release definition with more details in next point. MY environment here the Azure ILB ASE that I am targeting the deployment too





  1. All this release does is deploy our artefact to the azure web app created using ILB ASE. One key thing to point out is the Agent Queue Parameter. Make sure it is pointed to our build agent that we created earlier.


  1. Create a new release using above release definition and you should be successfully able to move your code to ILB ASE.


  1. If you don’t use the build agent that we created earlier but use VSTS hosted one, then you should see this error. This is because the VSTS agent could not connect to the internal deployment endpoint of ILB ASE.




Deploying a Web Deploy Package to AWS ElasticBeanstalk

AWS provide an extension to Visual Studio to make interacting with your AWS services easy, including deploying to a Beanstalk environment, which is the recommended way of deploying to a Beanstalk.

This works great, and if you are able to, you should obviously use the recommended approach, but there may be times you don’t have the extension available, or already have a build system setup to use Web Deploy packages. As far as I can tell the Beanstalk just uses MsDeploy packages under the hood, making it easy to deploy these without the extension!

1. Create a Package

If you don’t already have a Web Deploy package, create one. This is simple in Visual Studio, open your Web Application, right click on the Web Application project and select Publish.

This will open the Publish Web dialog:


Select Custom, and give your profile a name (for example the beanstalk environment name). On the Connection screen, update the Publish method to Web Deploy Package.

Deploy2Enter Default Web Site for the Site name, and choose a location on your machine to create the package.

Check the Settings are correct on the next screen, confirm your publish location on the Preview screen, and then click Publish.

Navigate to the folder where the package was created, you should see 5 files, the only one of interest for this case is the ZIP file.


2. Deploying the package

Browse to your environment in the AWS Management Console

Deploy3Select Upload and Deploy.


Deploy4Choose the ZIP file created earlier, and give this version a label (these should be unique amongst labels used for this application).

Clicking Deploy will start the deployment of the code to this environment, you will be able to monitor the logs in the Console to the status of your deployment.

If everything goes to plan you should see a message in the logs saying “New application version was deployed to running EC2 instances.”.

Next Steps

Just as you can automate these steps using the AWS Visual Studio Toolkit and the Deployment Tool command line program, these steps can be automated

The package can be created using MSBuild and the Package target.

The deployment to AWS can be automated using either the CLI tools, or Powershell tools and the following methods