debug / trace find ancestor of type

[mjkkirschner]

Hello,

please redirect me if this is the not the correct location for this issue.

I would somehow like to debug all FindAncestorOfType calls but I cannot seem to find objectref file when decompiling symbols in visual studio.

If that is not possible I would like to enable the tracing args for this method - is that possible?

wpf/src/Microsoft.DotNet.Wpf/src/PresentationFramework/MS/Internal/Data/ObjectRef.cs

Line 393 in b08d70d

d = FindAncestorOfType(_relativeSource.AncestorType, _relativeSource.AncestorLevel, d, args.IsTracing);

[lindexi]

@mjkkirschner You can download the symbols and do not decompiling symbols in visual studio.

And you can build the wpf repo to get the debug dll and pdb file. And you can replace it with your build version.

[siagupta0202]

@mjkkirschner does the solution provided by @lindexi answer your question?

[miloush]

You could also try adding a breakpoint by function name.

[mjkkirschner]

thanks for the suggestions, I was looking at https://github.com/dotnet/wpf/blob/main/Documentation/developer-guide.md
but I need to debug an existing project that cannot be compiled as standalone/publish.

The guide says to install a test host and to replace the binaries for that test host? Apologies for my ignorance there - is this also the appropriate workflow if I just want to debug?

Looking for a tad more guidance on debugging - I am totally happy to follow @lindexi's suggestion of And you can build the wpf repo to get the debug dll and pdb file. And you can replace it with your build version. Except I am not sure how to replace the binaries for my runtime dependent (not standalone) application.

[h3xds1nz]

@mjkkirschner You can just reference the built debug libraries directly in the project, e.g.

<Reference Include="%HOMEDRIVE%\Users\somebody\wpf\artifacts\bin\PresentationCore\x64\Debug\net10.0\PresentationCore.dll">
  <Private>True</Private>
</Reference>
<Reference Include="%HOMEDRIVE%\Users\somebody\wpf\artifacts\bin\PresentationFramework\x64\Debug\net10.0\PresentationFramework.dll">
  <Private>True</Private>
</Reference>
<Reference Include="%HOMEDRIVE%\Users\somebody\wpf\artifacts\bin\WindowsBase\x64\Debug\net10.0\WindowsBase.dll">
  <Private>True</Private>
</Reference>

Do note that debugging on main branch will require you to install an unsigned SDK build from here:
https://github.com/dotnet/sdk/blob/main/documentation/package-table.md

And in order to debug .NET 10 in VS, you will need the preview for Visual Studio and to set this env variable:
set VSDebugger_ValidateDotnetDebugLibSignatures=0

In case you're not running under a specific host and you wish to replace libraries for framework-dependent apps, you can just do it directly in the runtime folder, e.g. for Windows Desktop libraries:

%HOMEDRIVE%\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App\10.0.0-alpha.1.25066.1

[miloush]

https://github.com/dotnet/wpf/blob/ad9c7ba7de15ebb10025f37e3379b24ed4c6df13/Documentation/developer-guide.md#testing-api-changes worked for me so far

[mjkkirschner]

thank you for all the suggestions, I will close this for now and reopen if I have trouble. Thanks!

[mjkkirschner]

Actually, I've tried a few suggestions here and while they worked with a new wpf app - they did not work with my real application.

After reading about default probing paths and tracing the assembly loads it appears that because my application does not have a deps.json file generated (we have not gotten this working yet, it's a legacy application ported to net8) that TRUSTED_PLATFORM_ASSEMBLIES will not contain my local copies of the wpf binaries.

It seems my only options are to:

1. figure out how to get deps.json generated for our .sln, and have the application continue to function.
2. replace the binaries in the Program Files\dotnet\shared\Microsoft.WindowsDesktop.App folder which seems really brittle, though maybe I could write a script to swap back and forth - or is there one already floating around somewhere?
3. temporarily change the entry point project to be self contained - this actually works great, but I'm not sure I can trust this for profiling/debugging scenarios as it's not how we distribute our application.

Am I missing some other option?