Category Archives : Tips and Tricks

Visual Studio 2015 – Using a Product Key 3


Continuing from the experience with Visual Studio 2013, the next edition – Visual Studio 2015 – was officially released to MSDN subscribers early this morning.  This edition follows the trend established in the previous edition of providing two channels of licensing – by using a Microsoft Account or by supplying a product key.

Get a Product Key

You’ll need to have an MSDN Subscription which matches the version of Visual Studio you are using.  Authenticate to MSDN Subscriptions and go to the Subscriber Downloads section. 


Here you’ll see a tab for “My Product Keys”.  In the list of keys there should be static activation keys for your account.  Find and copy out the product key for your version of Visual Studio 2015 (e.g. Enterprise, Professional, Test Professional).


  • If you don’t have a Product Key listed, as with Visual Studio 2013 it’s likely tied to the type of MSDN Subscription you have – whether you have assigned a perpetual license of not.  Whether or not Visual Studio carries a Product Key/perpetual license seems to depend on the type of MSDN subscription.
  • If you don’t have an MSDN subscription, but have instead purchased a retail copy of Visual Studio 2015 when it becomes available, there should be a Product Key with the product.  A boxed product should have a Product Key on the media (or box) and a soft copy should have a key associated with it somehow (maybe it is mailed to you?).

Install Visual Studio 2015

Once you have acquired a Product Key, the next step is to install Visual Studio 2015.  I’ve chosen to evaluate Visual Studio 2015 Enterprise edition, which replaces Premium and Ultimate editions (they have been merged into a single SKU).

image  image image

There’s some different options in this new edition (when using a custom install), the options I selected to install will absorb over 24 GB of hard drive space.  Probably best you avoid installing VS 2015 o a netbook!  If you want to minimise the install vector, unselecting the Cross Platform Mobile Development saves a lot of space.

Registering Visual Studio 2015

Once the installation completes, you’ll be able to launch the Visual Studio 2015 IDE.  You’ll be taken through the usual “first time user” wizard, which establishes your development and UI preferences.  You can skip logging in with a Microsoft account by choosing “Not now..”.

image  image

Once the IDE loads, you can select “Register Product” from the Help menu:

image  image

Once the registration dialog appears, use the “License with a Product Key” option, and enter your Product Key with the popup window.

image   image

Note: you don’t have to be online for the process to complete, so it looks like a good option for offline installs.


None!  The normalised CamelCase menus are back by default.


Documenting a ASP.NET Web API with Swagger

MVC3    +   swagger2

In this article, I’m going to take a look at some ways you could generate documentation for ASP.NET Web API.  Unless you’ve never generated a Web API website, you’ll be aware that the default templates already include functionality to generate documentation for the API which you might implement, an example of which is here at

Getting started

There’s more than a couple of articles already written about how to generate documentation for ASP.NET Web API using Swagger (and there’s a NuGet package called Swashbuckle which you can easily integrate), but I needed something less dynamic – in fact, I needed to generate static documentation representing what we’d promoted to production (point in time), as it needed to be provided for an audit.

The traditional documentation (e.g. Sandcastle Help File Builder) i clearly not viable as it documents managed code rather than the more important API interfaces and runtime models.

Luckily for me, there’s a toolset complimenting Swagger called Swagger codegen which generates client code to consume APIs, and for me – an ability to generate static HTML (courtesy of [1]) Unfortunately I couldn’t find a .NET port of Swagger Codegen, so I bit the bullet and compiled the Java binaries from the source using Maven and the latest JDK.

What you need

You need to be able to generate a Web API site which you can spin up in IIS or IIS Express.  Ideally, what you’d do is integrate the previously mentioned Swashbuckle NuGet package into your existing (or new) Web API Project. Once installed, all you need to do is change the project settings to generate a comments XML file (not a mandatory step, but useful – see image below) and then configure the SwaggerConfig.cs file which is inserted into the project under the App_Startup folder.

Enable XML comments output.

Swashbuckle NuGet packages (Swashbuckle and Swashbuckle.Core)

Here’s a really brief (minimal) implementation of the SwaggerConfig with the copious comments removed:

