In my preparation for a “Deploying ASP.NET Core” talk at our dotnetConf.Local Birmingham 2016 event last week, I found the ASP.NET Core documentation has not been updated for the final 1.0 RTM release of ASP.NET Core. The instructions only apply to RC1:

If you attempt to use the current documentation you will receive the following error when you build in VSTS.

##[error]There are no runtimes matching the name dnx-clr-win-x86 on feed https://www.nuget.org/api/v2. ##[error]At C:\Users\buildguest\.dnx\bin\dnvm.ps1:619 char:9 ##[error]+ throw "There are no runtimes matching the name $RuntimeId on feed $feed. ... ##[error]+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ##[error] + CategoryInfo : OperationStopped: (There are no ru...get.org/api/v2.:String) [], RuntimeException ##[error] + FullyQualifiedErrorId : There are no runtimes matching the name dnx-clr-win-x86 on feed https://www.nuget.org/ap ##[error] i/v2. ##[error] ##[error]Process completed with exit code 1 and had 1 error(s) written to the error stream.

If you correctly identify that dnvm / dnx are no longer needed and remove that task you still get the following error on build:

C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\DotNet\Microsoft.DotNet.Common.Targets(262,5): Error : Project MyApp does not have a lock file. Please run "dotnet restore" to generate a new lock file.

Deploy ASP.NET Core 1.0 With Ease

The good news is its easier now to deploy an ASP.NET Core 1.0 application. Here are a few of the differences between the RC2 instructions and the steps listed in this blog post:

The PreBuild.ps1 script is no longer necessary to call dnvm to install dnx ( dnx has been replaced with dotnet.exe which is installed on the hosted VSTS build agents by default)

script is no longer necessary to call to install ( has been replaced with which is installed on the hosted VSTS build agents by default) You can use the dotnet publish command to publish the site instead of using MSBuild arguments

command to publish the site instead of using MSBuild arguments We will use the same deployment mechanism as the right-click publish option in VS which will provide more consistent results between local and VSTS builds/deployments

The deployment will not require an Azure service integration in VSTS

In the remainder of this blog post I will detail the steps necessary to deploy and ASP.NET Core 1.0 web application to an Azure App Service.

ASP.NET Project Setup

Create a ASP.NET Core 1.0 project. If necessary, upgrade your project from RC2 to RTM. Next create a publish profile by importing the publish profile settings from your Azure Website or App Service into Visual Studio. Right click on your web project, choose Publish and then click Import under “Select a publish target”. More details here for importing publish setting.

Then you can close the Publish dialog window or deploy directly from VS. Saving this profile creates a few files under the Properties folder of your project.

Make sure you check-in these files into your source control repository.

Sayed Hashimi explains how the right-click publish logic works for a ASP.NET Core project here.

Build Definition

Now we need to create a build definition in VSTS using the Visual Studio template.

Select the appropriate repository source on the next screen. You can delete the Nuget Restore, Test Assemblies and Publish Symbols path tasks if you like.

Next add two Commandline tasks, one before the Build solution task and one after.

Update the first task Tool field to “dotnet” and the Arguments field to “restore”. On the second task set the fields to “dotnet” and “publish” respectively. You can also update the task names to be more clear:

On the Copy files to staging task, add “**\PublishProfiles\**” to a new line on the Contents field so that your publish profile files to the published artifacts.

Now you can save and queue the build. The build should succeed and you should see the PublishProfiles folder in the artifacts:

Finally, save the build definition.

Release Definition

Create a new release definition and choose the Empty template and select the Build definition you created in the steps above on the next screen:

Add a PowerShell script task and use the Select File or Folder dialog to set the Script Path field to the PowerShell script that was created from importing the profile in VS. Set the following arguments in the Arguments field:

packOutput – path to the folder with your publish output. The path provided below should work if you update the Build Definition and Project names.

path to the folder with your publish output. The path provided below should work if you update the Build Definition and Project names. pubProfilePath – path to the .pubxml file that was generated when you imported your publish profile settings into VS. The path provided below should work if you update the Build Definition, Project and .pubxml file names.

path to the file that was generated when you imported your publish profile settings into VS. The path provided below should work if you update the Build Definition, Project and file names. publishProperties – set the password for your deployment. VS keeps a local copy of the password from your publish profile settings but it is not checked in so you must provide it. Use the exact argument below and we will create an Environment Variable next for it.

For example,

-packOutput "$(System.DefaultWorkingDirectory)/BasicBuild/drop/src/TestingDeploy\bin\Release

etcoreapp1.0\publish\" -pubProfilePath "$(System.DefaultWorkingDirectory)/BasicBuild/drop/src/TestingDeploy/Properties/PublishProfiles/dotnetCoreDeploy - Web Deploy.pubxml" -publishProperties @{'Password'='$(AzureWebsiteDeployPassword)';}

Lastly, create an Environment Variable by clicking the ellipsis on the environment and choosing “Configure variables …”.

Add a variable named “AzureWebsiteDeployPassword” and set it to the password found in your publish profile setting file from Azure. Make sure to also click the lock on the far right to hide the value.

If you forget to add the password environment variable or set it incorrectly you will an error similar to:

Error Code: ERROR_USER_UNAUTHORIZEDMore Information: Connected to the remote computer ("dotnetcoredeploy.scm.azurewebsites.net") using the Web Management Service, but could not authorize. Make sure that you are using the correct user name and password, that the site you are connecting to exists, and that the credentials represent a user who has permissions to access the site. Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_USER_UNAUTHORIZED.Error: The remote server returned an error: (401) Unauthorized.Error count: 1.

Success

If you did everything correctly you should see the deployment completes successfully and updates the files on the site.

I hope this helps others who are trying to deploy ASP.NET Core 1.0 for the first time. If you have any errors or questions please feel free to add a comment below or ping me on Twitter.