Background
To directly jump to the problem this post is dealing with by skipping the story, directly jump to the last paragraph in this section.
When we were developing .Net libraries or third-party components in the early days we had to keep one project per framework version. That is because there would be more than one version in the mainstream at any time. Though Visual Studio 2008 onwards there is some sort of multi-targeting which matured with VS 2010, it was not easy to publish libraries from one project targeting different framework versions.
The need to target multiple versions became intense with the introduction of .Net Core. Both Full .Net Framework, as well as .Net Core, keep getting new versions.
But it changed totally when Microsoft introduced multi-targeting library projects in Visual Studio 2017. For simplicity skipping the PCL(Portable Class Libraries) which was introduced in between to deal with common code base for Silverlight and .Net Framework. At that time, there was real confusion about what library project to choose when we create new. Later Microsoft introduced JSON based project file for .Net core which dropped with a migration path.
The new project format really simplified the .csproj files. Initially, it was more related to the .Net Standard but later it is used for different purposes as well even for console apps. Let us not get into .Net Standard as differentiating it is another post by itself. Finally, the new project format got the name SDK-Style project which we can identify by the below tag in the project file (.csproj)
<Project Sdk="Microsoft.NET.Sdk">
One of the earliest blog posts explains what is the vision when they revamped the project file format. No listing of files inside the project file, can produce nuget directly without nuspec, easy modification without IDE, etc... were some. Until then the csproj was considered as only software editable file format though it is XML. But with the SDK-Style project format, though it is still XML, humans are also allowed to edit manually. More details can be found here.
Now the csproj is more like the NodeJS development where the packge.json is human editable. Really dreaming for a day when Microsoft says "develop with NodeJS or something else and host in Azure". Just a dream.
Let us come back to the purpose of this post. Here we are seeing how to convert existing old nuget library projects to modern SDK-Style library projects which can target multiple frameworks and versions including from .Net 4.5 to .Net Core 3.1.
Existing approaches
The easy way most of the internet says on converting existing projects to a multi-targeting SDK-Style library project is to create a new project. Then just copy-paste the files from old project location to new. Since the new project format doesn't require all the files to be added to the project file its easy as just copy. Links are given in the references section.
Just compare with NodeJS development where package.json doesn't need to know all the files.
There is another way to convert the projects to SDK-Style. First, convert the nuget package references from the packages.config to <packagereference> tag in csproj. Then use a tool to migrate the project file. There seem multiple tools listed below though they point to the same GitHub repo. Maybe one is a wrapper over other when VS 2019 released.
Manual approach
However, it seems easy to convert by hand, if our project is not that much complicated and confirms the compatibility. The only problem is that we need to clean the project which is not required if we start a new project and copy files.
Manually porting project to SDK-Style library project
Below goes a diff of manual porting of one project. If the iFrame is not loading directly go to the GitHub URL. Another difference is that the SDK-Style doesn't really require the Assemblyinfo.cs
Manually porting test project to SDK-Style
The same can be applied to test projects as well. The link to the comparison is here.
Please note that it worked smoothly as this project is simple and only one person handles all at this point. When working in Enterprise environments or a large team environment, it would not be efficient as following the steps such as evaluate compatibility, refactoring projects to smaller pieces before doing anything.
References
https://weblog.west-wind.com/posts/2017/jun/22/multitargeting-and-porting-a-net-library-to-net-core-20https://www.michaeltaylorp3.net/porting-a-net-framework-library-to-net-standard/
No comments:
Post a Comment