Debug symbols settings are different between local and official builds

[eerhardt]

Local builds should be as similar as possible to official builds. That way we can get consistent behavior and we can reproduce locally when official builds break.

However, this isn't the case w.r.t. DebugType:

arcade/src/Microsoft.DotNet.Arcade.Sdk/tools/ProjectDefaults.props

Lines 31 to 38 in c306937

	Jenkins build:
	- Embed PDBs to make it easier to debug Jenkins crash dumps.
	Developer build:
	- Embed PDBs to be consistent with Jenkins builds.
	-->
	<DebugType>portable</DebugType>
	<DebugType Condition="'$(OfficialBuild)' != 'true'">embedded</DebugType>

You can see above that DebugType=embedded when it isn't an official build, and the comments around it refer to Jenkins (which is no longer being used).

We should have this to always have portable be the default DebugType whether this is a dev build, CI, or official build. That way people (like me) who are using snupkg packages aren't confused when their .snupkg files are empty and don't contain any symbol files.

/cc @tmat @markwilkie @safern

[tmat]

This behavior is intentional.

The comment wording is outdated but the comment is still valid. We use embedded symbols in PR validation builds so that crash dumps captured on these builds are easily debuggable (note that PR validation builds do not publish the symbols to any symbol server).

As the comment also says the local builds have embedded PDBs enabled so that they are the same as PR validation build.

[tmat]

BTW, Arcade currently does not support snupkgs. Once it does it will account for this difference and not produce snupkgs locally.

[eerhardt]

I'm not convinced this should be the default behavior. IMO it is very surprising for arcade to change things that are defaulted in the official product

Arcade currently does not support snupkgs

Can you link to the work item for this? It is working for my repo by just setting:

    <IncludeSymbols>true</IncludeSymbols>
    <SymbolPackageFormat>snupkg</SymbolPackageFormat>

And of course overwriting DebugType back to portable.

Once it does it will account for this difference and not produce snupkgs locally.

This is just compounding the problem IMO. What started out as a little difference is making waves even further out. Why is it acceptable for local builds and official builds to be so different that some produced assets aren't even possible to get on a local build?

[tmat]

#1959

Yes, you can generate them. But the publishing logic is not ready for snupkgs.

Why is it acceptable for local builds and official builds to be so different that some produced assets aren't even possible to get on a local build?

"We use embedded symbols in PR validation builds so that crash dumps captured on these builds are easily debuggable"

[tmat]

Why do you care for snupkgs in local builds? They are useless. The only purpose of snupkgs is to deliver symbols to NuGet.org when packages are published.

[eerhardt]

"We use embedded symbols in PR validation builds so that crash dumps captured on these builds are easily debuggable"

I would have thought that this goal could be achieved by other means. Perhaps the crash dump process could load/store the symbols while creating the dump. Or whomever is capturing the dump could also capture the symbols in PR validation.

This doesn't seem to be an isolated issue just for projects using arcade.

Why do you care for snupkgs in local builds?

I care that the outputs of my build are as consistent as possible. That way I can ensure my build is doing what I expect it to be doing without having to submit official builds to test it.

They are useless.

Not necessarily - If I give someone a locally built .nupkg for testing/evaluation, how would I give them the symbols that go with it?

[tmat]

I care that the outputs of my build are as consistent as possible. That way I can ensure my build is doing what I expect it to be doing without having to submit official builds to test it.

They are as consistent as possible, but not more than that :). There is certainly a trade-off in certain aspects like (symbol) publishing, signing, etc.

I would have thought that this goal could be achieved by other means. Perhaps the crash dump process could load/store the symbols while creating the dump. Or whomever is capturing the dump could also capture the symbols in PR validation.

It would certainly be possible but it would require major changes in procdump (the tool that captures crash dump) and the debugger to make it all work end-to-end.

This doesn't seem to be an isolated issue just for projects using arcade.

Indeed. I would recommend everyone using embedded PDBs everywhere, except for when they are building official packages that need to be optimized for size.

Not necessarily - If I give someone a locally built .nupkg for testing/evaluation, how would I give them the symbols that go with it?

That's the best part - you don't need to give them separate symbol package because the PDBs are embedded in the DLLs that are in the main package. Debugging will just work.

[markwilkie]

@eerhardt - thoughts on next steps for this issue?

[eerhardt]

Doesn't sound like this is something that will be changed.