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.

[sgf]

@Cryru Things like not being able to build a standalone executable, and the oblivious dismissal of the very real need to do so. Pretty much every other build system in existence will not only build a statically linked executable, it will strip unused parts of dependencies. Stripping dependencies has been a standard feature for at least a decade; static linking since the invention of compliers.

Agree,This is actually related to the position of C # programs in the operating system. C# programs always cant became the a First-class citizen. Only to be the Second-class.

[giggio]

This is resolved. TLDR: dotnet publish -r win10-x64 /p:PublishSingleFile=true

Details: https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotnet-core-3-0#single-file-executables https://github.com/dotnet/designs/blob/master/accepted/single-file/design.md

[mihaimyh]

This is resolved. TLDR: dotnet publish -r win10-x64 /p:PublishSingleFile=true

Details: https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotnet-core-3-0#single-file-executables https://github.com/dotnet/designs/blob/master/accepted/single-file/design.md

In which version of dotnet-core was this feature added? I am using 3.0.100-preview5-011568and got this error: error MSB4030: "/p:PublishSingleFile=true" is an invalid value for the "SelfContained" parameter of the "ResolveFrameworkReferences" task. The "SelfContained" parameter is of type "System.Boolean".

LE: Actually it is working, it seems only there is a syntax error in the https://github.com/dotnet/designs/blob/master/accepted/single-file/design.md which states publishing with dotnet publish -r win10-x64 --self-contained /p:PublishSingleFile=true and actually is without adding --self-contained.

[swaroop-sridhar]

Thanks @mihaimyh I'll fix the typo in the design doc.

[sgf]

im always against using zip/unzip solution for Single exe self contained feature. because this will cause the next issue. How to reduce the Single exe file size !

In fact, from the outset should use IL-Merge similar ways.

[jnm2]

I explicitly want single-file without AOT. I prefer the ability to JIT so that I can use reflection, generics, and runtime-generated code.

[PRIMETSS]

im always against using zip/unzip solution for Single exe self contained feature. because this will cause the next issue. How to reduce the Single exe file size !

Not sure I understand, as if its Zipped its already compressed. Or are you meaning reduction of redundant dependencies and therefore reduced size before compression?

[PRIMETSS]

Not understanding the negativity. Ive not used it yet other than quick test. But seems the single executable works well for the situation deploying an app to client, or as a CLI tool. Which is where I believe this feature is useful. Outside of that, in Dev or other environment I dont see a use case for it, so what they have done works fine as a solution for now..

[jnm2]

@RUSshy

i guess MS don't want to hear, ok

On the contrary, they are asking for and collecting a wide range of use cases which you can see in related threads. Your opinion is important, but the opinions of others in the community are just as important and you should not be mocking Microsoft for listening to them.

Based on your statement I think you might have mistaken me for Microsoft. I'm just a community member like yourself who does not speak for Microsoft in any capacity.

[sgf]

im always against using zip/unzip solution for Single exe self contained feature. because this will cause the next issue. How to reduce the Single exe file size !

Not sure I understand, as if its Zipped its already compressed. Or are you meaning reduction of redundant dependencies and therefore reduced size before compression?

if u use WebApi or MVC or ConsoleApp write an HelloWorld! ur well know what my mean. the packed file is too large.its bring too much code but never will be execute. if IL-Merge ways will Reduce unused code branch.

[PRIMETSS]

Yes sure I did a console HelloWorld and yes sure its 68K The none self contained was 67K But its C# not assembly. If I wanted a <1K HelloWorld then why use c#? Larger apps use more of the framework, so at a point its more custom code than framework.. Are we really worried about a few 100K? If so, dont use a framework and spend the time writing everything from scratch?? What am I missing here?

[swaroop-sridhar]

im always against using zip/unzip solution for Single exe self contained feature. because this will cause the next issue. How to reduce the Single exe file size ! if u use WebApi or MVC or ConsoleApp write an HelloWorld! ur well know what my mean. the packed file is too large.its bring too much code but never will be execute. if IL-Merge ways will Reduce unused code branch.

@sgf there are two somewhat separate issues here:

• How to reduce the code for an app?
• How to package the app into a single file?

For code-reduction, there are further several techniques

• Merging IL: This is not for all apps, because it loses assembly identity in the process. This is not a goal for the current single-exe work.
• Trimming unused IL: The ILLinker aims to trim unused IL. This feature is integrated into the dotnet SDK (PublishTrimmed property), and more optimizations in the ILLinker are under development.
• Zip/Unzip: dotnet publish doesn't currently zip the published single file, but it can be done.

