New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Single exe self contained console app #13329

Closed
mj1856 opened this Issue Nov 3, 2016 · 26 comments

Comments

Projects
None yet
@mj1856
Contributor

mj1856 commented Nov 3, 2016

Publishing a self-contained console application in .net core, as described here results in a directory with a lot of files, even one with "smaller footprint".

Is it possible to bundle all the dependencies so we get a single executable? One large-ish myapp.exe when targeting Windows, for example.

I suppose I'm looking for something similar to ILMerge, but for .net core. Is it possible by some option flag on dotnet publish or some other command? If not, please consider as a feature request. Thanks.

@mellinoe

This comment has been minimized.

Show comment
Hide comment
@mellinoe

mellinoe Nov 3, 2016

Contributor

This scenario isn't supported right now. Keep an eye on the https://github.com/dotnet/corert repo for work that will lead down this path.

Contributor

mellinoe commented Nov 3, 2016

This scenario isn't supported right now. Keep an eye on the https://github.com/dotnet/corert repo for work that will lead down this path.

@karelz

This comment has been minimized.

Show comment
Hide comment
@karelz

karelz Nov 4, 2016

Member

CoreRT is the right place to search for this solution.

Member

karelz commented Nov 4, 2016

CoreRT is the right place to search for this solution.

@karelz karelz closed this Nov 4, 2016

@mj1856

This comment has been minimized.

Show comment
Hide comment
@mj1856

mj1856 Nov 11, 2016

Contributor

Thanks. It looks like CoreRT is exactly what I was looking for.

For others that may stumble on this, read here

Contributor

mj1856 commented Nov 11, 2016

Thanks. It looks like CoreRT is exactly what I was looking for.

For others that may stumble on this, read here

@karelz karelz modified the milestone: 1.2.0 Dec 3, 2016

@jnm2

This comment has been minimized.

Show comment
Hide comment
@jnm2

jnm2 Aug 15, 2017

Collaborator

I specifically want this feature without ahead of time compilation. I don't want corert– I want the same jit and debugging and runtime experience as a normal self-contained app– but I also don't want to distribute four files per utility. That's inconvenient for whoever wants to use the utility. I just want it packed and run from a single exe. This is causing me to choose .NET Framework over .NET Core for many utilities.

Collaborator

jnm2 commented Aug 15, 2017

I specifically want this feature without ahead of time compilation. I don't want corert– I want the same jit and debugging and runtime experience as a normal self-contained app– but I also don't want to distribute four files per utility. That's inconvenient for whoever wants to use the utility. I just want it packed and run from a single exe. This is causing me to choose .NET Framework over .NET Core for many utilities.

@karelz

This comment has been minimized.

Show comment
Hide comment
@karelz

karelz Aug 18, 2017

Member

.NET Framework is "cheating" as you have plenty of files already present in the OS.
You can achieve the same with .NET Core, by installing machine-wide shared .NET Core if that is what you want.

Refactoring CoreCLR to merge all its files into one (incl. native + managed) is non-trivial work and I don't think the scenario is that interesting for too many customers.

Member

karelz commented Aug 18, 2017

.NET Framework is "cheating" as you have plenty of files already present in the OS.
You can achieve the same with .NET Core, by installing machine-wide shared .NET Core if that is what you want.

Refactoring CoreCLR to merge all its files into one (incl. native + managed) is non-trivial work and I don't think the scenario is that interesting for too many customers.

@jnm2

This comment has been minimized.

Show comment
Hide comment
@jnm2

jnm2 Aug 18, 2017

Collaborator

The difference is that every Windows machine is guaranteed to have .NET Framework but not .NET Core, so unless there's a special reason that is worth making deployment more complex, I guess I'll end up staying there.
I guess customers don't typically write single exe utilities. Maybe one day. :-)

Collaborator

jnm2 commented Aug 18, 2017

The difference is that every Windows machine is guaranteed to have .NET Framework but not .NET Core, so unless there's a special reason that is worth making deployment more complex, I guess I'll end up staying there.
I guess customers don't typically write single exe utilities. Maybe one day. :-)

@mellinoe

This comment has been minimized.

Show comment
Hide comment
@mellinoe

mellinoe Aug 19, 2017

Contributor

unless there's a special reason that is worth making deployment more complex

There are MANY reasons to prefer .NET Core over .NET Framework. Performance, modularity, serviceability, isolation, etc. And that is ignoring cross-platform-ness.

