Visaul Studio 2015: Code Lens Unit Test Attribution bug

I am currently working on a legacy application that has recently had a "solution" upgrade to work with Visual Studio 2015. During the course of my work I have encountered minor Code Lens attribution bug.

The bug essentially attributes test results of a child class, to the base class from which it is inherited. The test results are then propagated up the class hierarchy to all classes which inherit from the base class.


  1. Create Unit Tests for new Attribute Figure: Unit Tests for RemoteRequireAttribute Figure: Unit Tests for RemoteRequireAttribute

  2. Create ActionFilter that inherits from RequireHttpsAttribute | ActionFilterAttribute and implement functionality. Figure: RemoteRequireHttpsAttribute class signature Figure: RemoteRequireHttpsAttribute class signature

  3. Execute Tests. All Passing Figure: Passing Unit Tests Figure: Passing Unit Tests

  4. View another class that inherits from ActionAttribute. VS2015 Code lens now shows 5 of 5 tests passing. Figure: 5 of 5 passing tests Figure: 5 of 5 passing tests

  5. Closer inspection of the tests shows that the are not related to this class, other than the base inherited classes. Figure: 5 of 5 passing tests are all for RemoteRequireHttpsAttribute ActionFilter. Figure: 5 of 5 passing tests are all for RemoteRequireHttpsAttribute ActionFilter.

For those of you who are wondering what my system looks like:

  • Surface Pro 3 - Max specs.
  • Windows 8.1 Fully patched and at the latest version
  • Domain Joined
  • .Net 2 through 4.6 installed and fully patched to the latest versions
  • VS2013 and VS2015 are both installed and fully patched.

ASP.NET 5 dnvm update-self on OS X

Continuing on from #687: dnu restore broken; A number of people are still finding this to be an issue. The recommended fix at this stage is to update dnvm to the latest version with dnvm update-self.

If you, like me have installed dnvm on OS X via Homebrew, you will run into the following issue:

dvnm update-self issue Figure: dnvm update expects dnvm directory in .dnx folder

As you can see from the following tree .dnx output, the dnvm directory is not present.

├── alias
│   └── default.alias
└── runtimes
    ├── dnx-mono.1.0.0-beta4
    │   ├── bin
    │   │   ├── Microsoft.CodeAnalysis.CSharp.Desktop.dll
    │   │   ├── Microsoft.CodeAnalysis.CSharp.dll
    │   │   ├── Microsoft.CodeAnalysis.Desktop.dll
    │   │   ├── Microsoft.CodeAnalysis.dll
    │   │   ├── Microsoft.Framework.ApplicationHost.dll
    │   │   ├── Microsoft.Framework.DesignTimeHost.Interfaces.dll
    │   │   ├── Microsoft.Framework.Runtime.Interfaces.dll
    │   │   ├── Microsoft.Framework.Runtime.Loader.dll
    │   │   ├── Microsoft.Framework.Runtime.Roslyn.Common.dll
    │   │   ├── Microsoft.Framework.Runtime.Roslyn.Interfaces.dll
    │   │   ├── Microsoft.Framework.Runtime.Roslyn.dll
    │   │   ├── Microsoft.Framework.Runtime.dll
    │   │   ├── Newtonsoft.Json.dll
    │   │   ├── System.Collections.Immutable.dll
    │   │   ├── System.Reflection.Metadata.dll
    │   │   ├── dnu
    │   │   ├── dnx
    │   │   ├──
    │   │   ├── dnx.mono.managed.dll
    │   │   └── lib
    │   │       ├── Microsoft.Framework.DesignTimeHost
    │   │       │   ├── Microsoft.Framework.DesignTimeHost.dll
    │   │       │   └── Microsoft.Framework.NotNullAttribute.Internal.dll
    │   │       ├── Microsoft.Framework.PackageManager
    │   │       │   └── Microsoft.Framework.PackageManager.dll
    │   │       └── Microsoft.Framework.Project
    │   │           └── Microsoft.Framework.Project.dll
    │   ├── dnx-mono.nuspec
    │   └── package
    │       └── services
    │           └── metadata
    │               └── core-properties
    │                   └── ddd70229659a44fe8e4fbc08b9d84d87.psmdcp
    └── dnx-mono.1.0.0-beta6
        ├── bin
        │   ├── Microsoft.CodeAnalysis.CSharp.dll
        │   ├── Microsoft.CodeAnalysis.dll
        │   ├── Microsoft.Framework.ApplicationHost.dll
        │   ├── Microsoft.Framework.DesignTimeHost.Abstractions.dll
        │   ├── Microsoft.Framework.Runtime.Abstractions.dll
        │   ├── Microsoft.Framework.Runtime.Caching.dll
        │   ├── Microsoft.Framework.Runtime.Compilation.DesignTime.dll
        │   ├── Microsoft.Framework.Runtime.Loader.dll
        │   ├── Microsoft.Framework.Runtime.Roslyn.Abstractions.dll
        │   ├── Microsoft.Framework.Runtime.Roslyn.Common.dll
        │   ├── Microsoft.Framework.Runtime.Roslyn.dll
        │   ├── Microsoft.Framework.Runtime.dll
        │   ├── System.Collections.Immutable.dll
        │   ├── System.Reflection.Metadata.dll
        │   ├── dnu
        │   ├── dnx
        │   ├──
        │   ├── dnx.mono.managed.dll
        │   └── lib
        │       ├── Microsoft.Framework.DesignTimeHost
        │       │   ├── Microsoft.Framework.DesignTimeHost.dll
        │       │   ├── Microsoft.Framework.NotNullAttribute.Sources.dll
        │       │   └── Newtonsoft.Json.dll
        │       ├── Microsoft.Framework.PackageManager
        │       │   ├── Microsoft.Framework.NotNullAttribute.Sources.dll
        │       │   ├── Microsoft.Framework.PackageManager.dll
        │       │   └── Newtonsoft.Json.dll
        │       └── Microsoft.Framework.Project
        │           └── Microsoft.Framework.Project.dll
        ├── dnx-mono.nuspec
        └── package
            └── services
                └── metadata
                    └── core-properties
                        └── 6586fbcfbbe442c4a108a4b34abfbae8.psmdcp

