-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Request: Set IncludeNativeLibrariesForSelfExtract default to true #24181
Comments
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. |
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? |
LGTM |
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):
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). |
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 |
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:
|
.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 theIncludeNativeLibrariesForSelfExtract
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 2Risks
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 usePublishSingleFile
on its own just want just a single file.The text was updated successfully, but these errors were encountered: