Request: Set IncludeNativeLibrariesForSelfExtract default to true

[rgwood]

.NET lets you publish executables as a single file using the PublishSingleFile MSBuild property, but native libraries are not included by default; you need to set the IncludeNativeLibrariesForSelfExtract property to include native libraries.

Could this be changed so that setting PublishSingleFile automatically includes native libraries in the single file?

Reasoning

The current behavior is arguably unintuitive; in my experience users expect PublishSingleFile to publish a single file and are confused when it creates multiple files. Many first-party technologies (WPF, WebView2, Microsoft.Data.Sqlite) use native libraries so this is a fairly common scenario.

There are a lot of Stack Overflow questions where users have been confused by the defaults: 1 2 3 4 5 6 7 8 9 10

It has also come up on the dotnet repos: 1 2

Risks

This would be a breaking change; someone could be using PublishSingleFile and relying on the current behavior. I think that's a relatively low risk, since most people who use PublishSingleFile on its own just want just a single file.

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[agocke]

This seems reasonable to me. FYI -- the reason it's not the default is that including + extracting is slightly slower in the first start, and it's more complex, so there are some corner cases where it can go wrong (e.g., file being deleted from a temp dir out from under you).

That said, I agree it's not intuitive, and we've gotten a lot of questions about it. I think having it set by default is probably the right move. @richlander @vitek-karas @VSadov any thoughts?

[richlander]

LGTM

[vitek-karas]

I have to disagree. That's what we've done in 3.1 and 5 and there were lot of issues with the self-extract, to list the most serious problems we've faced (and haven't really solved):

• Reliability
  • On Windows AV software frequently causes problems and we had to add retries and all kinds of heuristics to make the process at least reasonably usable - as far as I know there's no truly reliable solution to this problem.
  • On all OSes there are tools which delete files in temp - breaking apps. We had to add lot of complexity (and startup perf hits) to compensate. Again no known way to make this truly reliable.
• Unexpected behavior
  • For the above reasons we moved the extraction to HOME, some of the issues are better, but now there are users complaining that we don't cleanup afterwards (we leave the extracted files behind, as a cache). I'm not aware of a good solution to this - it's like recreating installers in a way.
  • People don't expect the self-extract behavior - they're surprised that we're trying to write to disk, especially on startup
  • Fails on some configurations in Linux (I think systemd services are still like that) - we rely on some relatively standard apis/env variables, but there's always another Linux distro which does things differently
• Security problems
  • Hopefully all fixed, but who knows
• Performance
  • It's pretty slow to start for the first time if there's lot of files to write to disk - no known fix, just workarounds (like the request to add the ability to provide a splash-screen)

In addition the "hybrid" mode where some files are extracted (but not all) adds another problem - there's not a single "application directory" - some programs struggle with this.

There are obviously downsides to the current 6 default, the fact that it's not truly one file the most obvious one. But the upside is that most of the above issues are nonexistent. For me the reliability going up is the most important reason.

It's unfortunate that we call this feature "Single" file, because it's really not, but that's not something we're about to change.

I do agree that this behavior causes confusion, but to me that's something which is mostly solvable (maybe we need better docs). The reliability issues above are much harder to solve and never really 100%.

It's reasonable to design the solution such that frameworks like WPF would not require any additional files on disk (we would have to increase number of hosts, or add the ability to link within SDK). So then it would be about user's native libraries (and again, some of that is solvable).

[rgwood]

I think systemd services are still like that

Can confirm, I've run into that recently. Thankfully the note in the documentation got me past the issue quickly.

I can appreciate that the file extraction approach has some issues. But I'd question whether defaulting IncludeNativeLibrariesForSelfExtract to false helps with those issues; my guess is that most people just forge ahead and set IncludeNativeLibrariesForSelfExtract to true after noticing the multiple files. I do and I've been happy enough with the self-extract functionality.

[agocke]

Vitek's raised some really good points. I wonder if there are solutions other than setting extraction to be the default. There are a couple options:

1. Improve discoverability. We could have the CLI print a message when publishing with native files that native files are not included in the bundle, and give an aka.ms link with information on extracting them.
2. Make a Windows Desktop version of the host. A lot of people have native files because Windows Desktop has native dependencies. If we provide a Windows Desktop host we could avoid the extra native files, and potentially improve performance.
3. Offer an advanced scenario for statically linking extra native libraries into the host itself. This would give full control to the user.