Migrating to SDK csproj

The SDK csproj files introduced with Visual Studio 2017 are a much needed improvement to the project files.    If you are creating a new .NET Core project or a .NET Standard library, either with VIsual Studio 2017 or the .NET CLI via dotnet new, it will generate the new SDK csproj.  What isn’t very clear to many is that you can use the new SDK format with full .NET Framework apps.  So this post will point out a really simple way for migrating to SDK csproj.

SDK Benefits

First, if you are unfamiliar with the new SDK csproj, here are a few of the benefits.

  • Include files using a wildcard as opposed to specifying every single file.
  • Simpler referencing of solution project references.
  • Reference NuGet package as references.  No more packages.config.
  • Define Some AssemblyInfo attributes.
  • NuGet package definition as part of the project file.  No more nuspec.

Old Style

Here’s the older style csproj from a .NET Framework 4.7.1 class library that references another class library.  There is a NuGet Package to Newtonsoft.Json

Migrating to SDK csproj

If you want to do manual conversions, take a look at this post by Nate McMaster.  However, ain’t nobody got time for manual conversions.  Luckily there is a tool that does a lot of the heavy lifting for your.  The CsprojToVs2017 project on Gith=Hub has been working wonders for me.  It either has worked in generating a full conversion or got me most of the way there.

Simply run the exe specifying the csproj file to convert:

.\Project2015To2017.exe YourClassLibrary.csproj

Here is the converted csproj file.  You can see

AssemblyInfo

There are a couple of errors after the conversion.

Since the csproj now contains some assembly info that is also in our existing AssemblyInfo.cs.  Specifically these two:

[assembly: System.Reflection.AssemblyCompanyAttribute("ClassicClassLibrary")]
[assembly: System.Reflection.AssemblyConfigurationAttribute("Debug")]

We can either remove the appropriate lines from our csproj or from our AssemblyInfo.cs  The choice is yours.

PackageReference and Reference

The conversion looked at our packages.config and created the appropriate <PackageReference ../>.  However, it also created <Reference ../>, which we no longer need.  So we can delete any of those that are actually NuGet Packages.

More

There are a ton of situations such as content files that it was handle appropriately.  If you have many project files that you would like to convert, I suggest giving this tool a shot.  Even if it gets you 80% of the way there and requires a bit of cleanup, I find it well worth it.

Are you converting?

If so, are you doing rewriting the project files manually or using this or a different tool?  I’d love to hear your comments or in Twitter.

 

 

Enjoy this post? Subscribe!

Subscribe to our weekly Newsletter and stay tuned.