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

[dazinator]

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]

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]

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

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

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:

[PRIMETSS]

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]

@Scellow @PRIMETSS I have to agree

[AnalogMan151]

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

[hkoelewijn]

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]

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

[FlsZen]

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

[FreeApophis]

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!

[ghost]

+1

[stansw]

+1 I've just tried to run custom activity in Azure Batch on a cluster without .net core runtime and it cannot handle the high number of files the "self-contained" version creates.

Total size of resourceFiles cannot be more than 32768 characters

[dgiagio]

This isn't an official solution, but it might be useful. I'm the author of warp, a tool that allows you create self-contained single binary applications: https://github.com/dgiagio/warp

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