Single exe self contained console app

[mattjohnsonpint]

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 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]

CoreRT is the right place to search for this solution.

[mattjohnsonpint]

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

For others that may stumble on this, read here

[jnm2]

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]

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

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]

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]

@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]

Possibly related: dotnet/core#600

[thefringeninja]

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]

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]

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]

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]

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