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  /build.sh

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.


Azure Web Sites support IP restriction in the web config, as demonstrated by Stefan Schackow's MSDN Blog.

I then add the following to my web.config

While this works great for Azure, for local builds, you may encounter:

HTTP Error 500.19 - Internal Server Error

The requested page cannot be accessed because the related configuration data for the page is invalid.

Module IpRestrictionModule
Notification BeginRequest
Handler ExtensionlessUrlHandler-Integrated-4.0
Error Code 0x80070021
Config Error This configuration section cannot be used at this path. This happens when the section is locked at a parent level. Locking is either by default (overrideModeDefault="Deny"), or set explicitly by a location tag with overrideMode="Deny" or the legacy allowOverride="false".

The culprit was the snippet at the bottom of my applciationHost.config

<location path="" overrideMode="Deny">

Commenting out the entire location tag resolves the issue.

Microsoft Azure has successfully lured me in with their promises of a VS2014 CTP VM.

Recently completed MVC training was my first introduction to Azure, so outside a learning environment the VS CTP was a chance to dust off the account.

Trial Account & Credit Card Registration

While I was hesitant to hand lover my Credit Card number, expecting the usual incurred charges if you don't cancel, Azure surprised me with being up front about what my next bill would be, and that it would be 0.00


Having that on the first page that opens when I click on billing, is transparency that will go along way with those who are less trusting of cloud computing.

Spooling up the VS 2014 VM

All very straight forward, select add, and select VM for Gallery for existing images.


Select the VS2015 CTP



Minimum required info to get me started... not bad.




Now if this is your first VM, note the Cloud Service DNS name will be reused for all VM's.

Remote Access to your VM

Under endpoints check the RDP public port. This will access your machine via NAT.


RDP into <CloudServiceDMSName>.cloudapp.net : 59276 (in is case), and you're in.

AzureEndPoints AzureDesktop

After Integrating Visual SVN & Jira with Slack, I decided to replace the existing bat file calling a python script with something a bit more extensible.

I also wanted to change Slack's SVN integration to a custom one that would point to the revision on our Fisheye server, which would show the changes made and link to Jira when we added the  ticket <ProjectName-Ticket#> in the Commit Notes, which Fisheye does out of the box

.Net REST Console App

I decided to build a console app that call the slack incoming webhooks API. It needed to:

  • Accept a channel name, title & API Token
  • Accept a SVN Projectname & revision number to call SVNlook & get author & log details. (When fired by SVN Server)
  • Accept a Jenkins name to hit up the Jenkins JSON API for build details
  • Parse success/fail messages and convert them to the Slack notification color names (good, warning & danger)
  • Create a JSON Object
  • Post the JSON object to the slack API
  • A verbose option for debugging
  • Manually enter message text, and author to integrate with other apps down the line.

.Net Apache Common CLI

As there is quite a large set of parameters, I made use of the .Net port of the Apache Commons CLI libraries by Akutz. This handles all aspects of console arguments, while adhering to best practices and existing expectation when passing argument to a cone application.

An example of the init & usage syntax is below.

options.AddOption("a", "apiToken", true, "API token.");
  if (_apiToken == null && Globals.CMD.HasOption('a'))
     _apiToken = CMD.GetOptionValue('a');
  return _apiToken;

This is a huge help in argument management, and also handled the help messages.

There was very little documention on .Net CLI, though using the Apache usage documentation was fine, just remeber to capitalise the method name i nthe .ent vesrion, for example option.AddOption instead  of option.addOption, option.HasOption instead of option.hasOption and so on.

And one last catch, the Apache DefaultParser was called the BasicParser in the .Net port.

BasicParser parser = new BasicParser();
CommandLine commandLine = parser.Parse(options, args);


Restsharp likely needs no instruction has a library for simple Rest messaging.

I found it very easy to use, apart from one hitch that had me stumped for much longer than I would like to admit.

The following code (I thought) added the query string with the API token for slacker to the url.

 var request = new RestRequest(resource, Method.POST);
request.AddParameter("token", "CfkRAp1041vYQVb");

However, doing so, and then trying to add any details to body via request.AddBody resulted in it not being added, nor raising an error attempting to do so.

request.RequestFormat = DataFormat.Json;
request.AddBody(json); //Ignored if AddParameter was previously called

Opening up Wireshark showed that the query string was being added to the body.

After a bit of head scratching I found that AddParameter took a third argument,

request.AddParameter("token", "CfkRAp1041vYQVb", ParameterType.QueryString);

SVN versioning

As I planned to use this exe on various production servers, automated SVN versioning was the next logical step.

I utilised Avi Turner's SVN versioning script on stackoverflow to update the $WCREV$ tag I inserted into the AssemblyFileVersion in AssemblyInfo.cs and rev.subwcrev-template used to track the currently checked out & built version.


Finally, I though I would try my hand at weaving assemblies into the .exe for a single file deployment.

I settled on Costura.Fody as many had said that it Just Works™

After adding both Fody and Costura.Fody via the VS2013 package manager, I assumed the various build xml files automatically would need to be tweaked. Though, when I hit build, I realised that I didn't need to touch them at all, and ended up with a exe file where every assembly set to copy local, in this case RestSharp, was embedded into the exe.