How to Continuously Deploy an ASP.NET Core 1.0 Web App to Microsoft Azure
Here's a rundown of how to set up continuous deployment of an ASP.NET Core 1.0 app to Azure.
Join the DZone community and get the full member experience.Join For Free
We started the first real world project with ASP.NET Core RC2 a month ago and we learned a lot of new stuff around ASP.NET Core:
- Continuous Deployment to an Azure Web App.
- Token based authentication with Angular2.
- Setup Angular2 & TypeScript in a ASP.NET Core project.
- Entity Framework Core setup and initial database seeding.
In this post, I'm going to show you how we set up continuous deployment stuff for an ASP.NET Core 1.0 project, without tackling TypeScript and Angular2. Please remember: The tooling around .NET Core and ASP.NET Core is still in "preview" and will definitely change. I'll try to keep this post up-to-date. I won't use the direct deployment to an Azure Web App from a git repository because of some reasons I mentioned in a previous post.
I will write some more lines about the other learned stuff in one of the next posts.
Let's Start With the Build
Building is the easiest part of the entire deployment process. To build an ASP.NET Core 1.0, solution, you can use
MSBuild.exe. Just pass the solution file to MSBuild, and it will build all projects in the solution.
*.xproj files use specific targets, which will wrap and use the dotnet CLI. You are also able to use the dotnet CLI directly. Just call
dotnet build for each project, or just simpler: call
dotnet build in the solution folder and the tools will recursively go through all sub-folders to look for
project.json files and build all the projects in the right build order.
Usually, I define an output path to build all the projects into a specific folder. This makes it a lot easier for the next step:
Test the Code
Some months ago, I wrote about unit testing DNX libraries (Xunit, NUnit). This didn't really change in .NET Core 1.0. Depending on the test framework, a test library could be a console application, which can be called directly. In other cases, the test runner is called, which gets the test libraries passed as arguments. We use NUnit to create our unit tests, which doesn't provide a separate runner yet for .NET Core. All of the test libraries are console apps and will build to a
.exe file. So we are searching the build output folder for our test libraries and call them one by one. We also pass the test output file name to that libraries, to get detailed test results.
This is pretty much all to run the unit tests.
Throw It to the Clouds
Deployment was a little more tricky. But we learned how to do it from the Visual Studio output. If you do a manual publish with Visual Studio, the output window will tell you how the deployment needs to be done. These are just two steps:
1. Publish to a specific folder using the "dotnet publish" command We are calling
dotnet publish with this arguments:
Shell.Exec("dotnet", "publish \"" + webPath + "\" --framework net461 --output \"" + publishFolder + "\" --configuration " + buildConf, ".");
webPathcontains the path to the web project which needs to be deployed.
publishFolderis the publish target folder.
buildConfdefines the Debug or Release build (we build with Debug in dev environments).
2. Use msdeploy.exe to publish the complete publish folder to a remote machine. The remote machine, in our case, is an instance of an Azure web app, but could also be any other target machine.
msdeploy.exe is not a new tool, but is still working, even with ASP.NET Core 1.0.
So, we just need to call msdeploy.exe like this:
Shell.Exec(msdeploy, "-source:contentPath=\"" + publishFolder + "\" -dest:contentPath=" + publishWebName + ",ComputerName=" + computerName + ",UserName=" + username + ",Password=" + publishPassword + ",IncludeAcls='False',AuthType='Basic' -verb:sync -" + "enablerule:AppOffline -enableRule:DoNotDeleteRule -retryAttempts:20",".")
msdeploycontaines the path to the msdeploy.exe which is usually
C:\Program Files (x86)\IIS\Microsoft Web Deploy V3\msdeploy.exe.
publishFolderis the publish target folder from the previous command.
publishWebNameis the name of the Azure Web App name, which also is the target content path.
computernameis the name/URL of the remote machine. In our case
"https://" + publishWebName + ".scm.azurewebsites.net/msdeploy.axd"
passwordare the deployment credentials. the password is hashed, as in the publish profile that you can download from Azure. Just copy paste the hashed password.
I didn't mention all the work that needs to be done to prepare the web app. We also use Angular2 with TypeScript. So we also need to get all the NPM dependencies, we need to move the needed files to the
Published at DZone with permission of Juergen Gutsch, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.