Vogen: DebuggerDisplayAttribute breaks in Rider

Describe the bug

When viewing the generated types in the debug window you get different messages depending on the type:

Int:

Underlying type: global::System.Int32, Value = Exception of type 'System.Security.VerificationException' was thrown: objRef is not object value

String:

Underlying type: System.String, Value = Failed to read field: Value does not fall within the expected range. The error code is E_INVALIDARG, orCOR_E_ARGUMENT, orWIN32_ERROR_INVALID_PARAMETER, or0x80070057.

What they seem to have in common is that the debugger breaks on stringifying the _value parameter.

It then doesn’t even allow you to expand the objects as it doesn’t get to the point of instantiating the proxy object.

If you remove the _value from

[global::System.Diagnostics.DebuggerDisplayAttribute("Underlying type: global::System.Int32, Value = { _value }")]

then you can expand the debug window. Unfortunately this then causes a stack overflow, because the DebugProxy has a reference to the ValueObject and it tries to recursively instantiate itself.

The solution is to take the important elements from the ValueObject in the DebugProxy and not keep a reference to the ValueObject in the DebugProxy.

I have no clue whether this is something that is contained to Rider’s debugger or if this happens on other C# debuggers as well.

Steps to reproduce

  1. Create a class
[ValueObject(typeof(string))]
public partial class TestThing
{
    
}
  1. Create an instance
var test = TestThing.From("Test");
  1. Do something with it
Console.WriteLine(test.Value);
  1. Debug the line where you do something with it and look at the Variables section.

Expected behaviour

I see the Debug Proxy without any issues and don’t get exceptions.

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 15 (11 by maintainers)

Most upvoted comments

I’m wondering if I should close this issue. Does the fact that having the debug attributes causes you to not be able to use Vogen? If so, I’ll add something so that the can be turned off in Rider while its being fixed.

It should be fine to close it, I opened the issue because I thought it was a Vogen issue, but since its a rider issue we can close it now.

@SteveDunn Will try to create one. The project where I’m currently using it is quite big and of course I can’t share it. @Blackclaws Thanks, will try to see what happens. Usually on load there are no errors and everything is fine. Things start to break apart when I edit code that has references to VOs. Sometimes even a “move this class to another file” breaks everything.

@SteveDunn I don’t think it is related to this attribute per-se. I asked @Blackclaws as it seems he’s using Rider with Vogen.

I’m not sure what Rider does with source-generators, but before Vogen I used StronglyTypedId and had similar issues (but solved by simply closing/reopening the solution).

If I have to guess (based on my null knowledge of source generators), this seems to be related to how you hook into the pipeline.

So definitely a Rider thing:

https://youtrack.jetbrains.com/issue/RIDER-79915 https://youtrack.jetbrains.com/issue/RIDER-79916

Probably not something you have to worry about as it should work. Not sure when it will get fixed however …

Referencing properties instead of fields work fine by the way. So a solution for people running into this issue would be to change the code generation for _value to emit a Property instead.