4 ms·

Right but converting a big application to .NET Core is hard. Is this project not sort of an emulator to allow a legacy .NET Windows app to run on .NET Core? I h

Right but converting a big application to .NET Core is hard. Is this project not sort of an emulator to allow a legacy .NET Windows app to run on .NET Core? I had better read TFA better.

GordonS 7y ago
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.
efdee 7y ago
You're postponing the inevitable. .NET 5 is .NET Core.
- stragies 7y ago
  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.
  - triangleman 7y ago
    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.
  - uk_programmer 7y ago
    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.
bob1029 7y ago
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.Compatibility 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.
uk_programmer 7y ago
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/MultiTargeting-and-Porting-a-NET-Library-to-NET-Core-20 https://weblog.west-wind.com/posts/2017/Jun/22/MultiTargetin...
- moron4hire 7y ago
  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).
  - uk_programmer 7y ago
    The old multiplatforming options I don't think anyone bothered with. It certainly much easier than before.
int_19h 7y ago
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.

Right but converting a big application to .NET Core is hard. Is this project not sort of an emulator to allow a legacy .NET Windows app to run on .NET Core? I had better read TFA better.

GordonS 7y ago

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.

efdee 7y ago

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

stragies 7y ago
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.
- triangleman 7y ago
  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.
- uk_programmer 7y ago
  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.

bob1029 7y ago

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.Compatibility 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.

uk_programmer 7y ago

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/MultiTargeting-and-Porting-a-NET-Library-to-NET-Core-20 https://weblog.west-wind.com/posts/2017/Jun/22/MultiTargetin...

moron4hire 7y ago
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).
- uk_programmer 7y ago
  The old multiplatforming options I don't think anyone bothered with. It certainly much easier than before.

int_19h 7y ago

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.