Discussion: Change default DebugType to embedded for .NET Core 3
Inspired from this issue and twitter thread https://github.com/dotnet/docs/pull/9110 https://twitter.com/rrelyea/status/1064587440935956482 I want to propose that the default `DebugType` in the SDK change from `portable` to `embedded`. I would also propose that Sourcelink be included/used by default. At the very least, there should be one property `ConfigureOpenSourceDefaults` that turns these on as best practices. My rationale is driven by the pit of success. I believe that out-of-the-box, developers should produce fully debuggable code. This is similar to how JS typically generates/includes sourcemaps by default, so there is precedent. Few notes: - Embedding a pdb yields a file size that's 20-30% bigger. - Some .NET tools, like .NET Native do not support symbol server; the symbols need to be alongside the dll - Symbol server significantly slows down VS debug startup as it probes for files Some things like Appx/MSIX packaging strip-out pdb files by default. They rely on extra properties (`AppxPackageIncludePrivateSymbols`) to include them, which I'm sure 99% of people wouldn't know to add. Without them, the stack traces aren't as useful. Symbol servers may be blocked by corporate firewalls, or otherwise affected by low-bandwidth connections (think airplanes, trains, mobile hotspots, and anywhere else with slower/spotty connections). I believe that the extra size of the files with embedded pdb's is worth the trade-off for most cases as it presents the best debugging e
Posted by clairernovotny on Nov 19, 2018, 8:11 PM
Tags
Related issues
- ⚠️ PHP CVEs. Update required!
- I think RTS could continue to work if someone made a massive leap of faith and put all the modern infra around it that a AAA extraction s...
- RFC: Pluggable SessionDB Provider — PostgreSQL, MySQL, and Beyond
- v2.1.113+ broken on Termux/Android: native binary requires glibc, no JS fallback
- I’m firmly anti-Tahoe and haven’t updated, and I’ve started to find Apple despicable.
- [FEATURE] Link a source control repo as the source for organization skills
Raise real-world problems, find people facing the same issue, and discuss solutions.4,000 issues0 comments
reliability (Sysadmin)
⚠️ PHP CVEs. Update required!
I think RTS could continue to work if someone made a massive leap of faith and put all the modern infra around it that a AAA extraction s...
RFC: Pluggable SessionDB Provider — PostgreSQL, MySQL, and Beyond
v2.1.113+ broken on Termux/Android: native binary requires glibc, no JS fallback
I’m firmly anti-Tahoe and haven’t updated, and I’ve started to find Apple despicable.
[FEATURE] Link a source control repo as the source for organization skills
Feature Request: Option to disable paste text collapse in input field
We went down the WASM sandboxing rabbit hole at Gobii when building our agent infra.
Discussion: Change default DebugType to embedded for .NET Core 3
Inspired from this issue and twitter thread https://github.com/dotnet/docs/pull/9110 https://twitter.com/rrelyea/status/1064587440935956482 I want to propose that the default `DebugType` in the SDK change from `portable` to `embedded`. I would also propose that Sourcelink be included/used by default. At the very least, there should be one property `ConfigureOpenSourceDefaults` that turns these on as best practices. My rationale is driven by the pit of success. I believe that out-of-the-box, developers should produce fully debuggable code. This is similar to how JS typically generates/includes sourcemaps by default, so there is precedent. Few notes: - Embedding a pdb yields a file size that's 20-30% bigger. - Some .NET tools, like .NET Native do not support symbol server; the symbols need to be alongside the dll - Symbol server significantly slows down VS debug startup as it probes for files Some things like Appx/MSIX packaging strip-out pdb files by default. They rely on extra properties (`AppxPackageIncludePrivateSymbols`) to include them, which I'm sure 99% of people wouldn't know to add. Without them, the stack traces aren't as useful. Symbol servers may be blocked by corporate firewalls, or otherwise affected by low-bandwidth connections (think airplanes, trains, mobile hotspots, and anywhere else with slower/spotty connections). I believe that the extra size of the files with embedded pdb's is worth the trade-off for most cases as it presents the best debugging e
Comments (0)
No comments yet. Start the discussion.