Hacker News Reader

Comment by triangleman | Hacker News Reader

The big question, for me at least, is can this be used to containerize a .NET application without having to package a full Windows OS into the container?

View on HN

In case you weren’t yet aware, .NET Core runtime can be containerized on Linux. .NET Framework is the (mostly) Windows dependent runtime. Mono is the open / Microsoft supported translation of .NET Framework to Linux.

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.

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.

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.

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.

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.

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.

This is just the .Net runtime most application will probably depend on the .net framework libraries so not really.

"containerize" is a very loaded/subjective term. In my experience, the best container-like boundary for .NET Core applications would be the process itself. AppDomains and related fanfare don't really exist anymore, and the process is the only common abstraction across all platforms that shares most of the same principles. It's always been the best grain to go along IMO.

I assume the author really means "run in a Linux context, without Windows". Otherwise, if you really just want to containerize and don't mind running an instance of Windows, you could use a Windows container.

If I read TFA correctly: Maybe in a couple of years, if a 100 devs jump on the project. The author is currently in the "Proof-of-concept" stage. Nevertheless an interesting project and write-up. Probably to late to run old legacy .Net Apps that -unfortunately- you "inherited" without source-code.

Lots of Linux images available @ https://hub.docker.com/_/microsoft-dotnet-core-aspnet/

Reply on news.ycombinator.com