Hacker News Reader

Comment by badsectoracula | Hacker News Reader

This is for .NET Core 3, not for .NET 5. While .NET 5 might provide the same tool, it doesn't answer if it will also provide a .NET Framework 4-like functionality where the .EXE relies on a runtime already installed on the user's system and if that framework will be something the developer will need to provide and/or be part of Windows 10 like .NET Framework 4.

View on HN

And .Net 5 will be the release after .Net Core 3, so I assume they won't go ahead and remove the feature for it.

Sorry, i edited my message above after you replied it to add a bit of more detail what i mean.

Ah, got it. You want to be able to ship something that relies on an existing installed runtime and don't want to bundle the runtime with your executable.

Me too. Requiring to run all executable with a command line is a major inconvenience. And by choosing ".dll" as an extension it is not even possible to assign the extension to dotnet as a default application like you could with a jar file. And if you want self-executing binaries you not only have the version problem you mention, but you also have to bundle all sort of assemblies. And there doesn't seem to be anything like ILMerge for .net core assemblies to merge them into a single file.

What you are looking for is called a "framework-dependent executable" (exe file with no framework) rather than a "self-contained deployment" (exe wrapper for dll file with framework included) or a "framework-dependent deployment" (dll file with no framework)

On the Github repo is a roadmap for such a single file app.[1]

[1] https://github.com/dotnet/coreclr/issues/20287#issuecomment-...

This is already supported https://docs.microsoft.com/en-us/dotnet/core/deploying/#fram...

> Starting with .NET Core 2.2, you can deploy your app as an FDE, along with any required third-party dependencies. Your app will use the version of .NET Core that's installed on the target system.

> Your app can be run by calling the published executable without invoking the dotnet utility directly.

It's almost certain they'll offer the ability to publish a self-contained binary or split from dependencies since that's a feature of .Net Core 3 today. The Mono-based projects may not, but I'd expect them to someday replace what Mono targets with .Net Core. That's just a ways out and otherwise inconsequential to the end-user using the .Net 5 API.

As others have noted, the same tool is used for both kinds of deployments (based on whether the --self-contained option is specified)

This is already possible.

That's right, that is a framework-dependend deployment as opposed to a self-contained deployment.

There is even a chary picking type of deployment (do not use entire framework).

Hehe it’s cherrypicked. Or cherry picking!

> The term is based on the perceived process of harvesting fruit, such as cherries. The picker would be expected to only select the ripest and healthiest fruits. An observer who only sees the selected fruit may thus wrongly conclude that most, or even all, of the tree's fruit is in a likewise good condition. This can also give a false impression of the quality of the fruit (since it is only a sample and is not a representative sample).

Source Wikipedia.

Reply on news.ycombinator.com