Angular 2 “Primary outlet is already registered” routeLink error

17th April 2016 Angular 1 comment

EDIT: This issue was fixed in Angular 2.0.0-beta17.

If you’re using routeLinks in Angular 2 beta ([routerLink]=”[‘YourRoute’]”), you may have come across a very ugly “Primary outlet is already registered” error.


As I’m new to Angular2, I spent a good hour on trying to figure out what I was doing wrong. It turns out it’s because I was using the minified versions of Angular and its routing component. Change your script tag from




That should take care of it.

Moving the Viber Downloads folder on Windows

21st February 2016 Windows 1 comment

By default Viber on Windows downloads files from your contacts to your Documents/ViberDownloads folder. The following explains how to change this. These steps assume you have Viber installed and your account just set up.

1. Find your ViberPC folder, usually in C:\Users\USERNAME\AppData\Roaming\ViberPC\YOUR_NUMBER

2. Confirm that the viber.db file exists in this folder.


3. Download DB Browser for SQLite. The PortableApp version is enough if you don’t want to install anything.

4. Close Viber, and open the viber.db file in DB Browser.

5. Navigate to the Settings table and Browse it.

6. Find the setting called “DownloadFolder” and double-click it to edit it.

7.  Change it to the new folder that you have created elsewhere for this and click OK.

8. Save the changes by clicking the Write Changes button.


You’re done!

Upgrading Portable Class Libraries to Class Library Packages

15th January 2016 .NET, .NET Core No comments , , , ,


  1. Class Library Packages – the future of Class Libraries.

EDIT:.NET Core and DotNet/NETStandard is a moving target at the moment, so this information may now be out of date. I will update this once .NET Core RC2 is out.


The following assumes you have installed the ASP.NET and Web Tools 2015 (RC1 Update 1) update to VS2015.


Upgrading a Portable Class Library to a Class library Package isn’t the easiest task, but this should be of some use if you need to do it.


I upgraded one of my own PCL’s to a Class Library Package, which can be found on GitHub and NuGet.

It should be noted several of these steps are not technically required, but ensure the upgrade will match a fresh Class Library Package solution.

Solution cleanup

1. I checked out the source code to the PCL from GitHub.

2. Class Library Packages place their source code into a “src” folder and test projects into a “test” folder according to the global.json file. So I re-organised the source code and tests into these folders.


3. As Class Library Packages also use “src” and “test” folders in the solution, I added “src” and “test” solution folders and moved the projects to the appropriate folders. I also added an additional “Solution Items” folder.


4. The final change to the solution was to add a global.json file to the “Solution Items” folder, containing the .NET Core version I wished to use for the solution. I then saved the solution.

Project upgrade

The following steps are essentially the same for all upgrades to any Class Library Package.

1. I added a “project.json” file to the “Imgur.API” project containing the default project.json content from a new Class Library Package.


2. I closed the solution and deleted the “Imgur.API.csproj” file in “src\Imgur.API”. I replaced it with a “Imgur.API.xproj” containing this default content from a fresh Package project.

3. I manually edited the solution file “Imgur.API.sln” and changed the project type Guid of the “Imgur.API” project from “{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}” to “{8BB2217D-0F2D-49D1-97BC-3654ED321F3B}”. I also changed the filename from “src\Imgur.API\Imgur.API.csproj” to “src\Imgur.API\Imgur.API.xproj” and saved the solution.

4. I then re-opened the solution. After a few seconds the project will be recognized

5. I deleted the “packages.config” file from the project.

6. In the AssemblyInfo.cs file, I removed any AssemblyVersion attributes as these are controlled by the project.json file now.

Additional steps

The following steps are specific to this particular PCL because of the frameworks I want to support.


These errors are caused by my desire to support several frameworks (.NET 4.5, .NET Platform Standard 5.4/1.1). Each of these frameworks need the assemblies and dependencies they depend on explicity defined. This is a very tedious process at the moment, although Microsoft are promising a “first class” experience with regard to this eventually. In the meantime tools like the ReferenceGenerator help, as does ildasm.exe.

Adding framework assemblies

For example, the project will not compile because there is a missing reference to HttpClient. The Intellisense is pretty clear and shows that a reference to System.Net.Http is required for the regular .NET 4.5 framework.


Simply add the assembly reference directly in the project.json file.

Adding framework dependencies

