WindowsAppSDK
WindowsAppSDK copied to clipboard
.NET publish as single file is broken (also dependency file is missing entries)
Describe the bug
Internal bug: https://task.ms/37013389
Rohan found two gaps in the .NET publish scenario (after fixing the basic scenario using https://microsoft.visualstudio.com/WinUI/_git/Microsoft-WinUI-Sdk/pullrequest/6634696):
Single file publish doesn't work as expected and it's not just us:
- Tried deleting Microsoft.WindowsAppRuntime.Bootstrap.dll, resources.pri and coreclr.dll (one at a time) and running the EXE. Didn't work.
- Fixing this for our two files here may be easy enough, but the fact that binaries like coreclr aren't marked for bundling seems bad (we shouldn't need to do anything for them). Makes me think that the single file scenario may not be broken just for WAS.
To be clear, the expected behavior here is that there is just a single file in this publish dir, namely the exe.
Second issue: The dependency file (<app_name>.deps.json) generated doesn't have the two WAS files not bundled in the single file case, namely resources.pri and Microsoft.WindowsAppRuntime.Bootstrap.dll.
- In the non-single file case, the deps file is also published. In the single file case, as you can see above, it isn't.
- I don't know what the impact of this is exactly...
Steps to reproduce the bug
See above
Expected behavior
No response
Screenshots
No response
NuGet package version
1.0.0-preview3
Packaging type
Unpackaged
Windows version
No response
IDE
No response
Additional context
No response
Please ensure this gets fixed. Should really be a priority that enabled features work as expected.
Heads up: Microsoft.WindowsAppRuntime.Bootstrap.dll
is native code and isn't normally merged into the app with .NET single file publishing.
Adding --self-contained true
or /p:IncludeNativeLibrariesForSelfExtract=true
should clean that up.
IMHO if the feature is called "Produce single file" then it should do exactly that. Everything else goes straight against the naming. /p:IncludeNativeLibrariesForSelfExtract=true
is not even exposed by the publishing wizard.
Thanks Rafael - sounds like we might be holding it wrong with native libs, although the default .NET SDK build behavior should warn that a native dll is being omitted. There may be general SelfContained issues beyond that, since coreclr.dll is also not being bundled.
I would also note that only zero-config (xcopyable) apps are candidates for SelfContained. An app with any install logic, like forking WindowsAppRuntimeInstall.exe, is out of scope.
I am having a similar issue.
When I Publish my Application with the Single-File Compile Option checked, I am left with 3 Files: The actuable Executable, "Microsoft.WindowsAppRuntime.Bootstrap.dll" and "resources.pri".
So far I've not been able to include the DLL (or resources.pri) inside the Single File Publish.
Is there a fix for this or?
You have to manually edit the publish.xml file by putting the aforementioned option into it.
You have to manually edit the publish.xml file by putting the aforementioned option into it.
This has actually resolved the issue for me with the Bootstrap DLL, but now I am still left with 2 files. Now though it is the "resources.pri" file.
As mentioned by @andrewleader deleting the file results in the application completely breaking.
Changing the build action of the assets to either Resource or Embedded Resource doesn't resolve the issue either. Publishing the Project with the "Self Contained" option set to 'true' also doesn't fix the problem in this case.
Does anyone have a fix for this as well or?
I think there is no fix available yet.
And how long will it take when Microsoft fix it?
Any updates due to this issue?
Just ran into this issue, I was able to remove Microsoft.WindowsAppRuntime.Bootstrap.dll by using the recommendations above but still have the issue with the Resources.pri
file. Are you aware of any workarounds I can use until this is resolved?
This is currently a blocking issue.
@jonwis
Ping @BenJKuhn @Scottj1s
- @evelynwu-msft
Are there any plans to fix this issue? It's been an issue for years.
Still an issue in .NET 6. Also entirely broken when using "WindowsAppSDKSelfContained = true". Some communication would be nice.