Monthly Archives: November 2016

VS2017RC Tooling on Linux

What better way to try out VS2017 RC, by creating a .Net Core solution on windows, and building it on linux.

However the standard .Net core installation guide for Linux, as of the date of this post, will not build VS2017 RC projects, due to it utilising *.csproj files, and no longer creating xproj / project.json files.

Expect an error along the lines of:

[user@localhost]$ dotnet run
The current project is not valid because of the following errors:
/home/user/DotNetCoreASP(1,0): error DOTNET1017: Project file does not exist '/home/user/DotNetCoreASP/project.json'.

A version check will show that the "latest" is quite on the bleeding edge as it needs to be.

[user@localhost /opt/dotnet]$ dotnet --version

Compare this to Powershell after a VS2017 .Net Core install in the windows box.

PS C:\> dotnet --version

Initially, the only option looked to be building from the preview branch in git.

However, there is a series of preview binaries available for those looking to hit the ground running faster.

Howover, that is waye tyopo easy.

Building the .Net CLI in Linux

Let's build us the .Net CLI.

After a git clone, switch to the preview 3 branch.

git checkout -b re1/

Initally, it's going to take a while, the bash that kicks it all off is  /

The scripts go three to four deep ,at least. Adding a set -x to the top level script next to the existing set -e will give us some visibility into how the build is going.

#!/usr/bin/env bash
# Copyright (c) .NET Foundation and contributors. All rights reserved.
# Licensed under the MIT license. See LICENSE file in the project root for full license information.

# Set OFFLINE environment variable to build offline

set -e
# Enable recursive debugging for verbose output
set -x


Post Build

Once built set up a new symlink. As it will be to the same executable, dotnet, create it in a subfolder to /user/local/bin, and then remove it, and remove the folder.

sudo mkdir /usr/local/bin/dotnet-preview3-dir
sudo ln -s /home/user/dev/cli/artifacts/centos.7-x64/stage2/dotnet /usr/local/bin/dotnet-preview3-dir
sudo mv /usr/local/bin/dotnet-preview3-dir/dotnet /usr/local/bin/dotnet-preview3
sudo rm /usr/local/bin/dotnet-preview3-dir -r

You can then have a stable binary, and a build version running side by side.


One nasty looking error I bumped into was this one, in red, making it extra ominous.

$ dotnet run
/opt/dotnet/sdk/1.0.0-preview3-004056/Microsoft.Common.CurrentVersion.targets(1107,5): error MSB3644: The reference assemblies for framework ".NETFramework,Version=v4.0" were not found. To resolve this, install the SDK or Targeting Pack for this framework version or retarget your application to a version of the framework for which you have the SDK or Targeting Pack installed. Note that assemblies will be resolved from the Global Assembly Cache (GAC) and will be used in place of reference assemblies. Therefore your assembly may not be correctly targeted for the framework you intend. [/home/user/DotNetCore/hwapp/hwapp.csproj]

The build failed. Please fix the build errors and run again.

Let see, its mention Net 4.0, and a GAC< on a LInux bo-x that is running .Net Core.

Not looking good. There are no .Net 4.0 References in the project and the whole point of .Net Core is to stand alone with a dependency on Mono. As for the GAC reference, this message doesn't give is much to go on.

Until you realise all you need to do is restore the project.

dotnet restore

It does show that while the base cross-platform functionality is there, removing the legacy windows reference is going to be some time away for this fledgeling framework.


Using docker cloud can result in a black box experience should something go wrong.

This is especially the case when you provision the node from the cloud UI.

Building a stack with Docker/Dockercloud -AuthorisedKeys however, can get you SSH access, to poke around inside.

  image: dockercloud/authorizedkeys
  deployment_strategy: every_node
  autodestroy: always
    - "AUTHORIZED_KEYS=ssh-rsa h38Fh4w89fdlx-s...304KJbhn45=="
    - /root:/user:rw

This will let you add root access via your SSH cert.

Ensure you also open up port 22 on your VM

Once inside, you can take a peek at various logs using a couple of methods.

docker logs containerName
cat /var/log/upstart/dockercloud-agent.log
cat /var/log/dockercloud/docker.log