Having a single exe utility is mostly a cosmetic concern. There's no real functional difference (for anyone involved) if the executable is a single file or a single folder with a handful of files in it.

Contributor

mellinoe commented Aug 19, 2017

unless there's a special reason that is worth making deployment more complex

There are MANY reasons to prefer .NET Core over .NET Framework. Performance, modularity, serviceability, isolation, etc. And that is ignoring cross-platform-ness.

Having a single exe utility is mostly a cosmetic concern. There's no real functional difference (for anyone involved) if the executable is a single file or a single folder with a handful of files in it.

@jnm2

This comment has been minimized.

Show comment
Hide comment
@jnm2

jnm2 Aug 19, 2017

Collaborator

@mellinoe Oh I agree for projects in general, that is certainly true. In the small utilities where this cosmetic is desirable, .NET Framework has thus far done a good enough job. I agree it's cosmetic in the same sense as being able to specify an assembly company and copyright message. But being a cosmetic thing doesn't make me like it less. Obviously not a priority here, that's quite understandable.

Collaborator

jnm2 commented Aug 19, 2017

@mellinoe Oh I agree for projects in general, that is certainly true. In the small utilities where this cosmetic is desirable, .NET Framework has thus far done a good enough job. I agree it's cosmetic in the same sense as being able to specify an assembly company and copyright message. But being a cosmetic thing doesn't make me like it less. Obviously not a priority here, that's quite understandable.

@ferventcoder

This comment has been minimized.

Show comment
Hide comment
@ferventcoder

ferventcoder commented Sep 9, 2017

Possibly related: dotnet/core#600

@thefringeninja

This comment has been minimized.

Show comment
Hide comment
@thefringeninja

thefringeninja Sep 27, 2017

It's not mostly cosmetic. Imagine that I want to distribute an application that has several components embedded inside, like say Idsrv4 or RavenDb + my own stuff. They take a dependency on the aspnet core bits. This all works fine as long as they depend on the same version of aspnet core. As soon as one of them rolls forward to the next version it probably will no longer work. If OTOH I could ilmerge each component down to a single .dll the problem goes away.

thefringeninja commented Sep 27, 2017

It's not mostly cosmetic. Imagine that I want to distribute an application that has several components embedded inside, like say Idsrv4 or RavenDb + my own stuff. They take a dependency on the aspnet core bits. This all works fine as long as they depend on the same version of aspnet core. As soon as one of them rolls forward to the next version it probably will no longer work. If OTOH I could ilmerge each component down to a single .dll the problem goes away.

@mellinoe

This comment has been minimized.

Show comment
Hide comment
@mellinoe

mellinoe Sep 27, 2017

Contributor

One thing to keep in mind is that there are more technical problems than just ILMerge not working. The runtime itself is fundamentally split into many files, and there are also auxiliary files like the CLR host, the runtime dependencies text file, and more. The only reason a single-file executable has worked in the past is because the .NET Framework, a global system-wide installation, was relied upon. Comparing the two scenarios is a bit unfair, because the .NET Framework doesn't really have a "self-contained" option.

This all works fine as long as they depend on the same version of aspnet core. As soon as one of them rolls forward to the next version it probably will no longer work.

This isn't really true. You can publish several different applications against different runtime versions and then bundle them into the same "uber-app". You just cannot mix their dependencies into a single folder. Even if you use the framework-dependent publish option, you can still mix and match versions. I understand that this is less convenient than having literally a single file, and might prevent things like embedding an exe as a resource in the PE. I'm not sure if that's what you're referring to, though, since you'd probably still need to extract the file to execute it, which you could still do with a directory.

Contributor

mellinoe commented Sep 27, 2017

One thing to keep in mind is that there are more technical problems than just ILMerge not working. The runtime itself is fundamentally split into many files, and there are also auxiliary files like the CLR host, the runtime dependencies text file, and more. The only reason a single-file executable has worked in the past is because the .NET Framework, a global system-wide installation, was relied upon. Comparing the two scenarios is a bit unfair, because the .NET Framework doesn't really have a "self-contained" option.

This all works fine as long as they depend on the same version of aspnet core. As soon as one of them rolls forward to the next version it probably will no longer work.

This isn't really true. You can publish several different applications against different runtime versions and then bundle them into the same "uber-app". You just cannot mix their dependencies into a single folder. Even if you use the framework-dependent publish option, you can still mix and match versions. I understand that this is less convenient than having literally a single file, and might prevent things like embedding an exe as a resource in the PE. I'm not sure if that's what you're referring to, though, since you'd probably still need to extract the file to execute it, which you could still do with a directory.

