1

I am currently tasked with replacing one of our large .NET Framework 4.7.2 libraries by several smaller .NET Standard 2.0 libraries to slowly but steadily prepare our projects for migration to .NET 6+.

Short overview of the old project structure (small excerpt, there are more projects but these are the important ones):

Monolithic Business Logic Library Project (Net472)

is being referenced by:

  • Legacy Winforms project (net472 - will probably stay there forever)
  • WPF project (net481, supposed to migrate to .NET 6 soon)
  • ASP.NET Web API / MVC project (net481, supposed to migrate to .NET 6 after the WPF app)

And the new project structure: The monolithic library is now split into several smaller libraries, e.g.

  • DAL library (netstandard2.0 with NuGet packages, e.g. Microsoft.Data.SqlClient)
  • FTP client library (netstandard2.0 with NuGet packages)
  • Document Management System Client (netstandard 2.0 with NuGet packages)

... you get the gist (yes, the old library was a mess...)

Those are referenced by (if needed):

  • Legacy Winforms project (net472)
  • WPF project (net481)
  • ASP.NET Web API / MVC 5 project (net481)

So far I managed to split the large library into those smaller .NET Standard libraries and modified our two large Desktop Apps to use the new libraries. I had to include some NuGet packages, such as Microsoft.Data.SqlClient in the new library projects which in turn forced me to migrate both Desktop Applications to the PackageReference format to make them work with transitive references. But after all, it worked quite well (except for this issue, which I fixed with this workaround and some minor issue with transitive project references I still need to sort out).

The last project I need to modify is the ASP.NET project but this is where the headache starts:

  1. ASP.NET projects cannot be migrated to PackageReference. So I first tried to just include all the needed NuGet packages in the root project as suggested in this stackoverflow thread. However, this became pretty bad pretty quickly because of all the transitive dependencies and I quickly ended up in package version hell. Microsoft.Data.SqlClient alone comes with an almost unmanageable amount of transitive dependencies and there are a lot more top level packages apart from that I would have to reference with all their respective transitive dependencies.

  2. My second (kind of desperate) try was to just slap <RestoreProjectStyle>PackageReference</RestoreProjectStyle> into the csproj-file as is suggested in some threads here and on other sites - which actually seemed to work until I realized that it caused Visual Studio to not recognize any of the installed packages anymore (the "Installed" tab was just empty in the NuGet package manager UI).

  3. My third try was to follow the suggestion in this github issue on NuGet to migrate to PackageReference anyway. As expected, I lost the content folder in the process but I was able to restore that from our git repo and I would have no problem with maintaining that by hand in the near future since its just internal Api documentation anyway. This attempt seems to be the most promising and everything seems to work currently (after running into this problem and fixing it) but I don't know if there are any other potential problems with this approach as there is also the install.ps1 scripts that will not be executed...

Can anyone tell me if my third attempt is actually a viable solution? Or is there a better way to approach this problem that I didn't think of yet?

S. Müller
  • 21
  • 2
  • 2
    Well, it is not an answer to your question, but according to my previous examples, migrating legacy projects are already a pain, choosing a path that requires migrating a project twice will double that pain. I usually prefer an approach that creates the project from scratch, adds all the dependencies to that empty project, and then moves the files step by step, from simple classes (Model, Dto, ViewModel, etc) to more complex ones and then fixes the breaking changes. And build the project at every step. – Eldar Jun 23 '23 at 07:08
  • Ok, now it makes sense. But you can apply what I said above to your shared libraries. Create the net standard project first add the dependencies and move your files afterwards. – Eldar Jun 23 '23 at 08:28
  • 1
    If it wasn't for the legacy application, I would also choose this path. However, since the legacy application will 100% stay on .NET Framework, I definitively have to migrate the common libraries to netstandard. And since the Web API and the WPF app also have common libraries, I would have to migrate those to netstandard too or lift both to net6 at the same time - which I cannot do since our clients are not prepared for net6 yet. The only viable path I see is to first migrate all common libs to netstandard and then migrate the respective apps to net6 whenever its time to do so. – S. Müller Jun 23 '23 at 08:31

0 Answers0