Publish Single-file: Smart settings for IncludeSymbolsInSingleFile
See original GitHub issueWhen publishing an app as a single file, the default setting is to not include PDB files in the output bundle by default (and instead leave them as separate files).
However, this setting is unsuitable for some apps, where the deps.json
file includes a dependency on the PDB file. This causes runtime-crash of the app when the apphost
validates the contents against the deps.json manifest. For example:
https://github.com/PowerShell/PowerShell/issues/10266
https://github.com/Viir/bots/tree/adapt-for-single-file-exe-publish
The inclusion of PDB files as a dependency is almost always an error, but an app (and its dependencies/nuget packages) are not required to associate the same semantics with file-extensions.
So, if the deps.json writer finds a PDB file in the manifest, the SDK should default the IncludeSymbolsInSingleFile
setting to true. The SDK should also issue a warning about this change, so that PDBs are not silently included – unintentionally increasing the size of published apps.
Issue Analytics
- State:
- Created 4 years ago
- Reactions:8
- Comments:11 (10 by maintainers)
Top GitHub Comments
Great points. At the end of the day, we have to uniformly decide if something is a symbol file or not. If we decide it is not a symbol file, but an arbitrary native asset, then it should be in deps.json AND deployed irrespective of IncludeSymbolsInSingleFile. And if we decide it is a symbol file, then it should not be in deps.json AND included in single file if and only if IncludeSymbolsInSingleFile is true.
NuGet and the assets files should be the source of truth for what files in package are what kind of thing. If we decide to use extension heuristics for this, then they should go in nuget. SDK should respect what NuGet tells us.
I will combine this issue and the issue of not copying managed PDBs into one feature request for nuget.
To double down: Does
IncludeSymbolsInSingleFile
also apply to dsym files? I think there should be parity for each runtime if that is the case, so leaving native pdb / dsym / * files alone and not applying filters to that or encoding the knowledge about all kinds of symbol files.