Open christcottrell opened 2 years ago
This is from 2 years ago? Really? And there is still no proper documentation on it. So when I'm rating my experience with Microsoft to be very poor, THIS is why. You build bad or incomplete products and don't document anything. Most have wasted time building and setting up something that just doesn't work or a simple set of documents explaining the best way would help. I can go on and on with examples, but THIS is why you are laughed at as a trusted organization. You also do too much leading the things you do to be not all put together.
https://github.com/MicrosoftDocs/azure-devops-docs/issues/3709
Could you be more specific on what doesn't work? Is the debugger not able to fetch the source files? What errors do you see?
The debugger does not attach to the source files that are included in the package. You can see that everything appears to be setup correctly in the package. It has a link to the commit with links in the pdb. And the source is within a private repo within an organization in Github packages. I would love it if the product direction for Github provided a symbol server within our organization because it is cleaner, but that isn't the direction either and there's still the issue on how that authentication is happening.
This is likely another question and I don't want to distract from the original question, but if a package is consuming another package that is also tied to Source Link. So we have package A being used by a consumer. Package A uses package B. When debugging from the consumer and we're able to get into package A, does it allow that debugging to flow into package B? Thanks!
@chuckries
does it allow that debugging to flow into package B? T
Yes, it should work as long as each of the packages is built with Source Link. Each assembly (.dll/.exe) has its own Source Link record in its PDB and is handled separately. Their sources can be in different repos of different git hosts.
@christcottrell a few questions:
If you are already using Embedded PDB's, you may also be able to leverage Embedded Source as a workaround to Source Link by adding this to your project:
<PropertyGroup>
<EmbedAllSources>true</EmbedAllSources>
</PropertyGroup>
@chuckries Based on the screenshot above I think "embedded" here means Portable PDB in nuget package, not embedded in the dll.
Are the Embedded PDBs being loaded? If you view CMP.Validation.Service.dll under Debug > Windows > Modules, does it say that the symbol are loaded?
Do you have Just My Code enabled (check via Debug > Options > General). If Just My Code is enabled, the debugger is likely not trying to stop in the dll, and Source Link Request is never being made. Settings are in place. for other sources like it will go into List. Enable Just my code is unchecked, enable source server support is checked, and enable source link support is also checked. (using Visual Studio 2022)
Is the source hosted on a private repo on GitHub.com? Or is it hosted on a GitHub Enterprise instance owned by Deloitte? VS does not fully support Source Link Authentication to GitHub Enterprise instances.
Also, it is going into the code for List under System.Collections.Generic as I step through it when it executes this line.. And I did see the notice about SourceLink when running.
lazyLoader.ValidationRulesData = new List
@tmat thanks, I assumed Embedded PDB.
@christcottrell I think the issue then is that the debugger is not finding the PDB's from within the nuget package. Try this:
Ensure that the PDB is loaded via the modules window. If the PDB is not loaded, Source Link cannot work.
Awesome.. That last part is what I needed. It does find the source there. Thank you!
Thanks @chuckries for the solution here, I ran into the same problem and manually locating the .pdb file worked.
Now I'm wondering if there's a way to make this work automatically? Is there a good way to make this seamless for private packages?
Switching the project settings so that the symbols are embedded into the .dll rather than placed in a separate .pdb seems to solve the problem and is an acceptable tradeoff for our use case so I think that's what we'll do for internal packages going forward.
Hi @mattnewport, How can I embed my pdb into dlls?
@emrecoskun705, set the MSBuild property <DebugType>embedded</DebugType>
as documented at https://learn.microsoft.com/dotnet/csharp/language-reference/compiler-options/code-generation#debugtype.
Before I hear back that they should be in snupkg packages, I need to hear back on whether they are supported with the pdb files embedded. This is one of our simplest use cases we have here at Deloitte and it's not working.
The code is being pushed to a Github within the Deloitte organization so the source code and the symbols are not public (hence not being able to use existing symbol servers that are public. From the nuget package explorer, everything looks ok.
The only thing I can think of is that the authentication to the Github repo is not in place. What I do have in my solution is a nuget.config that registers the nuget source and I am able to pull from our nuget repo from package manager without issues. But does the pulling of the source code use those nuget.config source settings? Has this been tested against non public code repos?
Thanks!