Similar to framework assemblies, .NET Platform Standards required assemblies to be defined as dependencies. You can add dependencies in the project.json file.

What’s left?

That’s it for the Class Library Package, but you may run into problems with Unit Test projects as for now the Visual Studio Test project doesn’t recognize xproj projects. You’ve got a couple of options here.

  1. Import the DLL using the Browse option when adding a reference. Add the DLL found in the “net45” directory. This is old-school and not a great solution because the tests aren’t executed under all the frameworks you specified, but it does work. I admit that I’m using this option until the Test project supports xproj.
  2. Use xUnit Test projects. I ended up rewriting my tests eventually.

Configuring frameworks for a Class Library Package

15th January 2016 .NET, Microsoft No comments , , , ,


  1. Class Library Packages – the future of Class Libraries.


The following assumes you have installed the ASP.NET and Web Tools 2015 (RC1 Update 1) update to VS2015 and that you then created a Class Library Package project. After opening the project, open the project.json file. This is where you configure the vast majority of settings for the package.

  "description""Demo Class Library Package",
  "authors": [ "Damien Dennehy" ],
  "tags": [ "" ],
  "frameworks": {
    "net451": { },
    "dotnet5.4": {
      "dependencies": {

Understanding the default frameworks

You’ll notice that by default package targets the full .NET Framework 4.5.1 and the .NET Platform Standard 5.4 by using the target framework monikers of “net451” and “dotnet5.4”. So what’s 5.4? The documentation (as of Jan 2016) for the Platform Standard only goes up to 1.4.


It turns out “dotnet5.4” is actually “netstandard1.3”. Remember this is all beta stuff – it’s changing and not documented well. I assume RC2 will resolve this. There’s a legitimate reason for the change (because the word “dotnet” is used everywhere) and “netstandard” matches Platform Standard I guess. The team are doing really great work on .NET Core and on the .NET Platform Standard but at the moment it’s a little frustrating to have to find out all of this from reading issues and source code on GitHub. I know that the reason there isn’t any reference to “dotnet” on the documentation is probably because they don’t want people using a legacy moniker, but the reality of it is that it’s the only one that works right now.

This mapping may be of some benefit:


Configuring the default frameworks

As previously mentioned, the default .NET Platform Standard as of RC1 is 5.4, or really “netstandard1.3”.

According to the official documentation “If a library targets .NET Platform Standard version 1.3, it can only run on .NET Framework 4.6 or later, Universal Windows Platform 10 (UWP), DNX Core 5.0 and Mono/Xamarin platforms.” This limits the use of the library, so let’s downgrade the two default frameworks to maximize compatibility.

The documentation states that .NET Framework 4.5 is the minimum required for a .NET Platform Standard, so “net45” is the lowest we can go. The version of “netstandard” you need to choose is up to you and dependent on what APIs you need; for some of my libraries I need “System.Net.Http” (which is available in “netstandard1.1”) so for now “dotnet5.2” will do.

For the record yes, this is very confusing and not well documented. But the team’s working on that apparently.

Back in the project.json file change the “net451” moniker to “net45” and change the “dotnet5.4” moniker to “dotnet5.2”. Save the file and the library will take a few moments to retarget, and you should see a change under the “References” section of the project.


When you downgrade the frameworks you may get an error in AssemblyInfo.cs:


This is resolved by removing the Com Guid reference in the file; as ComVisble is set to false by default this would have been irrelevant anyway.


The project should now build correctly.

To ensure a stable library, revert to stable dependencies in the “dotnet5.2” framework.


Selecting additional frameworks

The platform standards documentation has a list of Target Platforms that can be used.

Do you need to create additional frameworks in project.json for all of them?
No – going forward the “dotnet” or “netstandard” moniker is a catch all moniker that should allow the NuGet client to figure out what’s required. Oren Novotny has a really great post on this, but in short having at least a “net45” and “dotnet” moniker allows the following frameworks to use your library:

  • Desktop.NET 4.5 & 4.6
  • ASP.NET 4.5 & 4.6
  • ASP.NET 5 on Desktop.NET Framework & CoreCLR
  • DNX Console App on Desktop.NET & CoreCLR
  • Windows 10 UWP

That’s a lot of coverage, but it’s not enough for Windows 8 Phone or Windows 8 Store Apps. Xamerin and Mono coverage is also a work in progress.

.NET Portable Framework

If your library will be consumed by a classic Portable Class Library (and odds are it could be), you may need to support the .NET Portable Framework. If you do not the following error will be encountered when trying to install your package into a PCL.


You’ve got a number of choices to resolve this.

  1. Add a Portable framework

Stephen Cleary has a pretty definitive list of portable framework profiles. For the purpose of this package Profile 111 should be enough; it allows the PCL to be used on .NET Framework 4.5, Windows 8.0, Windows Phone 8.1. The moniker of the framework will therefore be “.NETPortable,Version=v4.5,Profile=Profile111”.

Open the project.json file again and add the new moniker.  Note that similar to the “dotnet5.2” framework you must explicitly define the dependencies – in this case framework assemblies – that the portable profile requires.

  "frameworks": {
    "net45": { },
    "dotnet5.2": {
      "dependencies": {
    ".NETPortable,Version=v4.5,Profile=Profile111": {
      "frameworkAssemblies": {

Save the file and the library will take a few moments to retarget, and you should see a change under the “References” section of the project.


This seems the best of both worlds but there appears to be a problem with this approach. It seems that there is an incompatibility with supporting “dotnet”/”netstandard” and .NET Portable frameworks in a Class Library Package. It’s a shame that this doesn’t work as it’s would have been a really cool way to be backwards compatible with the Portable framework. I’ve had mixed luck with this with my PCLs – some work, other’s do not.

2. Do nothing and wait for PCL support

The official docs state that full PCL support is coming – “PCL projects will be able to consume packages built for .NET Platform Standard (netstandard1.x)”.  This will be available around Feb 2016 in RC2.

Recommended Reading

Creating a NuGet Package in 3 easy steps using a Class Library Package

15th January 2016 .NET, .NET Core No comments , , , ,

Believe it or not Scott Hanselman’s 7 step guide to creating a NuGet Package is now five years old, and it’s fun to see how far NuGet has come in that time. Does it still take 7 steps to create a NuGet package? Not even close using a Class Library Package.

Step 0 – Install the ASP.NET and Web Tools 2015 (RC1 Update 1) update to VS2015.

Step 1 – Open VS2015 and create a new Class Library Package project.
Note that the name of the library becomes the Package ID if uploaded to NuGet/MyGet, so it’s not really editable afterwards – make sure you get it right.


Step 2 – Add your code to the library and configure the project.json file with any changes you may need.
For the purpose of this demo we’ll leave the project.json file as default.

  "description""AwesomeSoft.TextConverter Class Library",
  "authors": [ "Damien Dennehy" ],
  "tags": [ "" ],
  "frameworks": {
    "net451": { },
    "dotnet5.4": {
      "dependencies": {

Step 3 – Right-click on the project and select the Properties menu item. In the Build tab select “Produce outputs on build”. Build the project.


Step 4 – There is no Step 4, you’re done. Go to the artifacts folder in your project, in my case “artifacts\bin\AwesomeSoft.TextConverter\Debug”.
You should see the NuGet package already created, and the folders targeting each framework specified earlier.


Now that you have the .nupkg package, you can upload it to NuGet, MyGet, or create your own NuGet server and upload it there.

Happy packaging!



  1. Configuring frameworks for a Class Library Package.
  2. Upgrading Portable Class Libraries to Class Library Packages.

Class Library Packages – the future of Class Libraries

15th January 2016 .NET, .NET Core No comments , , , ,

With all the recent additions to .NET (.NET Core, ASP.NET 5 etc), it’s important to keep your Class Libraries up to date so they can be used on as many platforms as possible. If you haven’t been keeping up, here are the main Class Library types in Visual Studio.

Class Library


If you’ve worked with .NET for pretty much any period of time you’ve probably used a Class Library (CL) project. Class Libraries have been the de facto option for sharing code in .NET for the last decade, and for the most part they worked well.

Class Libraries assume that they will have access to the full .NET Framework when they run, so it will allow you to write code without any API restriction. Class Libraries aren’t a “one size fits all” solution however, so you have to compile your code multiple times to target multiple platforms and make use of #if to hide code from the platforms that don’t support it. This was – at best – messy. For example the Newtonsoft.Json library is compiled separately for .NET 2.0, 3.5, 4.0 as part of its build process.

Class Library (Portable)

Portable Class Library

A  couple of years ago Microsoft realized they needed to solve these problems and introduced Portable Class Library (PCL) projects. It allows you to target platforms you wish to have the library work on, and the PCL will only allow you to use APIs that are guaranteed to work on the platforms you specified.

PCLs can be converted to NuGet packages easily so PCLs became pretty popular.

PCLs aren’t perfect. You need to create NuGet packages manually, and targeting platforms is a well documented nightmare. I’m not going to talk in detail about this part, because I’ve died a little inside because of it over the years. But perhaps their biggest flaw is that they aren’t particularly future compatible – the PCL may not allow a platform that is perfectly capable of running it simply because it wasn’t defined at the time. The addition of .NET Core means that your PCL may not work on that either.

Class Library (Package)


To solve these problems, Microsoft created the .NET Platform Standard. The official documentation explains it pretty well; instead of allowing your libraries to target platforms it’s best to target platform standards – any platform that supports the standard will be capable of running your library. You can use existing PCL’s for this, but if you’re going to be making new class libraries and NuGet packages you’re better off using the new Package Class Library project. It has a number of advantages:

  1. Automatic creation of the NuGet package.
  2. Multi-target class libraries – the DLLs are cross-compiled into the frameworks you specify.
  3. Backwards compatible – existing PCL’s can consume Class Library Packages.
  4. Future compatible – all Class Libraries will be built this way in a few years.


  1. Creating a NuGet Package in 3 easy steps using a Class Library Package.
  2. Configuring frameworks for a Class Library Package.
  3. Upgrading Portable Class Libraries to Class Library Packages.

Getting ready for .NET Platform Standard and Windows Universal Apps

15th January 2016 .NET, .NET Core No comments , ,

.NET’s changed massively in the last two years and it’s an exciting time to continue to work in that eco-system. It’s important to make sure that as a library owner or maintainer that your libraries work on as many platforms as possible, especially with the new .NET Platform Standard and Windows Universal Apps.

This is easier said than done however. I maintain a handful of libraries publicly on NuGet and privately on corporate environments, and I’ve encountered a number of gotchas in upgrading libraries recently. The following may be of some benefit to those wishing to target .NET Core and other frameworks.

  1. Class Library Packages – the future of Class Libraries.
  2. Creating a NuGet Package in 3 easy steps using a Class Library Package.
  3. Configuring frameworks for a Class Library Package.
  4. Upgrading Portable Class Libraries to Class Library Packages.

DNX SDK install failure for Visual Studio 2015

26th July 2015 .NET 1 comment ,

If like me you installed Visual Studio 2015 on week one, you may have encountered the “DNX SDK version ‘dnx-clr-win-’ failed to install” issue.

I’ve had this issue on both my home and work PCs which are running Windows 7. It only occurs if you using the new ASP.NET 5 Preview Templates and only when you try and build the solution.


Fortunately it’s pretty easy to fix. Close Visual Studio and follow these steps.

1. Run an elevated command prompt and type “dnvm upgrade”. This will run the .NET SDK Manager and install the runtime.


2. If the runtime starts to install, you should see the “Installing runtime” message.


3. If you are behind a proxy (like I was at work), you may receive the following error: “Unable to find any runtime packages on the feed!”. This is a false positive – DNVM can’t reach the internet to download the package feed.


4. Set the proxy environmental variable by typing “setx http_proxy http://yourproxy:yourport”.


5. Once the proxy has been set, close the command prompt, and repeat step 1. The runtime should now install.

Open Visual Studio and you should be able to build the solution successfully.

Windows XP Support – 2014 or 2104?

7th April 2014 Microsoft 1 comment

A lot of people today are saying a fond farewell to Windows XP today as from the 8th April 2014 Microsoft are no longer officially supporting it.

Or is it 2104 and we have 90 years of support left?


Skype 5 doesn’t update to Skype 6

7th November 2012 Microsoft No comments ,

Like many people this week I decided on logging into Skype today to merge my Skype and MSN accounts. Microsoft instructs you to click the “Signin with Microsoft account” to start the process.

I started Skype, but noticed a small problem – that option didn’t appear. After spending far too much time trying to figure this out, I went to and downloaded the latest version from there, just in case the auto-updater wasn’t working. As it turns out, it wasn’t.

Skype 5 vs 6

In short, check your Skype version – if you’re running Skype 5, go to and download the latest version to update you to Skype 6.

One would think this would have been tested before letting 100 million people know their accounts will no longer work in a few months.