Now that the .net Core bits are RTM I wanted to start playing with a new website to get the feel for the new toolchain and the development/deployment lifecycle around .net core.
The ultimate goal was to have a continuous delivery pipeline going from an approved pull-request to a successful CI build and use the VSTS online release functionality to “approve” of a build and kick off deployment to an existing App Service on Azure.
I had not looked at .net core since the RC1 bits, so understanding the updates to the toolchain, and the deprecation of DNVM and DNX and use of dotnet took at while for me to fully grasp. I started by uninstalling the previous bits, and just installing the VS Tooling preview 2 and the .net Core SDK Preview 2 (x64). Actually I started looking for where to get DNVM, and that took me another couple hours …
Site and build definition
I went with a pure .net core site checked it in to VSTS and started creating a new build definition. Donovan Brown did a nice writeup of how to do this for the .net core RC2 bits that made it to the official documentation. But there was a few kinks that needed to be worked out
Build agent problems
First of all, the hosted build agents in VSTS does currently only build .net core RC2. When running a dotnet restore against the project.json file, dependency errors start popping up. You will get a lot of these:
The dependency Microsoft.CodeAnalysis.Common 2.0.0-beta1 does not support framework .NETCoreApp,Version=v1.0
I googled it and found links to people who just had to update to the latest SDK and VS toolkit. So I fired off a Command Line build step with dotnet –version and it showed that the hosted agent is running RC2 dotnet. No love there. Tweeted the @vsteam to hear when hosted build agents have the latest sdk, but haven’t heard anything.
No way around having a local build agent, that I installed on a bare bones local VM (Windows Server 2012R2 with all updates), along with only the .NET Core SDK (x64) and the downloaded build agent. Nothing else was on the machine. After that, the dotnet restore/build/publish steps from the Donovan Brown writeup worked perfectly.
The next step was to add the “Deploy AzureRM Web App” step, as I am using the Resource Manager based Web App, and not the old (as in last year) Web Sites. Behind the scenes, this step uses the msdeploy.exe web deploy tool. This gave me three problems:
The “Deploy AzureRM Web App” step expects to have the Azure Powershell commandlets installed. No problem. Grab them from this page.
The next problem was not an error – just that nothing happened when running the step. It exited without reporting an error, but nothing new was deployed to my site. To troubleshoot I logged on to the build server and ran the MSDeploy.exe from there. It blew up, moaning about missing the .net framework 2.0:
So … install the .net framework 2.0 on the build server if you want to use MSDeploy.exe.
Deployment step problems
The next error I got when running the “Deploy AzureRM Web App” was:
Error: Source does not support parameter called 'IIS Web Application Name'. Must be one of ().
Turns out the MSDeploy.exe command that the step executes looks like this:
-setParam:name="IIS Web Application Name",value="myazuresite"
Well … an hour of googling and reading documentation later, I can see that I had to create a parameters.xml file instead of using the –setParam as the azure deploy step does.
So… I added this parameters.xml to my site:
name="IIS Web Application Name"
I then removed the azure publih step, added a “Command Line” step with arguments:
-verb:sync -source:package="$(Build.ArtifactStagingDirectory)\website.zip" -dest:auto,ComputerName=https://myazuresite.scm.azurewebsites.net/msdeploy.axd?site=myazuresite,UserName="$myazuresite",Password=mytoken,AuthType="Basic" -enableRule:AppOffline -setParamFile:"c:\agent\_work\2\s\myazuresite\parameters.xml"
And that ran without a problem and deployed to my site as expected.
Next step is to deploy the site from the Release functionality with the approval functionality to only deploy some builds.