Not necessarily. It really depends on your platform and 3rd party library usage scope. There also exist very helpful shims for accessing legacy .NET Framework functionality as long as you are running your .NET Core applications on windows:

https://www.nuget.org/packages/Microsoft.Windows.Compatibili...

The idea here being that you can quickly move to .NET Core using the compatibility shim, and then incrementally work your way off of it. .NET 5 will support the exact same concepts, so it still makes sense to engage this task if you want to get onto the new bandwagon.

I've never tried it, but from memory I think you can run .NET Framework under Wine, which presumably you could put in a container.

But honestly, I think your time would be better spent moving it to .NET Core. I've moved a few big apps, and while I wouldn't class it as "easy", it wasn't really that difficult, more time consuming that anything.

You're postponing the inevitable. .NET 5 is .NET Core.

Yes, but many legacy .Net apps were delivered without source-code, the original developer is not available, and now people like OP and me are looking to run this old crap (for paying customers) without having to maintain a dedicated Windows VM.

Have you tried decompiling it? Telerik Just Decompile will decompile it back out to C#. It ultimately depends on agreement you had with the original developer as to whether it is legal or not.

Even with source, it's still a big undertaking to convert to .NET Core but efdee is right, it's just postponing the inevitable. I'm sure we will go to .NET 5 soon enough.

If you try to do it in one big hit it will be hard but you don't have to do that. You can move it over piecemeal.

You can use multi-targeting to move parts of your code over to .NET Standard. So if you start with your base projects and move your way up, gradually your code will become compatible between .NET core and .NET Framework. This will help you remove any .NET Full Framework / Windows specific bits. Where you have to have things that are specific to each OS you can then just configure your DI so it will inject the Windows specific / Linux specific implementation.

For those that are not aware of multi-targeting here is a great article on it:

https://weblog.west-wind.com/posts/2017/Jun/22/MultiTargetin...

I used the multitargetting approach over the last year to convert most of my code to .NET Standard (about 50KLOC). The latest .NET Standard 2.0 and .NET Core 3.1 make it pretty easy. MS' previous attempts at multiplatforming were hit or miss, but they really seem to have finally gotten it right.

Part of what has made it so much easier is the new "SDK Style Project File Format". It makes manually editing the csproj file mostly easier than using the VS editor for the vast majority of tasks. Which, for better or worse, is necessary to get some of the latest features. Got example, you can enable most of the latest C# 8 features for .NET Framework (which officially is stuck at C# 7.2).

The old multiplatforming options I don't think anyone bothered with. It certainly much easier than before.

The hard part is exactly all those legacy APIs that are often Windows-specific. This is just a custom implementation of the CLR; it doesn't do anything about the libraries, so far as I can tell.