Request: Set IncludeNativeLibrariesForSelfExtract default to true

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

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

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