简体   繁体   中英

On Windows only: does net5.0-windows (or net6.0-windows) allow me to recompile .Net framework in .Net 5 ( or .Net 6)?

I have .Net framework apps, that are intended to run only on Windows, now and forever.

I am thinking about upgrading them to .Net 5 or .Net 6, and target them to net5.0-windows (or net6.0-windows ). From MS website it says that

net5.0-windows will be used to expose Windows-specific functionality, including Windows Forms, WPF and WinRT APIs.

Does that mean that my .Net framework apps can be recompiled in .Net 6, as long as I specify the net-windows target and the csproject upgrade and compilation is successful, the program will just work ? I just intend them to run on Windows, now and always .

My apps also consume a lot of .Net framework 2.0/3.5/4.6 dlls ( mostly they are involved with OpenGL and other graphic things), which I can only assume to have no general port to .Net 5 or .Net 6, and which the source code is no longer available even to me ( they are from close-source third party providers).

Does that mean that my .Net framework apps can be recompiled in .Net 6,

Yes

the program will just work?

Most likely it will, but one should do a full regression test to verify.

My apps also consume a lot of .Net framework 2.0/3.5/4.6 dlls

If you can't migrate to .Net 4.8, then chances are slim that one can be able to migrate into .Net core.

( mostly they are involved with OpenGL and other graphic things), which I can only assume to have no general port to .Net 5 or .Net 6

Each one has to be taken on as a case by case basis; you may have just actually answered your own question. Say Goodnight Gracey...


What may better serve you is to create a docker container which will serve up the older versions of these app(s) which has the target version of the frameworks which currently work.

Unfortunately there is no definitive answer to your question, as it will depend (no pun intended) entirely on what your dependencies are.

.NET 5 was intended to be the unification of classic .NET Framework and .NET Core and in many cases it will just work .

Speaking from experience, in many cases it is easier to create a clean project in the new framework, copy all the existing files from the old project then re-add NuGet and project references. I have done this successfully for Console Apps, Test Projects and even a WinForms app 15-20 project dependencies to .NET 4.8 projects and it has worked out of the box - albeit with a compiler warning about the .NET 4.8 dependencies.

However I have also come across at least one missing / changed API between 4.8 and 5.0 - BeginInvoke . A blog post here describes it in more detail. Sometimes there are also issues with NuGet versions.

The closest thing to a definitive list online is the MS Doc "Changes that affect compatibility" and in particular the Breaking changes for migration from .NET Framework to .NET Core section. I'm not sure the is a better "answer from a reputable source" out there.

As for your .NET 2.0 / 3.5 / 4.6 dlls I don't think there is anyway of knowing without trying. There are simply too many unknowns, especially as they are 3rd party dlls. If I had to guess it would be that at least one won't work, whether you can find an updated version or how much work an alternative library will be to incorporate will be impossible to tell

As for net5.0-windows , it's basically a fudge. While the goal of everything .NET 5.0 onwards was unification and cross-platform everything, they couldn't get all the work done in time. I read a blob post about it, which I can't find right now, but basically WinForms in particular is very closely tied to some underlying Windows only APIs. Maybe .NET 7.0?

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM