[Generator] Allow to have a way to attach to the generator. by mandel-macaque · Pull Request #19565 · dotnet/macios (original) (raw)

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Conversation28 Commits5 Checks0 Files changed

Conversation

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters

[ Show hidden characters]({{ revealButtonHref }})

mandel-macaque

As soon as we moved to have a build of the generator that used dotnet we opened the door to a number of developer life improvements. The very first one of those is the poissibility to attach the dotnet debugger to the bgen process and that way be able to debug.

In order to do that, this PR has changed two small things:

  1. Added code in the main method of the generator that will block the tool until a debugger is attached.
  2. Changed the csproj to add the previously mentioned code only when the enviroment variable XAMMACIOS_DEBUGGER is set. This way the code does not reach our customers.

A README has been added explaining how to debug the processes via Visual Studio. Any other IDE that support the dotnet debugger can be used this way.

Screenshot 2023-12-03 at 19 10 18

@vs-mobiletools-engineering-service2

This comment has been minimized.

@vs-mobiletools-engineering-service2

This comment has been minimized.

@vs-mobiletools-engineering-service2

This comment has been minimized.

@vs-mobiletools-engineering-service2

This comment has been minimized.

@vs-mobiletools-engineering-service2

This comment has been minimized.

mcumming

@vs-mobiletools-engineering-service2

This comment has been minimized.

rolfbjarne

## Debugging
One of the main problems when adding changes to the generator was that before the generator was moved to dotnet, we could not attach the dotnet debugger to it.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could however start debugging in VSMac just fine though. That should still work if you have the correct version of .NET installed I believe.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, you can, but it is a lot more work. You have to install the right version, generate the rsp files, and then call from vsmac.

I initially started by doing it like that and it got very annoying.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. You can either install the right .NET version (make print-dotnet-pkg-urls -C builds will give you the url) or delete global.json (I tend to go for the latter, works well enough for small fixes).
  2. That's already done for legacy targets:

Screenshot 2023-12-04 at 17 27 37

Should be easy enough to add the .NET ones in the csproj (and that would be committed, so no need to do it again).

@vs-mobiletools-engineering-service2

This comment has been minimized.

@vs-mobiletools-engineering-service2

This comment has been minimized.

@vs-mobiletools-engineering-service2

This comment has been minimized.

@vs-mobiletools-engineering-service2

This comment has been minimized.

@vs-mobiletools-engineering-service2

This comment has been minimized.

@vs-mobiletools-engineering-service2

This comment has been minimized.

stephen-hawley

// block the generator until a debugger has attached to it
// our customers won't find any use for this.
var process = Process.GetCurrentProcess ();
Console.WriteLine ($"Waiting for debugger to attach: ({ process.Id}) {process.ProcessName}");

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: ({ process.Id}) -> ({process.Id})

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm funny that the autformat did not pick that up :/

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because it's behind an #if ... that evaluates to false.

the Attach to Process option. In the dialog that will appear, you will need to select the dotnet process that is running the generator. In this case, the process
is the one with the PID 55644. Once you have selected the process, you can click on the Attach button.
Because the generator is called several times, one per platform, you can attach to the different processes in case the issue you are trying to debug

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should the "Waiting for debugger to attach" message include the args so that it would be easier to differentiate instances?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good idea, that way it is easier to debug. A simple string.join of the arg should be better than nothing.

@mandel-macaque

As soon as we moved to have a build of the generator that used dotnet we opened the door to a number of developer life improvements. The very first one of those is the poissibility to attach the dotnet debugger to the bgen process and that way be able to debug.

In order to do that, this PR has changed two small things:

  1. Added code in the main method of the generator that will block the tool until a debugger is attached.
  2. Changed the csproj to add the previously mentioned code only when the enviroment variable XAMMACIOS_DEBUGGER is set. This way the code does not reach our customers.

A README has been added explaining how to debug the processes via Visual Studio.

@mandel-macaque @rolfbjarne

Co-authored-by: Rolf Bjarne Kvinge rolf@xamarin.com

@mandel-macaque @rolfbjarne

Co-authored-by: Rolf Bjarne Kvinge rolf@xamarin.com

@mandel-macaque

This broke the support.

This reverts commit a25def8.

@mandel-macaque

@vs-mobiletools-engineering-service2

@vs-mobiletools-engineering-service2

@vs-mobiletools-engineering-service2

💻 [CI Build] Tests on macOS M1 - Mac Big Sur (11.5) passed 💻

All tests on macOS M1 - Mac Big Sur (11.5) passed.

Pipeline on Agent
Hash: [PR build]

@vs-mobiletools-engineering-service2

💻 [CI Build] Tests on macOS M1 - Mac Ventura (13.0) passed 💻

All tests on macOS M1 - Mac Ventura (13.0) passed.

Pipeline on Agent
Hash: [PR build]

@vs-mobiletools-engineering-service2

✅ API diff for current PR / commit

Legacy Xamarin (No breaking changes)

✅ API diff vs stable

Legacy Xamarin (No breaking changes)

ℹ️ Generator diff

Generator Diff: vsdrops (html) vsdrops (raw diff) gist (raw diff) - Please review changes)

Pipeline on Agent
Hash: 4c5b835b49cbbcb8a02d2ac99f09bdad64d4528a [PR build]

@vs-mobiletools-engineering-service2