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 elementOur projects were still targeting .NET 3.5 but to fix the problem we needed to update the visual studio version in the build configuration
Note: we were are using Visual Studio 2012, but our Team City server is currently hosted on a 2003 Server O/S instance so we must select the VS2010 option in our build configuration (VS2012 option only works on 2008 Server and higher due to .NET 4.5 limitation).
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 . . .