3 ms·

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.

by Arnavion 8y ago

badsectoracula 8y ago
Sorry, i edited my message above after you replied it to add a bit of more detail what i mean.
- deleted 8y ago
  [deleted]
- Arnavion 8y ago
  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.
  - cm2187 8y ago
    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.
    - shawnz 8y ago
      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)
    - cheerlessbog 8y ago
      On the Github repo is a roadmap for such a single file app.[1] [1] https://github.com/dotnet/coreclr/issues/20287#issuecomment-488850277 https://github.com/dotnet/coreclr/issues/20287#issuecomment-...
    - testvox 8y ago
      This is already supported https://docs.microsoft.com/en-us/dotnet/core/deploying/#framework-dependent-executables-fde 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.

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.

badsectoracula 8y ago

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

deleted 8y ago
[deleted]
Arnavion 8y ago
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.
- cm2187 8y ago
  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.
  - shawnz 8y ago
    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)
  - cheerlessbog 8y ago
    On the Github repo is a roadmap for such a single file app.[1] [1] https://github.com/dotnet/coreclr/issues/20287#issuecomment-488850277 https://github.com/dotnet/coreclr/issues/20287#issuecomment-...
  - testvox 8y ago
    This is already supported https://docs.microsoft.com/en-us/dotnet/core/deploying/#framework-dependent-executables-fde 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.