Add source linking information during the build

[miniksa]

Summary of the Pull Request

I've been having trouble debugging some crashes because the source information is difficult to come by in Visual Studio and WinDBG. This adds SourceLink to link it up for Visual Studio and a script that @jevansaks created for MUX to create the srcsrv linkage for WinDBG.

PR Checklist

• Closes personal frustration against lack of source linking.
• I work here.
• I checked that the release build output (published to the symbol server) comes up and links appropriately in both WinDBG and Visual Studio to sources.
• Shouldn't need explicit doc.
• I am a core contributor

Validation Steps Performed

• I checked the release build I generated with this and it worked in WinDBG and Visual Studio

[DHowett-MSFT]

Does this need to be applied to Terminal(App|Connection|Control).dll as well?

[zadjii-msft]

I second Dustin's question about Terminal*.dll. If those need this as well, I'd say lets just throw these into the cppwinrt pre/post props we have

[miniksa]

Does this need to be applied to Terminal(App|Connection|Control).dll as well?

Yes, probably.

I second Dustin's question about Terminal*.dll. If those need this as well, I'd say lets just throw these into the cppwinrt pre/post props we have

I don't think I can put it into the pre/post props because it's a NuGet package. The NuGet packages get registered in this file that has to sit in the folder of every vcxproj, as far as I'm aware.

I can roll it out to the others, though.

[miniksa]

I still want to test this but the CI doesn't leave any artifacts behind on PR. I think I need to introduce a temporary piece of the build to dump the artifacts so I can fetch them out and ensure that this works in VS and WinDBG before being done.

[jevansaks]

I still want to test this but the CI doesn't leave any artifacts behind on PR. I think I need to introduce a temporary piece of the build to dump the artifacts so I can fetch them out and ensure that this works in VS and WinDBG before being done.

Can you just queue a CI build manually?

[miniksa]

I still want to test this but the CI doesn't leave any artifacts behind on PR. I think I need to introduce a temporary piece of the build to dump the artifacts so I can fetch them out and ensure that this works in VS and WinDBG before being done.

Can you just queue a CI build manually?

I'm not sure why queuing it manually would cause it to hold artifacts when there's no artifact saving step in the pipeline. Perhaps there's something I'm not aware of?

[DHowett-MSFT]

There's definitely an artifact saving step in the pipeline, but it's conditioned to not run for pull requests.

[DHowett-MSFT]

cf.

terminal/build/pipelines/templates/build-console-steps.yml

Lines 98 to 103 in 275b651

	- task: PublishBuildArtifacts@1
	displayName: 'Publish Artifact (appx) (Non-PR builds only)'
	inputs:
	PathtoPublish: '$(Build.ArtifactStagingDirectory)/appx'
	ArtifactName: 'appx-$(BuildConfiguration)'
	condition: and(succeeded(), ne(variables['Build.Reason'], 'PullRequest'))

[jevansaks]

There's definitely an artifact saving step in the pipeline, but it's conditioned to not run for pull requests.

But if you manually queue the pipeline and point it at your source branch then it won't know it's a pull request.

[miniksa]

As far as I was aware, the APPX directory is assembled by the build step at the top that compiles the solution.

The source linking script runs after the build steps and presumably massages the PDBs that are lying around loose, not the ones already packed into an APPX.

Then later, that publish artifacts step picks up only the APPX stuff. Not all the loose PDBs that have been massaged by the sourcelink script.

Am I incorrect?

This is why I thought I needed a new step that collected more of the artifacts for publishing so I could test it. I am also relatively certain that the release builds will collect and submit more of the PDB data to the right place, but I don't want to trigger a release build for testing given it has signing steps in it.

[miniksa]

OK, I cannot find a symbol publishing step in our pipelines. So unless it's currently some sort of magic that happens with the store submission back-end when the .appxsym goes up, we don't have it.

I found over in MUX that there's this: https://github.com/microsoft/microsoft-ui-xaml/blob/master/tools/PublishSymbols/PublishSymbols.ps1 which appears to submit them directly to the Microsoft Symbol Server in a custom script instead of using a task. Not sure why the task isn't used.

[jevansaks]

Then later, that publish artifacts step picks up only the APPX stuff. Not all the loose PDBs that have been massaged by the sourcelink script.

In that case you might want to add this script as a custom build step. In our case it's a separate job because it doesn't have to be done that early.

OK, I cannot find a symbol publishing step in our pipelines. So unless it's currently some sort of magic that happens with the store submission back-end when the .appxsym goes up, we don't have it.

It probably is. It might still be worth publishing symbols from at least release builds. We publish to symweb internally because it's the only way I was able to find to get internal watson to find them. But externally the publish symbols task should be enough. Honestly it should be good enough for watson too but symweb was what we were using when we were internal and I haven't revisited it.

[miniksa]

I ran the release build internally (which apparently doesn't match the external YAML definition yet...) and this worked in Visual Studio but not in WinDBG.

Which then was obvious because the internal definition didn't have the Powershell script running yet. So I'm running it internally one more time and if it's good, then we're good to go.

[miniksa]

OK. It works for WinDBG now too. This is good to go.