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
.NET core app does not start when published with /p:PublishSingleFile=true
#10523
Comments
Reading in the document at https://github.com/dotnet/designs/blob/master/accepted/single-file/design.md : I found this paragraph interesting:
I found this interesting because the error message from the published app (quoted above) mentions a file with a name ending in
But, on the other hand, the linked document also contains following:
So the |
I've seen one or two other reports about errors when RID-specific content is involved together with single-file publishing. the deps.json shouldn't contain links to runtimes/* folders when the app is published rid-specific, which is the case for single-file apps. |
Adding <PropertyGroup>
<IncludeSymbolsInSingleFile>true</IncludeSymbolsInSingleFile>
</PropertyGroup> Could help in your situation, but I'm not sure and even if, it shouldn't be necessary in the first place. |
Experiment according to findings reported at https://github.com/dotnet/cli/issues/12723#issuecomment-535614970
I added this to the I confirm this helps, at least the app seems to start normally. I did not find a problem with the apps behaviour when published from that version. Adding the |
@Viir: This problem here is that the app's definition (as dictated by the The correct fix is to not have the PDB file required by deps.json. This dependency likely comes in because of one of the dependencies of the apps (via nuget packages). This issue is similar to PowerShell/PowerShell#10266 From the host point of view, this bug is a dup of dotnet/core#3455 (comment). |
CC: @dsplaisted |
It is strange that pdbs would ever be in deps.json like that. I gues nuget thinks this is a native library? |
if I understand the linked issues correctly powershell removes their PDBs. I don't think that files in native folders should be assumed to be of special type.. it is valid that PDBs shouldn't be runtime libs trying to be loaded by the host. But also removing them from the publish (single file) seems off since the NuGet package should be free to include whatever is necessary - that may be symbols for native libs (pdb,dsym,..) for stack traces or just txt/dat files. |
@dasMulli the exclusion of PDB is just a default, and can be overridden by I'm not sure if there is anything else actionable for this issue. |
@swaroop-sridhar thank you for the quick clarification. Does this mean the So far, I did not find such a warning in the output from |
Sure, the since the SDK generates the deps.json file, it is possible to generate a warning if PDBs are included in deps.json files. It is also possible to adapt the default to include the required PDBs in the single-file -- but this will silently hide a likely bug in one of the dependent packages and make the app larger unnecessarily. I filed #3685 to track this. |
Closing this issue as there is a sdk issue tracking the action item from this thread. |
How can I use publishing of single-file executables?
I tried to follow the instructions from https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotnet-core-3-0#single-file-executables, but this did not work:
Steps to reproduce
publish
the .NET core app in this directory: https://github.com/Viir/bots/tree/82ef37f3089a3e40bd496f507b691a5c25011b33/implement/engine/BotEngine.Windows.Console , using the following command:The publish command produced following output in the console:
./botengine
Expected behavior
I expected the single-file executable app to behave the same way as when published without the
/p:PublishSingleFile=true
option.When published without the
/p:PublishSingleFile=true
option, the apps output starts as follows:Actual behavior
When trying to start the app, it outputs the following message:
and then exits.
Environment data
dotnet --info
output:The text was updated successfully, but these errors were encountered: