5 ms·

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?

stragies 7y ago
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.
vesh 7y ago
This is just the .Net runtime most application will probably depend on the .net framework libraries so not really.
9wzYQbTYsAIc 7y ago
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.
- triangleman 7y ago
  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.
bob1029 7y ago
"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.
- solarkraft 7y ago
  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.
runfaster2000 7y ago
Lots of Linux images available @ https://hub.docker.com/_/microsoft-dotnet-core-aspnet/ https://hub.docker.com/_/microsoft-dotnet-core-aspnet/
deleted 7y ago
[deleted]

stragies 7y ago

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.

vesh 7y ago

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

9wzYQbTYsAIc 7y ago

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.

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

bob1029 7y ago

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

solarkraft 7y ago
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.

runfaster2000 7y ago

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

deleted 7y ago

[deleted]