As part of his fantastic ‘What is .NET standard‘ presentation at DDD12, Adam Ralph provided an amazing amount of detail in such a short amount of time. One of the most valuable points, which is completely obvious when you think about it, is how you should work with .NET standard when creating libraries. NET standard now comes in a multitude of flavours: currently 1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6 and 2.0. When starting out . . .
If you’re trying to access a class library (.NET Standard) from a traditional console application (in VS2017 those can be found under ‘Windows Classic Desktop’) you will run into problems; which can feel a little strange for something that was pretty simple in VS2015 and earlier. You can add a reference to the class library project (Resharper will even volunteer to add the dependency / namespace reference if you don’t already have it). But the . . .
The title pretty much says it all, there is no way to open an MVC2 project within Visual Studio 2012, there is no “auto-upgrade” path either! If you attempt to convert a solution containing an MVC2 project you will probably see the following error message: Subtype: ‘{F85E285D-A4E0-4152-9332-AB1D724D3325}’ is unsupported by this installation. If you do, then the only real solution appears to be graft the existing MVC2 project into an empty MVC3 or MVC4 project . . .
Not sure that this post really needs anything more than the title. If you are upgrading a Silverlight project from VS2008 or VS2010 be aware that VS2012 only supports versions 4 & 5 of Silverlight. If you need to update the solution/projects to use them in VS2012 I’d recommend upgrading to at least Silverlight 4 first in your existing Visual Studio and then once it’s working upgrade the solution/projects to VS2012 so you’re only tackling . . .
We’ve recently upgraded to Visual Studio 2012 from VS2008 and switched over to using NuGet rather than direct project references for our third party tools. Everything worked as planned until we checked the solution into source control and the personal build for TeamCity kicked off. Almost straight away the build fell over with the following error message: D:TeamCitybuildAgentworke6ae794aab32547b.nugetnuget.targets(102, 9): error MSB4067: The element beneath element is unrecognized. Project BJ.Core.sln failed. Our projects were still targeting . . .
I ran into an interesting problem today when upgrading a visual studio 2008 project to visual studio 2012, whilst trying to leave the targeted framework to .NET 3.5. Each time I tried to open the solution all my test projects automatically upgraded to .NET 4.0 regardless of what I did. It was impossible to downgrade the project using either the project property page or manually editing the project file. I’d make the change and then . . .
Today Jetbrains announced on their blog that they’ve released a resharper nuget package that will obtain project references via nuget, rather than making direct references to the locally installed code. As we are currently in the early stages of transitioning from VS2008 to VS2012 we aren’t ready to start using NuGet(*) but I think I’ll be grabbing this plugin for when we do. (*) In my last role we were using VS2010 and making heavy . . .
Leading on from the previous blog post on reducing code noise when checking for null parameters, these help functions can be utilised to further reduce code noise that generally occurs in class constructors. Most constructors are purely made up of the following duplicated checking/assignment code. Again putting together a small helper function, making use of the previous Throw class can remove 90% of the previous argument checking/assignment code resulting in: Get the code from GitHub.
The problem with writing defensive fail early code, it doesn’t take long before methods are 70% argument checking, 30% logic: Code contracts can be a great way to move code out of the method body, but how can you clean up the code just through traditional refactoring? For the last few projects I’ve worked on, I’ve been using a small helper class that abstracts all the conditional code out, leaving just a single line call . . .
Just a word of warning: Windows NT and Windows Server 2003 do not support .NET 4.5 – you can not install the framework onto these systems. So if you are building in visual studio 2012 and have to support Server 2003 (or earlier) then you must remember to target .NET4.0 (or lower) in your project(s) otherwise you will not be able to run them on the target system. That would be a really bad thing . . .