How to build an MSDeploy package for an ASP.Net 5 app that targets .Net Core

Question

I'm trying to configure Visual Studio Online to continuously deploy my ASPNET 5 application to an Azure webapp as described in this tutorial from the Team Foundation Build docs: https://msdn.microsoft.com/Library/vs/alm/Build/azure/deploy-aspnet5

I have followed all the steps and everything is working great. By default this script deploys a build of my app that targets the full .Net 4.5.1 DNX so I decided to try and modify it to deploy for .Net Core.

The build script creates its deployment package by calling: msbuild.exe /t:Build,FileSystemPublish After turning up log verbosity and reading through the relevant msbuild files I have learned the following:

The "Build" target ultimately uses dnx.exe to compile the project. Because the project.json file includes both dnx451 and coreclr TFMs this step produces build output for both frameworks - so far so good.

However, the FileSystemPublish target seems to only output an msdeploy package that targets the .Net 4.5.1 runtime. From the logs I could see executing the FileSystemPublish target ultimately issues a "dnu publish" command and in my cases passes "dnx-clr-win-x86.1.0.0-beta6" as the -runtime parameter. When I followed the breadcrumbs to find out where it was getting the value "dnx-clr-win-x86.1.0.0-beta6" from I eventually ended up in the "GetRuntimeToolingPath" task in Microsoft.DNX.Tasks.dll. This task seems to look in global.json to determine the correct runtime to use but strangely appears to internally override this value with "x86" and "clr" before creating the return string.

If I have interpreted things correctly, it seems that the FileSystemPublish target (in Microsoft.DNX.Publishing.targets) is essentially (indirectly) hard wired to use the x86, full .Net framework DNX when it produces its package output. At this point I am stuck for how to get this build process to produce a .Net Core package.

My question is why would FileSystemPublish be coupled to the x86 full .Net DNX and given this appears to be the case (unless I am mistaken) what is the recommended way to produce an msdeploy package for an ASPNET 5 app that targets .Net core?

EDIT: For now I have a workaround. I can pass /p:RuntimeToolingDirectory="C:\Users\buildguest\.dnx\runtimes\dnx-coreclr-win-x64.1.0.0-beta6" as a parameter to msbuild. This overrides the default logic in the GetRuntimeToolPath and forces it to use .Net Core. This works but feels like a hack so I'm leaving the question open for a better answer.

Answer 1

To publish Core CLR, you can pass the msbuild parameter 'PublishDNXVersion' as dnx-coreclr-win-x64.1.0.0-beta6.

msbuild <project>.xproj /p:deployOnBuild=true;PublishDNXVersion=dnx-coreclr-win-x64.1.0.0-beta6

Answer 2

From the Old Azure portal within the Web App section of it on the Dashboard page of your particular Web App. [deep breath]

On the right hand side is a section that says "set up publishing with visual studio online". Clicking on that link will walk you through the necessary steps to set up continuous deployment from a visual studio online repository (either git or tfs based)

Since that is a mouthful, I have provided a link to a tutorial which walks you through the entire process: https://azure.microsoft.com/en-us/documentation/articles/cloud-services-continuous-delivery-use-vso/#step3

Answer 3

Had the same problem with .NET Core RC2-preview1 tooling. My solution: Add SDKToolingDirectory to my .xproj with a proper path to .NET Core installation:

<PropertyGroup>
    <VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">14.0</VisualStudioVersion>
    <VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
    <SDKToolingDirectory>C:\Program Files\dotnet</SDKToolingDirectory>
</PropertyGroup>

Answer 4

I had some luck with this by passing the following parameters into the Bundling step of my Visual Studio Online build process:

/p:Bundle64BitRuntime=true /p:BundleCoreClrRuntime=true

This causes my publish to leverage the 64 bit CoreCLR Runtime when it runs through msbuild.exe.

I figured this stuff out by digging through the Microsoft.DNX.Publishing.targets file (found at C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\Web) and looking for variables I could pass in as properties. Regarding runtime, this seems to be an interesting snippet:

<GetRuntimeVersion 
  Condition="'$(IgnoreDNXRuntime)' != 'true'"
  RuntimeVersionOverride="$(PublishDNXVersion)"
  TargetDNXVersion="$(_DefaultDNXVersion)"
  RuntimeToolingVersion="$(RuntimeToolingVersion)"
  Want64Bit="$(Bundle64BitRuntime)"
  WantCoreClr="$(BundleCoreClrRuntime)">
  <Output PropertyName="FinalPublishVersion" TaskParameter="RuntimeVersion"></Output>
</GetRuntimeVersion>

There's probably a little bit(?) of risk here in terms of future proofing your build routine against future changes to variables names. But, you know, beta software and all that :)

Good luck!