How to package the app into a single file? dotnet publish supports publishing into a single file -- the published file will be as big as the app would otherwise be.

Regarding the generating native code:

• Currently the support for generating native code is through ready-to-run compiler (PublishReadyToRun property).
• Publishing via AOT compilation is great (CoreRT), but it is not available yet. With AOT compilation too, the size of the executable depends on the compilation options: ex: do we include the jit for executing generated code, etc.?

[sgf]

Yes sure I did a console HelloWorld and yes sure its 68K The none self contained was 67K But its C# not assembly. If I wanted a <1K HelloWorld then why use c#? Larger apps use more of the framework, so at a point its more custom code than framework.. Are we really worried about a few 100K? If so, dont use a framework and spend the time writing everything from scratch?? What am I missing here?

sorry as ur img shown,with self contianed.Thats 68626KB,its about 68mb=68KK,not only 68K!!! we wont need <1kb (With self contianed That's impossible),<3000KB is ok,accept. But 68mb is more 30X+ U wont always just write a HelloWorld Program !!!

[PRIMETSS]

Apologies, late at night mistake with the K's Thanks for the added explanation/info swaroop-sridhar, some new switches there I was not aware of. Just tried with 3.preview 6 with the following switches

dotnet publish -r RID /p:PublishTrimmed=true /p:PublishSingleFile=true and now down to 29,000K

Sure not all apps will be Hello World, but for a C# Core SelfContained App, that also contains the runtime... Personally Im not to worried. Sure I understand if your writing a tiny console tool it would be nice to have it 3K. But why use C# for that in the first place? Interesting discussion though guys!

[stay2be]

30mb LOL, call me when it'll be something like 1-3mb, runtime is full of bloat, check GO, people migrate in wave

https://www.jetbrains.com/lp/devecosystem-2019/

Even kotlin starts to gain shares, and with kotlin native it put c# to shame

And Swift is comming to windows https://forums.swift.org/t/swift-win32-programming/20686

So here some suggestions:

• Add option to remove Reflection
• Add option to remove JIT stuff
• Better optimize C# code so you don't rely on JIT

I think this is not fair. .NET was not designed for building the smallest single file console applications. We use it for Asp.Net websites and apis. Therefore, the framework itself brings a ton of features with it in addition to tons of nuget packages that you can include. I can't imagine that there is a concern if an web application is 50 or several hundreds of megabytes in size. The primary concern is speed, memory usage and in the long term maintainability. Who cares about the size on the server.

If your only intention is to built small single mb size console application, why not use the right tool for the job. Instead of complaining that an application with a full featured framework packed into a single file is several tens of megabyte in size even for a "hallo world", why not go with Rust for example?

Microsoft is doing a great job with .NET since its beginning and even more in the last couple of years, so thank you for that.

[jnm2]

Sorry if i sound rude but

You sound rude, period. That, and your dismissals and jumping to conclusions, do not have the effect of being persuasive.

[sgf]

Apologies, late at night mistake with the K's Thanks for the added explanation/info swaroop-sridhar, some new switches there I was not aware of. Just tried with 3.preview 6 with the following switches

dotnet publish -r RID /p:PublishTrimmed=true /p:PublishSingleFile=true and now down to 29,000K

Sure not all apps will be Hello World, but for a C# Core SelfContained App, that also contains the runtime... Personally Im not to worried. Sure I understand if your writing a tiny console tool it would be nice to have it 3K. But why use C# for that in the first place? Interesting discussion though guys!

don't as a modern language should have a little ambition to unify the world? Do you want all developers writing c# back home for C++? or push them to Go,Kotlin,Swift ? Market share and further erode c#?

.Net because does not implement cross-platform missed the first 15+ years of the great development opportunity. But Now .net is back to right Way.

[PRIMETSS]

Yeah as I commented before Im not sure why the negativity. .Net Core has been nothing but fantastic if you are coming from Full Framework. And the .Net Standard +Core amalgamation vision I think is sensible and progressive.

Comparing .NET to GO or any other language/framework is pointless. Anyway, Im OUT on this topic, as I think the solution they are working on and improving for Single .exe has resolved my 'ask' from several years back quite well... Good enough for me, and suits my immediate needs.

So thanks Guys & Gals!

OUT

[karelz]

I would like to remind everyone on this thread about Code of Conduct.

It is ok to disagree or have different opinion, but please, let's be civil and let's express that as technical discussion. No need to use strong words. Also, targeting ideas, implementations with your opinions is fair game. HOWEVER, it is NOT ACCEPTABLE to attack PEOPLE behind them. Please let's all be respectful to each other, let's hear different opinions and let's refrain from strong statements and offensive comments.

Also, I wold like to ask everyone to be open to other view points and opinions. Before making judgements, it is typically good to hear out the other side -- there is often a story behind why things are the way they are. Poking at ideas and solutions when one knows why they are the way they are is typically more productive.

Thank you!

[sgf]

im always against using zip/unzip solution for Single exe self contained feature. because this will cause the next issue. How to reduce the Single exe file size ! if u use WebApi or MVC or ConsoleApp write an HelloWorld! ur well know what my mean. the packed file is too large.its bring too much code but never will be execute. if IL-Merge ways will Reduce unused code branch.

@sgf there are two somewhat separate issues here:

• How to reduce the code for an app?
• How to package the app into a single file?

For code-reduction, there are further several techniques

• Merging IL: This is not for all apps, because it loses assembly identity in the process. This is not a goal for the current single-exe work.
• Trimming unused IL: The ILLinker aims to trim unused IL. This feature is integrated into the dotnet SDK (PublishTrimmed property), and more optimizations in the ILLinker are under development.
• Zip/Unzip: dotnet publish doesn't currently zip the published single file, but it can be done.

How to package the app into a single file? dotnet publish supports publishing into a single file -- the published file will be as big as the app would otherwise be.

Regarding the generating native code:

• Currently the support for generating native code is through ready-to-run compiler (PublishReadyToRun property).
• Publishing via AOT compilation is great (CoreRT), but it is not available yet. With AOT compilation too, the size of the executable depends on the compilation options: ex: do we include the jit for executing generated code, etc.?

As required dynamic merge native-DLLs to One name likes: XXX.exe (UnManaged). Using static analysis to analysis when compile the nativeDLLs(UnManaged) Function-Level Linking.

api-ms-win-core-console-l1-1-0.dll
api-ms-win-core-datetime-l1-1-0.dll
api-ms-win-core-debug-l1-1-0.dll
api-ms-win-core-errorhandling-l1-1-0.dll
api-ms-win-core-file-l1-1-0.dll
api-ms-win-core-file-l1-2-0.dll
api-ms-win-core-file-l2-1-0.dll
api-ms-win-core-handle-l1-1-0.dll
api-ms-win-core-heap-l1-1-0.dll
api-ms-win-core-interlocked-l1-1-0.dll
api-ms-win-core-libraryloader-l1-1-0.dll
api-ms-win-core-localization-l1-2-0.dll
api-ms-win-core-memory-l1-1-0.dll
api-ms-win-core-namedpipe-l1-1-0.dll
api-ms-win-core-processenvironment-l1-1-0.dll
api-ms-win-core-processthreads-l1-1-0.dll
api-ms-win-core-processthreads-l1-1-1.dll
api-ms-win-core-profile-l1-1-0.dll
api-ms-win-core-rtlsupport-l1-1-0.dll
api-ms-win-core-string-l1-1-0.dll
api-ms-win-core-synch-l1-1-0.dll
api-ms-win-core-synch-l1-2-0.dll
api-ms-win-core-sysinfo-l1-1-0.dll
api-ms-win-core-timezone-l1-1-0.dll
api-ms-win-core-util-l1-1-0.dll
api-ms-win-crt-conio-l1-1-0.dll
api-ms-win-crt-convert-l1-1-0.dll
api-ms-win-crt-environment-l1-1-0.dll
api-ms-win-crt-filesystem-l1-1-0.dll
api-ms-win-crt-heap-l1-1-0.dll
api-ms-win-crt-locale-l1-1-0.dll
api-ms-win-crt-math-l1-1-0.dll
api-ms-win-crt-multibyte-l1-1-0.dll
api-ms-win-crt-private-l1-1-0.dll
api-ms-win-crt-process-l1-1-0.dll
api-ms-win-crt-runtime-l1-1-0.dll
api-ms-win-crt-stdio-l1-1-0.dll
api-ms-win-crt-string-l1-1-0.dll
api-ms-win-crt-time-l1-1-0.dll
api-ms-win-crt-utility-l1-1-0.dll
aspnetcorev2_inprocess.dll
clrcompression.dll
clretwrc.dll
clrjit.dll
coreclr.dll
dbgshim.dll
dotnet-aspnet-codegenerator-design.dll
hostfxr.dll
hostpolicy.dll
mscordaccore_amd64_amd64_4.6.27317.07.dll
mscordbi.dll
mscorrc.dll
mscorrc.debug.dll
sni.dll
sos.dll
sos_amd64_amd64_4.6.27317.07.dll
ucrtbase.dll
...etc...

if do good job the result maybe be willl 2-3mb. when im direct packed all of them with 7zip,its take about 4.85mb.Now we get XXX.exe

develop the similar Function-Level Link with IL-merge. For a managed DLL same old trick again. At Last embed managed DLL as the PE.exe Sections(mark as .net section).

For reflect,analysis DLL of the reflection type. Retain metadata and type of reflection ( including function ) and all of its tree - dependent.

[sgf]

I apologize, I don't want to take the more time to participate in the discussion about this any more.Opinions cannot be unified. At first I had expected the result. But now,I should probably consider other programming languages to fulfill my needs(maybe Dlang maybe Go maybe Kotlin maybe Nim or maybe Rust is the best).

thanks for all talk this with me. sorry for my nagging. out

[dazinator]

@sgf I think you made some good points and I know you've signed off on the topic. Just wanted to say that I believe the features you are asking for, will be coming over the next couple of years to .NET Core. In fact if you wanted to get small file size today, it may be possible if you target mono.

1. Mono already supports AOT compilation with Linking to reduce file size. This is one reason why mono was chosen for the browser .net runtime implementation. https://www.mono-project.com/docs/advanced/aot/ and I assume it's why Blazor projects can have a Linker.

2. Microsoft have declared that they want to cosolidate their .NET runtimes into one "all powerful" one. Rather than have mono for some things, and .NET Core for others, they want a single runtime that can deliver on all scenarios. This defacto means it will need to support AOT and Linking / Code stripping etc. Therefore I expect over the next few years, either the .NET Core runtime to get these features, or for Mono and .NET Core features to be consolidated into a new Runtime.

If anyone knows better, please inform me.

[Alan-FGR]

+2¢

I think the problem is it seems decisions are being made without much information. These days everywhere I look people are talking about this; the vast majority of people deploying programs have this on top of their wish list, and many are moving away from C# to other languages with better AOT/deployability. I think that's a pretty established fact which becomes very evident if you're active in the community. Yet it doesn't seem to be affecting the decisions in the slightest.

The thing is, it seems nobody knows exactly to what extent this is important. To me personally it's extremely important, so of course I'm very biased but the impression I have is that overall this is of prime importance and it seem MS just isn't giving it the attention it deserves, leaving a lot of us the impression they're taking uniformed decisions what in turn doesn't make us confident about the future of the technology as a whole.

I agree with @RUSshy. CoreRT is an incredible project and definitely going in the right direction, but overall it seems all efforts are focused on server/web technologies. Things like runtimes, jits and large binaries speak for themselves in that regard. Nobody deploying software want those things.

That being said I'm personally still using the tech although I'm not really holding me breath about its future in some areas.

I would like to see more participation from the community in the direction being taken, even if it turns out it's the opposite of what I'm personally expecting. But so far it seems decisions are being made without taking that into account. It seems server/web is what makes money and people deploying programs are a negligible minority (at least in terms of profits), but if that's the case I'd at least want to know that's what they're basing their decisions on (which is very likely), because from the outside it looks like they're flipping a coin.

[dazinator]

@Alan-FGR

But so far it seems decisions are being made without taking that into account.

Do you have specific examples of such decisions to share, as I'd be curious to learn more.

I think MS are very aware of the shortcomings of the current dotnet core runtime and that's why they will seek feature parity with mono runtime in the future.

Just look at the release notes for .net core 3.0.0 preview 6:

Today, we are announcing .NET Core 3.0 Preview 6. It includes updates for compiling assemblies for improved startup, optimizing applications for size with linker and EventPipe improvements. We’ve also released new Docker images for Alpine on ARM64.

It looks like to me they are very aware that application size is important for certain scenarios - especially now with Blazor in the mix.

[kjkrum]

@Alan-FGR Agreed, the web focus is rather strange considering that IIS has about 8% market share and falling. ASP.NET is irrelevant, and no improvement to C# or its standard libraries is ever going to change that. C# is being sustained by console apps, Windows services, mobile apps, and PC games. It owes its continued existence to Unity and Xamarin. Which is a shame, because C# is a really enjoyable language to develop in. That's high praise coming from a long time Java developer who still thinks Microsoft left its high water mark with Windows XP.

[swaroop-sridhar]

As required dynamic merge native-DLLs to One name likes: XXX.exe (UnManaged). Using static analysis to analysis when compile the nativeDLLs(UnManaged) Function-Level Linking.

I'm not sure what you mean by dynamic merge, but there is a plan to statically link the native components together with the host. Please see this section.

develop the similar Function-Level Link with IL-merge. For reflect,analysis DLL of the reflection type. Retain metadata and type of reflection ( including function ) and all of its tree - dependent.

We've discussed the option of merging assemblies into one, and having side meta-data tables to support dynamic features. It does provide considerable size-savings. But the cost of implementing it is quite high -- because of the new meta-data support, and the changes required in debuggers/profilers etc to handle it.

There are a few other options to reduce the binary size -- for example, when we're able to execute a single-file directly (without having to extract to files), we can drop the signature/certificates on each DLL in favor of signing the app as a whole. This can save a few MBs sometimes.

[Alan-FGR]

But so far it seems decisions are being made without taking that into account.

Do you have specific examples of such decisions to share, as I'd be curious to learn more.

I think MS are very aware of the shortcomings of the current dotnet core runtime and that's why they will seek feature parity with mono runtime in the future.

@dazinator I think the very fact that MS somehow thinks Mono is a decent solution for anything goes to show that they really don't know their products. I've used Mono, and while it's an important piece of tech and helped popularize .NET immensely, it's definitely lacking some quality... Xamarin did some great marketing work promoting their tech, but it was based on over-promising and under-delivering, and it seems that whoever is taking those decisions at MS just saw some of their promo material and never really used the tech. CoreRT on the other hand is a technology that so far has greatly over-delivered for me. It's on another level of quality in my opinion, and yet it's being neglected by MS in favor of some tech that I suspect is held together with duck tape.

Agreed, the web focus is rather strange considering that IIS has about 8% market share and falling. ASP.NET is irrelevant, and no improvement to C# or its standard libraries is ever going to change that. C# is being sustained by console apps, Windows services, mobile apps, and PC games.

@kjkrum that's the point. However, maybe for them 8% market share on the web is still much more important than the Windows and mobile apps. Good web techs at very least help Windows server sales, so their interest on that is quite obvious, but focusing so much on it is also a very shallow strategy and I refuse to believe that's what drives their decisions. MS seemed to be going the right direction with the dotnet foundation and so many promising projects going on, but it seems they're letting the opportunity to have a dominant tech pass by.

I know this is anecdotal so probably meaningless, but all the people I know who were using C# for their projects (mostly game dev) moved into something else because of limitations that were totally solvable. They moved to Rust, D, Go, and C++. I myself use C++ on a regular basis and I'm learning Rust, but I'm still using C# for some personal projects because it's so much better, even though deploying a quality product is a pain in the rear.

It owes its continued existence to Unity and Xamarin.

Yes, what's a blessing and a curse because of the many technical problems. Unity for example has a very bad reputation but luckily that didn't seem to affect .NET/C#. XNA however, although far from perfect still has an incredibly great reputation among users and developers.

[mattjohnsonpint]

Happy to see this land with .NET Core 3.0 today. Thanks folks! 👍

[jnm2]

Yes, it's definitely what I want. It's still smaller than a regular self-contained deployment.

More aggressive assembly trimming and tree-shaking would be welcome, but this is a very useful start. Incremental improvement is the smartest way to deliver value.

[jnm2]

@RUSshy It's no more bloated than any other self-contained deployment, right?

Removing JIT and reflection is independent from whether everything is packed into a single exe. I.e. you can remove JIT and reflection without single-exe, and you can have single-exe without removing JIT and reflection. They are separate pieces of work.

[sgf]

I'm not sure that is what people want, if we end up with simple calculator that is 141mb exe, then the feature is a failure (and i believe the real cost is 141mb * 2, since it's gonna extract stuff somewhere right)

its extract the files in to C:\Users[YourUserName]\AppData\Local\Temp.net\

[eiva]

Is there any way to override where single exe will be unpacked? I ran into problem when it try to extract into /var/.... where user have no permissions to write.

[swaroop-sridhar]

@eiva which OS was this? Was it AWS lambda? https://github.com/dotnet/core-setup/issues/7940 tracks fixing this issue.

In the meantime, you can set the DOTNET_BUNDLE_EXTRACT_BASE_DIR environment variable to control where the bundled files are extracted.

[eiva]

@swaroop-sridhar Thanks for the reply! It is centos.7 launching app from the "restricted" service account.

[TechnikEmpire]

@jnm2 I appreciate that you love C#, I do too. But lets be honest, it's insanity that a calculator is 128 megabytes.

[jnm2]

@TechnikEmpire I feel it necessary to point out that that "I love C#" is a pretty intensive reduction of what I said above :D

I'm personally not going to feel entirely satisfied until I have the ability to do tree-shaking of my own code and libs, referenced third party libs, and .NET itself. But that doesn't make the single-exe feature any less valuable to me today. It's a step along one dimension. Tree-shaking is an independent dimension and one that I hope gets a lot of attention.