Dotnet core is the new kid in town, ready to build, publish and release.
Some background knowledge.
The Global.json holds the version of the dotnet sdk used. See Hanselman’s post on running multiple versions of the sdk.
This version needs to be available on compiling on the develop machine and on the build server. When you have the wrong version you get the message:
[error]GETSDKTOOLINGINFO(0,0): Error : The project is configured to use .NET Core SDK version 1.0.0-preview2-003121 which is not installed or cannot be found under the path C:\Program Files\dotnet. These components are required to build and run this project.
To overcome this, you can add the dotnet-install.ps1 as a build step (see the GitHub documentation and this post) or simply install it on your build server.
NetCore 1.0.0 version.
You can create two types of core projects with Visual Studio, DNX and NET452.
One runs on all platforms and the other one only on the windows platform. The difference can be seen in the references node in the solution explorer and the corresponding project.json. while we are going to deploy the app to Azure App Services, the Core Web Application with .NET Framework will do. No plans to move it in the future to a Linux or Osx platform.
For the build and publish activity is doesn’t really matter, as long as the proper netcore version is installed on the machine doing the build.
At this moment (12-7-2016) the hosted build isn’t updated yet with the netcore 1.0.0 framework. The build will succeed, but with the message:
Note: I expect the hosted builds will be updated soon.
All good you think, till you deploy your netcore app to an Azure App Service. When running the app afeter deployment you get this error: The specified CGI application encountered an error and the server terminated the process.
So, you need the 1.0.0 framework on the build server. What you can do is installing the core 1.0.0 framework during your release, see this post: Running the Latest .NET Core SDK on Visual Studio Team Services Hosted Build Agent. Or make your own IaaS Build server and run it in Azure Devtest Lab like this: Azure Dev Test Browser Lab for Visual Studio Team Services. #VSTS #Azure (see the VSTS agent artifact).
When your build server meets the correct netcore sdk and netcore framework you are ready to create the build, which is easy.
Take an empty build in VSTS and add four build steps, two command line, one copy files (for needed for deployments) and one publish artifacts.
The first command line runs, dotnet restore -v minimal, this commandline gets the dependencies for the projects as listsed in the project.json, see documentation.
The output will be like:
The second command runs, dotnet publish $(build.sourcesdirectory)\src \project.json --output $(build.stagingDirectory) --framework net452 --configuration Debug, this command builds (if necessary) and packs the application and all of its dependencies into a folder getting it ready for publishing.
The output will be like:
The last activities in the log are coming from the scripts section in the project.json, some gulp like functionality.
You also can decide to use dotnet build command, but this one only compiles the solution and we want to move and also deploy it to Azure App Service. The dotnet build command can be used in a Pull request build and use the dotnet publish command in the CI build on the branch. See 101 Setup, configure and work with GIT VSTS Build and Release.
The Copy files and publish artifacts build steps are making it the output ready for VSTS Release Management. In the solution there is a PowerShell script and settings file for the deployment (see release paragraph), we need those as build artifacts together with the dotnet publish output.
And for sure add more steps at will, dotnet test for example.
The release of a netcore 1.0.0 application on an Azure App Service doesn’t differ that much from previous deployment methods, MSDeploy can still be used for the deployment.
You can see the details when you publish the application via Visual Studio.
To use this MSDeploy in VSTS Release Management you can add an Azure Powershell shell release step, which calls a PowerShell function with several parameters.
To create a PowerShell script file which executes MSDeploy, look at: http://trycatchfail.com/blog/post/The-trials-and-tribulations-of-using-MSDeploy-with-PowerShell
For the deployment I’m using a little tweaked version of this script: Publishes a Windows Azure Web App from a Web Deploy Package using MSDeploy it accepts a publish settings file, which makes our live easier.
The used PublishSettings file can be downloaded from the Azure App Service and put in the solution.
Note: remove the password from the settings file and put it in the release step as parameter.
The release steps will look like this:
The second powershell step is the post to slack step.
The output will look like this:
Happy build and releasing...