Jumping to Asp Net Core RC2 with DotNet CLI

The RC2 release came out mid May shortly after we pushed some toy code that uses Asp Net Core. Microsoft has a guide to jump from RC1 to RC2. This worked but there are some pitfalls that we didn’t find in circulation. Our sandbox shows the alterations we made from a nightly RC2 build using the old tool chain in the first release (i.e. 1.0.0 of Five) to the second (i.e. 1.0.1) using the DotNet tool.

We installed the preview version (1.0.0-preview1–002702) of DotNet tool (for Windows). This did not uninstall a previous version of DotNet. The old DotNet had to be manually removed prior to installing the preview. So make sure to issue a dotnet --version before editing.

The global.json has to have the correct SDK version. Earlier, We had a nightly RC2 coreclr then set the version to 1.0.0-preview1–002702. Otherwise, Visual Studio (after the preview upgrade) did not understand certain keywords in the project.json file.

The project.json file regulates if the runtime is locally installed or self-hosted. We wanted a self contained application. DotNet lets one publish for a specific runtime (i.e. like for Docker or our local Windows, win10-x64). On the Net Core site, under the Linux link, all of the different flavors of Linux with their versions are shown. We picked Debian at 8.2. This is reflected in the runtimes section of the project.json and used with DotNet publish with the -r option. Tacking on an architecture suffix was purely something we saw other people doing.

We could have made a portable application. This wasn’t the deployment style we want to use with Docker. Plus, we weren’t sure how publishing would fit in with Docker and a portable package. Our guess here was that the whole project gets copied into a Docker volume and DotNet runs off the project.json file (i.e. no DotNet publish step just restore and run). A portable application wasn’t practical due to an IO bug with Docker on Window 10 whereby the container can’t be stopped. Unfortunately, some DotNet directives for us indirectly led (i.e. a Docker problem, not Microsoft’s) to unstoppable containers.

There are already instructions floating around as to how to adjust the Startup code (i.e. mainly the WebHostBuilder and ConfigurationBuilder). Rather than regurgitate these please check out the release 1.0.1 tagged code in our Five sandbox. A good spot to find breaking changes is on the Asp Net announcements page. We publish a Debian flavor like this:

dotnet publish
  --output <Docker volume>
  --configuration Debug
  -r debian.8.2-x64

Inside the output directory, there is binary file (i.e. an executable file name Five) that can be run directly in the Debain container based of the latest DotNet Docker image. Target the Windows runtime then one gets an .exe file to test locally. From the Main entrypoint, We except command line arguments:

public static void Main(string[] args)
{
   var config = new ConfigurationBuilder()
       .AddCommandLine(args)
       .Build();
}

Once inside the Docker container (i.e. docker exec -i -t <image name> /bin/bash), we supply the binary file with a --server.urls argument to bridge the container to the outside world:

./Five --server.urls http://0.0.0.0:5000

Another thing that we need to think about is the best way to publish environment specific settings. For now, we edit our appconfig.json settings before starting the executable from Docker.

The only thing that is still not working is debugging locally against IIS Express. The launch settings are on GitHub. The Kestrel server starts fine (i.e. the configuration completes as expected) but it bombs out with an access violation.