@thefringeninja

This comment has been minimized.

Show comment
Hide comment
@thefringeninja

thefringeninja Oct 17, 2017

I didn't mean runtime version, I know that isn't going to work. What I mean is, what happens in my scenario when each component takes a dependency on LibXYZ@1.0.0. Component a then updates to LibXYZ@1.0.1. Normally that's fine, but in this hypothetical the authors of LibXYZ don't know / don't care about semantic versioning. Ilmerge made this problem go away.

thefringeninja commented Oct 17, 2017

I didn't mean runtime version, I know that isn't going to work. What I mean is, what happens in my scenario when each component takes a dependency on LibXYZ@1.0.0. Component a then updates to LibXYZ@1.0.1. Normally that's fine, but in this hypothetical the authors of LibXYZ don't know / don't care about semantic versioning. Ilmerge made this problem go away.

@edblackburn

This comment has been minimized.

Show comment
Hide comment
@edblackburn

edblackburn Oct 17, 2017

As well as @thefringeninja pertinent point, I would suggest that a single deployable binary unit reduces the ops overhead. It reduces the likelihood of something going wrong with a deployment, lowers the burden of cognitively appreciating what you've shipped and reduces config for ops tooling be it scripting, or desired state.

I appreciate the dotnet tooling is nascent and has only just reached 2.0, but compared to alternatives such as golang this feature is sorely missing. Please consider adding it to the roadmap?

edblackburn commented Oct 17, 2017

As well as @thefringeninja pertinent point, I would suggest that a single deployable binary unit reduces the ops overhead. It reduces the likelihood of something going wrong with a deployment, lowers the burden of cognitively appreciating what you've shipped and reduces config for ops tooling be it scripting, or desired state.

I appreciate the dotnet tooling is nascent and has only just reached 2.0, but compared to alternatives such as golang this feature is sorely missing. Please consider adding it to the roadmap?

@danbarua

This comment has been minimized.

Show comment
Hide comment
@danbarua

danbarua Oct 17, 2017

As a lib developer, I'd appreciate having ILMerge back in Core. 👍

danbarua commented Oct 17, 2017

As a lib developer, I'd appreciate having ILMerge back in Core. 👍

@dazinator

This comment has been minimized.

Show comment
Hide comment
@dazinator

dazinator Feb 17, 2018

Dotnet.exe is a single file. NuGet.exe is a single file. I think cosmetics are important, and a single file exe shouts simplicity in a way that a folder with 100 files in doesn't! Would be great to find a way to achieve this with dotnetcore

dazinator commented Feb 17, 2018

Dotnet.exe is a single file. NuGet.exe is a single file. I think cosmetics are important, and a single file exe shouts simplicity in a way that a folder with 100 files in doesn't! Would be great to find a way to achieve this with dotnetcore

@PRIMETSS

This comment has been minimized.

Show comment
Hide comment
@PRIMETSS

PRIMETSS Mar 5, 2018

I assumed this was possible, and after several weeks of work, came to publish CLI console tool to a single .exe ... ummm seems at the moment I cant just get a single *.exe ??
I thought that was the point of self contained core apps?

PRIMETSS commented Mar 5, 2018

I assumed this was possible, and after several weeks of work, came to publish CLI console tool to a single .exe ... ummm seems at the moment I cant just get a single *.exe ??
I thought that was the point of self contained core apps?

@svick

This comment has been minimized.

Show comment
Hide comment
@svick

svick Mar 5, 2018

Contributor

@PRIMETSS

I thought that was the point of self contained core apps?

The point of self-contained apps is that they are self-contained, that is, they don't require .Net Core to be installed on the target machine, because the app itself contains everything it needs to run.

To deploy such an app, you have to copy an entire directory of files. Having just a single file would make the deployment easier, but that's it, it's still a self-contained app even without that.

Contributor

svick commented Mar 5, 2018

@PRIMETSS

I thought that was the point of self contained core apps?

The point of self-contained apps is that they are self-contained, that is, they don't require .Net Core to be installed on the target machine, because the app itself contains everything it needs to run.

To deploy such an app, you have to copy an entire directory of files. Having just a single file would make the deployment easier, but that's it, it's still a self-contained app even without that.

@lashchev

This comment has been minimized.

Show comment
Hide comment
@lashchev

lashchev Mar 29, 2018

