Bug description
When a class or generic class marked [MessagePackObject(AllowPrivate = true)] is declared in one project and has at least one private field/property tagged [Key(...)], and a different, referencing project has a class (also [MessagePackObject(AllowPrivate = true)]) with an
actually-serialized ([Key]-tagged, not [IgnoreMember]) property of that closed generic type - both Visual Studio and VS Code (C# Dev Kit) flag the generic type with a false-positive "ambiguous type" CS0433 or CS0436 error. The methods/properties of the class or generic are flagged with CS1061 error. The error prevents using F12 or Go to definition in VS Code and Visual Studio.
This issue is dependent on the scope of the member, so public or internal scope does not lead to this false flagging. The scope should be private and the member should not be ignored for serialization using [IgnoreMember].
Repro steps
I have attached a skeletal solution with projects that can be inspected with VS Code and Visual Studio (IntelliSenseError.zip). It was created using a Coding Assistant, but I have verified the contents manually. Open this solution in the IDE and inspect Lib.Consumer/BoxUsage.cs - the BoxDouble property's type (GenericBox<double>) is flagged. Also, Lib.Consumer/BoxUsage.cs - the BoxObject property's type (Box) is flagged. If it isn't flagged immediately, wait for sometime or build the solution.
In the attached solution, the false flagging is triggered when (removing either one stops the bug from reproducing):
- GenericBox<T> (Lib.Std/GenericBox.cs) - a generic type marked
[MessagePackObject(AllowPrivate = true)], with at least one private member tagged
[Key(...)] (here, _counter). A type with only public [Key]-tagged members does not
reproduce the bug.
- BoxUsage (Lib.Consumer/BoxUsage.cs) - a class in a project that merely references
Lib.Std (via ProjectReference), itself marked [MessagePackObject(AllowPrivate = true)],
with a property of the closed generic type (GenericBox<double>) that is actually
[Key]-tagged (not [IgnoreMember]).
The same is true for Box.
Expected behavior
IntelliSense should not raise false error flags.
Actual behavior
IntelliSense in the IDE raises a false error which prevents navigation to definitions.
- Version used:
-
- MessagePack-CSharp: 3.1.8 (also confirmed on 3.1.7)
- Runtime: net8.0
- Reproduced in both Visual Studio (2022 and 2026) and VS Code 1.131.0 (C# Dev Kit extension)
Bug description
When a class or generic class marked [MessagePackObject(AllowPrivate = true)] is declared in one project and has at least one private field/property tagged [Key(...)], and a different, referencing project has a class (also [MessagePackObject(AllowPrivate = true)]) with an
actually-serialized ([Key]-tagged, not [IgnoreMember]) property of that closed generic type - both Visual Studio and VS Code (C# Dev Kit) flag the generic type with a false-positive "ambiguous type" CS0433 or CS0436 error. The methods/properties of the class or generic are flagged with CS1061 error. The error prevents using F12 or Go to definition in VS Code and Visual Studio.
This issue is dependent on the scope of the member, so public or internal scope does not lead to this false flagging. The scope should be private and the member should not be ignored for serialization using [IgnoreMember].
Repro steps
I have attached a skeletal solution with projects that can be inspected with VS Code and Visual Studio (IntelliSenseError.zip). It was created using a Coding Assistant, but I have verified the contents manually. Open this solution in the IDE and inspect Lib.Consumer/BoxUsage.cs - the BoxDouble property's type (GenericBox<double>) is flagged. Also, Lib.Consumer/BoxUsage.cs - the BoxObject property's type (Box) is flagged. If it isn't flagged immediately, wait for sometime or build the solution.
In the attached solution, the false flagging is triggered when (removing either one stops the bug from reproducing):
[MessagePackObject(AllowPrivate = true)], with at least one private member tagged
[Key(...)] (here, _counter). A type with only public [Key]-tagged members does not
reproduce the bug.
Lib.Std (via ProjectReference), itself marked [MessagePackObject(AllowPrivate = true)],
with a property of the closed generic type (GenericBox<double>) that is actually
[Key]-tagged (not [IgnoreMember]).
The same is true for Box.
Expected behavior
IntelliSense should not raise false error flags.
Actual behavior
IntelliSense in the IDE raises a false error which prevents navigation to definitions.