Visual Studio Feedback System on 7/8/2019, 10:37 PM (20 days ago):
We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.
Matt Grove on 7/9/2019, 02:45 PM (19 days ago):
I did a bit of debugging and this appears to be related to XAML type generation. Here's the callstack I get:
Also, both of the 'GetList' methods in Foo must be static. If one or both methods are instance, the error doesn't occur.
Matt Grove on 7/9/2019, 03:29 PM (19 days ago): (private comment)
Sorry. More research results.
What seems to be happening is that DirectUISchemaContext.GetXamlType(Type) is trying to add the generic type parameter T from one of the Foo.GetList overloads to its type tables. I can see that type parameter present in the masterTypeTable field. It then tries to add the XamlType to its other dictionary (masterTypeTableByFullName) -- but the key it uses is the generic type parameter's FullName, which is null for a generic type parameter. Hence, the exception.
You can see that masterTypeTable has 17 entries, while masterTypeTableByFullName has only 16 entries -- that's because it threw an exception trying to add that last "type" (generic type parameter T) to masterTypeTableByFullName.
I don't know why both overloaded methods must be present and static, but it seems as though this might be enough to get a good start on this.
These are the original issue solutions:
(no solutions)
If you remove the 'Foos' property, or remove either overload in class 'Foo', the error disappears.
Odd, eh?
This is VS2019 16.1.5. I didn't have this issue before now, though I admit I've upgraded VS2019 a few times since the last time I built that project.
This issue has been moved from https://developercommunity.visualstudio.com/content/problem/637611/xaml-compiler-error-wmc9999-related-to-c-code-not.html VSTS ticketId: 943916 These are the original issue comments:
Visual Studio Feedback System on 7/8/2019, 10:37 PM (20 days ago):
Matt Grove on 7/9/2019, 02:45 PM (19 days ago):
We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.
I did a bit of debugging and this appears to be related to XAML type generation. Here's the callstack I get:
mscorlib.dll!System.ThrowHelper.ThrowArgumentNullException(System.ExceptionArgument argument)
mscorlib.dll!System.Collections.Generic.Dictionary<string, System.Xaml.XamlType>.Insert(string key, System.Xaml.XamlType value, bool add)
Microsoft.Windows.UI.Xaml.Build.Tasks.dll!Microsoft.Xaml.DirectUI.DirectUISchemaContext.GetXamlType(System.Type type)
System.Xaml.dll!System.Xaml.XamlType.GetTypeArguments(System.Type type, System.Xaml.XamlSchemaContext schemaContext)
System.Xaml.dll!System.Xaml.XamlType.XamlType(string alias, System.Type underlyingType, System.Xaml.XamlSchemaContext schemaContext, System.Xaml.Schema.XamlTypeInvoker invoker, System.Xaml.Schema.TypeReflector reflector)
Microsoft.Windows.UI.Xaml.Build.Tasks.dll!Microsoft.Xaml.DirectUI.DirectUISchemaContext.GetXamlType(System.Type type)
Matt Grove on 7/9/2019, 03:07 PM (19 days ago):
Also, both of the 'GetList' methods in Foo must be static. If one or both methods are instance, the error doesn't occur.
Matt Grove on 7/9/2019, 03:29 PM (19 days ago): (private comment)
Sorry. More research results.
What seems to be happening is that DirectUISchemaContext.GetXamlType(Type) is trying to add the generic type parameter T from one of the Foo.GetList overloads to its type tables. I can see that type parameter present in the masterTypeTable field. It then tries to add the XamlType to its other dictionary (masterTypeTableByFullName) -- but the key it uses is the generic type parameter's FullName, which is null for a generic type parameter. Hence, the exception.
You can see that masterTypeTable has 17 entries, while masterTypeTableByFullName has only 16 entries -- that's because it threw an exception trying to add that last "type" (generic type parameter T) to masterTypeTableByFullName.
I don't know why both overloaded methods must be present and static, but it seems as though this might be enough to get a good start on this.
These are the original issue solutions: (no solutions)