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 with something new, we (as developers) often want to be as cutting edge as possible and probably haven’t read the small print / finer details. So as a result, when creating our first .NET standard library a natural tendency is to create it targeting .NET Standard 2.0. Of course, that makes perfect sense – it’s the newest so must be the best? It’s definitely true, it is the latest and has the largest .NET framework coverage. BUT, and it is a big but. The library you are building can now only be used by other libraries targeting .NET Standard 2.0 (and newer). If the consumer of your library wants, or must, target .NET standard 1.6 (or older) then they will be unable to use your library due to this version incompatibility.
Therefore when starting a new library targetting .NET standard you should always start with targeting 1.0 and only increase the targeted version when you run into an unsupported framework call. If you are able to create a library that can target .NET standard 1.0 you should be really happy, it has the highest level of compatibility and will make your library’s consumers lives much easier.
Like I say, when it’s highlighted it makes perfect sense but I’m sure we’ve all seen that “Target .NET Standard Version” dropdown and wondered “When there’s 2.0, why would I ever consider anything 1.x!”
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 . . .