22 directories, 53 files

This is due to Homebrew installing packages into /usr/local/Cellar/ and then symlinking to /usr/local/bin by default.

Normally I would advise updating dnvm via Homebrew like so:

brew update; brew upgrade dnvm;

However as Brennan Conroy mentions: "Unfortunately we don't support upgrade through homebrew".

Unfortunately we don't support upgrade through homebrew. Figure: Unfortunately we don't support upgrade through homebrew.

The correct method as of August 16th 2015 to upgrade dnvm if installed via Homebrew is the following:

brew remove dnvm; brew install dnvm;

Personally, I find this to be somewhat of an issue, though given the beta nature of ASP.Net 5 it's to be expected. At this stage I am investigating the viability of a patch to to support dnvm update-self from a Homebrew install. More on that at a later date.

ASP.NET 5 Beta 6: dnu restore broken #687

I have recently updated to the latest ASP.NET 5 Beta on my OS X development machines. One of the first stumbling blocks that I ran into was issue #687: dnu restore broken.

dnu execution error. Figure: Permission is denied.

This is a minor issue, and the fix is relatively simple

Steps to fix:

  1. Open Terminal ⌘+space Terminal
  2. Execute the following:
    cd ~/.dnx/runtimes/dnx-mono.1.0.0-beta6/bin/
    chmod +x dnu

No more issues.

Correct permissions for dnu execution. Figure: Executeable dnu

Goodbye AussieWeb. Hello SSW.

After more then 13 years, I have made the decision to move on from my Software Engineering role with Monte Huebsch and team at AussieWeb and take on a Senior Software Architect position with Adam Cogan and his team at SSW.

Goodbye AussieWeb

AussieWeb has been my home for more then a decade. When I started, AussieWeb was a small business, with only 4 permanent part-time employees; .Net was still in it's early releases (1.0 and 1.1), and the main business was Website Development & Hosting (partnered with Lloyd Ernst's WebCentral).

Today: AussieWeb employees 10 full time staff on generous salary & benefits packages; while the business itself has transformed from a Website Development & Hosting provider to one of the leading Google AdWords Partners in the Asia-Pacific Region. The core technology stack as I am leaving it, is .Net 4.5.1, SQL Server 2008R2 (and SQL 2014SP1), Entity Framework Code First, and ASP.NET MVC 5.

My time at AussieWeb has allowed me to do things that I would never have been able to do if I had taken the normal corporate developer route. I was able to live in different cities & countries, work remotely during a period in time where the idea of "remote" workers was still a new, untested and fraught with dangers and generally follow the path I decided was the most appropriate at the time. Ultimately I had complete flexibility as to when and where I worked; the technology stacks, platforms and devices I worked on/from. It was a dream job, with a steady paycheck. All the benefits of the "Nomadic Entrepreneur"/"Tropical MBA" lifestyle, without the responsibility of having to worry about meeting costs and payroll.

Though ultimately family life has caught up.

Hello SSW

I was introduced to SSW through the Brisbane .Net User Group, to be frank, I was impressed by the level of knowledge displayed by their Brisbane staff. SSW at this point feels like an environment where I can continue to grow my craft and expand my knowledge.

Though my official start date with SSW is July 1st 2015, I have been working with the Brisbane Team in a part time capacity since June 1st 2015. This has allowed me to ease myself into SSW's work-flow and methodologies, though not without some level of pain. It's not always easy to move from having complete freedom to following the rules

To date: I have pushed changes to the SSW Website, Sugar Learning and have started working with Brisbane Catholic Education on one of their internal Information Systems.

So a final Goodbye to my coworkers of 13+ years and AussieWeb, and hello to all of the team at SSW.

How to fix your Python virtualenv after a Homebrew Python upgrade

Do you manage your OS X Python installation with Homebrew? Have you recently upgraded Python?

In my case it was a Python 3 point release; from 3.4.2 to 3.4.3. The downside is that this is enough to invalidate virtualenv's symbolic links.


~: cd ~/src/my_app
~/src/my_app: source venv/bin/activate
[venv] ~/src/my_app: python
dyld: Library not loaded: @executable_path/../.Python
  Referenced from: /Users/jeremycade/src/my_app/env/bin/python
  Reason: image not found
Trace/BPT trap: 5

As I've mentioned the virtualenv symlinks to your Homebrew python installation no longer link to the correct locations. The solution is to delete, and regenerate virtualenv symlinks.

First thing, we need to ensure that the your virtualenv is not active.

[venv] ~/src/my_app: deactivate

Next, delete the offending symlinks.

~/src/my_app: find venv -type l -delete

In this case I've made use of the BSD find command that ships with OS X.

The final step is to recreate your virtualenv.

~src/my_app: virtualenv venv