24 Aug 2015
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.
Create Unit Tests for new Attribute
Figure: Unit Tests for RemoteRequireAttribute
Create ActionFilter that inherits from RequireHttpsAttribute | ActionFilterAttribute and implement functionality.
Figure: RemoteRequireHttpsAttribute class signature
Execute Tests. All Passing
Figure: Passing Unit Tests
View another class that inherits from ActionAttribute. VS2015 Code lens now shows 5 of 5 tests passing.
Figure: 5 of 5 passing tests
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.
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.
16 Aug 2015
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
If you, like me have installed
dnvm on OS X via Homebrew, you will run into the following 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.
│ └── default.alias
│ ├── 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.host.dll
│ │ ├── 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
│ ├── 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.host.dll
│ ├── 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
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".
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
dnvm.sh to support
dnvm update-self from a Homebrew install. More on that at a later date.
07 Aug 2015
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.
Figure: Permission is denied.
This is a minor issue, and the fix is relatively simple
Steps to fix:
- Open Terminal
- Execute the following:
chmod +x dnu
No more issues.
Figure: Executeable dnu
29 Jun 2015
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.
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.
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.
02 Mar 2015
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