For large and service-like apps this maybe not that important, but it is essential for command-line tools and small apps to be as simple as possible and COPY-deployment friendly.

I regularly write command line tools in .NET and having them as 1 EXE makes upgrades/deployments/packaging WAY simpler. I always pack all .config and other required files inside EXE.

Think of that single-EXE as a mini-container. Almost all benefits of container-based deployments apply here.

lashchev commented Mar 29, 2018

For large and service-like apps this maybe not that important, but it is essential for command-line tools and small apps to be as simple as possible and COPY-deployment friendly.

I regularly write command line tools in .NET and having them as 1 EXE makes upgrades/deployments/packaging WAY simpler. I always pack all .config and other required files inside EXE.

Think of that single-EXE as a mini-container. Almost all benefits of container-based deployments apply here.

@Scellow

This comment has been minimized.

Show comment
Hide comment
@Scellow

Scellow Apr 21, 2018

This is just horrible i wonder why this was approved during design process, want to distribute your application to one of your client, then good luck to him to find what to open:
image

This is just ugly and a complete mess

runtime/
MyProgram.exe
MyLib.dll

This would have been a way better idea

Even Java handle that better:
explorer_2018-04-21_16-42-33

Scellow commented Apr 21, 2018

This is just horrible i wonder why this was approved during design process, want to distribute your application to one of your client, then good luck to him to find what to open:
image

This is just ugly and a complete mess

runtime/
MyProgram.exe
MyLib.dll

This would have been a way better idea

Even Java handle that better:
explorer_2018-04-21_16-42-33

@PRIMETSS

This comment has been minimized.

Show comment
Hide comment
@PRIMETSS

PRIMETSS Apr 23, 2018

Yes I was thinking along the same lines, since the self contained apps need to have the runtime files included with it with it (obviously!) (and we dont have a way to merge those), then I also thought just a folder separation would be neater, and yes I also think the runtime files should be stored off in a runtime folder, so anyone trying to use a Command Line Tool written in core, would at least find it a bit more intuitive as what to run..

PRIMETSS commented Apr 23, 2018

Yes I was thinking along the same lines, since the self contained apps need to have the runtime files included with it with it (obviously!) (and we dont have a way to merge those), then I also thought just a folder separation would be neater, and yes I also think the runtime files should be stored off in a runtime folder, so anyone trying to use a Command Line Tool written in core, would at least find it a bit more intuitive as what to run..

@imgen

This comment has been minimized.

Show comment
Hide comment
@imgen

imgen commented Jun 7, 2018

@Scellow @PRIMETSS I have to agree

@AnalogMan151

This comment has been minimized.

Show comment
Hide comment
@AnalogMan151

AnalogMan151 Jun 11, 2018

How is this even still an issue? The demand is through the roof for this.

AnalogMan151 commented Jun 11, 2018

How is this even still an issue? The demand is through the roof for this.

@hkoelewijn

This comment has been minimized.

Show comment
Hide comment
@hkoelewijn

hkoelewijn Jun 19, 2018

yes to this separate folder with the addition to zip that into a bin and have two files, the exe and the bin. Easy distribution.

hkoelewijn commented Jun 19, 2018

yes to this separate folder with the addition to zip that into a bin and have two files, the exe and the bin. Easy distribution.

@CumpsD

This comment has been minimized.

Show comment
Hide comment
@CumpsD

CumpsD Jul 25, 2018

Another +1 to re-open and have as a feature.

CumpsD commented Jul 25, 2018

Another +1 to re-open and have as a feature.

@FlsZen

This comment has been minimized.

Show comment
Hide comment
@FlsZen

FlsZen Jul 31, 2018

I was expecting self-contained deployment was self-contained and found my way here. I'd also like to see this happen.

FlsZen commented Jul 31, 2018

I was expecting self-contained deployment was self-contained and found my way here. I'd also like to see this happen.

@FreeApophis

This comment has been minimized.

Show comment
Hide comment
@FreeApophis

FreeApophis Aug 7, 2018

How can anyone say this is just a cosmetic issue? (Only Framework developers ...)
Nobody thought of tools which are not installed? (.NET solved dll-hell, and .net core brings it back)

I just want my Command Line tool to be be self-contained.

This is bad, really bad!

FreeApophis commented Aug 7, 2018

How can anyone say this is just a cosmetic issue? (Only Framework developers ...)
Nobody thought of tools which are not installed? (.NET solved dll-hell, and .net core brings it back)

I just want my Command Line tool to be be self-contained.

This is bad, really bad!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment