Sponsor: Do you build complex software systems? See how NServiceBus makes it easier to design, build, and manage software systems that use message queues to achieve loose coupling. Get started for free.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 BenefitsFirst, 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 StyleHere’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 csprojIf 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:
Here is the converted csproj file. You can see
AssemblyInfoThere 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:
We can either remove the appropriate lines from our csproj or from our AssemblyInfo.cs The choice is yours.
PackageReference and ReferenceThe 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.