public class SwaggerConfig
   public static void Register()
       var thisAssembly = typeof(SwaggerConfig).Assembly;
       .EnableSwagger(c =>
          c.SingleApiVersion("v1", "API Services");
      .EnableSwaggerUi(c =>
   private static string GetXmlCommentsPath()
       var path = String.Format(@"{0}bin\Services.XML", AppDomain.CurrentDomain.BaseDirectory);
       return path;

If you compile and run, you should be able to resolve the Swagger UI, like this:



A very, very impressive dynamic documentation UI.

The key here is in the generated JSON which is accessible via the URI in the textbox, in my case it is: http://localhost:2218/swagger/docs/v1 (swagger.json)

Example swagger JSON

Converting to static documentation

Moving on to swagger codegen, you’ll also need a copy of the Java JDK. After installing the JDK (if you haven’t already), you’ll then need to ensure that the JAVA_HOME environment variable is correctly to the correct directory (NOT the runtime directory) and install/extract Maven binaries.

I used the latest JDK (1.8, 32 bit) which has the following directory: C:\Program Files (x86)\Java\jdk1.8.0_51 I also installed Maven into the Java directory and added it to the system path (the bin directory, specifically):


When ready, al you need is to extract the swagger codegen code into a local directory, browse to that directory in a command prompt and type mvn package:

image  image

Wait a while while Maven grabs all the packages

Once successfully compiled, it’s a simple matter of executing the compiled jar file.  In my case, I had placed the extracted swagger files in C:\Tools.  Open a command prompt and browse to the following location:


To generate a static HTML document for your API use the following syntax:

java -jar modules/swagger-codegen-cli/target/swagger-codegen-cli.jar generate -i http://localhost:2218/swagger/docs/v1 -l html

This produces a nice static document of your Web API:


A nice static HTML file which you can “print” to PDF, or copy and paste into Word


If your generated .json produces an empty object like this:

“Object”: {
“type”: “object”,
“properties”: {}

It could well be due to a lack of sufficient information about the data type in a response.  For example, take the following example Controller definition:

public class VersionController : ApiController
private readonly IVersionQuery _query;
public VersionController(IVersionQuery query) { Guard.That(query, "query").IsNotNull(); _query = query; }

[AllowAnonymous] public IHttpActionResult Get() { var version = _query.GetVersion(); return Ok(version); } }

What we’re missing here is an attribute which provides the return type, like this, decorating the Get() implementation:


I was assisted in making this discovery by the issues logged at [2], [3].



How IdentityServer3 Handles Client Credentials Flow

Identity Server 3 supports the Client Credentials OAuth2 grant.  I wrote a brief introduction to both OAuth2 and IdentityServer3 last month, this is a follow-on article exploring some other facets of authentication.

This is a little bit like basic authentication, in that the client (the application which wants to consume a WebAPI) passes a preshared key to ID3 in exchange for a bearer token.

The values passed from the Client to ID3 can be specified in either the HTTP/S header or body of the POST request.  I prefer specifying it in the Header.

The format is as follows:

Authorization: Basic (“Client ID” + “Client Secret”)


  • “Client ID” is the ID for the application (“Client”) in ID3
  • “Client Secret” is the unencrypted version of the client secret stored in ID3’s database
  • The Parenthesis indicates that the content should be Base64 encoded

The POST request also needs to contain the authorization flow type (client_credentials in this case) and intended scope (target) in the Body of the request.

The following PowerShell script demonstrates how to assemble a valid bearer token request:

function Hash($textToHash)
      $toHash = [System.Text.Encoding]::UTF8.GetBytes($textToHash)
      return [System.Convert]::ToBase64String($toHash)

$authUri = "https://identityserver/"
$authPostUri = "https://identityserver/connect/token"
$scope =  "someTargetApiName"
$client_id = "clientApplicationName"
$client_secret = "6FB76F91-B62D-4193-A795-FDDF405F94A2"
$grant_type = "client_credentials"
$value = Hash($client_id + ":" + $client_secret)
$auth = "Basic " + $value
$body = "grant_type=" + $grant_type
$body += "&scope=" + $scope
$resp = try { 
Invoke-RestMethod -Method Post -Uri $authPostUri -Headers @{ "Authorization" = $auth } -Body $body
} catch { $_.Exception.Response }

Which produces a HTTP POST request which looks like this:


POST https://identityserver/connect/token HTTP/1.1
Authorization: Basic c3lzdGVtQ29kZXN000JpcHQ6NkZCNzZGOTEtQjYyRC00MTkzLUE3OTUtRk000jQwNUY5NEEy
Content-Type: application/x-www-form-urlencoded
Host: identityserver
Content-Length: 55
Expect: 100-continue
Connection: Keep-Alive


Which, if successful, would return the following response from ID3:

@{access_token=dea839e9d3e09b4d4c00ba1fb479646a; expires_in=3600; token_type=Bearer}

Next up, I’ll show you how to generate the client secret and how to handle it on the client and within ID3’s database.