Any chance of a short term fix for casts not being picked up with AOT?

[benstevens48]

Description

I have just migrated a UWP app to WindowsAppSDK + CSWinRT + NativeAOT. However, it is a large app, and I keep on finding bugs which are present in the published version but not when debugging, primarily I think due to types not being picked up by the source generator (not sure exactly how it works). Often this is when the type is used via a cast - mostly I am using the C# as operator.

Steps To Reproduce

To give an example, I just realised that my custom media controls were not fading in/out in the published version of my app. Then I ran it in debug to see what this issue was and it worked fine! After being very confused for some time, based on some previous experiences I replaced this line

visibleStateGroup = GetTemplateChild("ControlPanelVisibilityStates") as VisualStateGroup;

with this line

visibleStateGroup = GetTemplateChild("ControlPanelVisibilityStates").As<VisualStateGroup>();

and it started working again. But it was very difficult to debug, especially as I had to publish the app every time to test a possible fix. Plus I have hundreds of places like this where I am using the C# as operator and it makes my code seem very fragile. This is an example of not such a bag bug but I have also had crashing bugs as well.

I realise this will probably be fixed by v3 and you are doing a lot of good work on it but it seems like it may still be some time before that is released(?).

Expected Behavior

Types picked up by source generator as needed.

Version Info

2.3 prerelease

Additional Context

No response

[manodasanW]

This looks like the issue that we improved in the CsWinRT 2.3.1 release and is going to be addressed in CsWinRT 3.0 using the new .NET TypeMap functionality. Can you try updating to CsWinRT 2.3.1 and set CsWinRTAotWarningLevel property to 3?

That should trigger our analyzer to detect the above casting scenarios that are getting trimmed and it would give a diagnostic fix which applies an attribute scoped to where it is used to prevent it from getting trimmed.

From the release notes:

Added a CsWinRTAotWarningLevel = 3 for more extensive AOT warnings with respect to casting scenarios. These warnings can be noisy, so they are not enabled by default.

[benstevens48]

Thanks, I missed the bit about setting CsWinRTAotWarningLevel to 3. Unfortunately I now have 1400 cast warnings and I don't think it's practical for me to try to fix them all, especially if the fix is not needed in CSWinRT 3 (plus I also get an additional 250 warnings about classes implementing IDisposable not being partial which I can ignore since they are not used across the ABI).

Isn't it possible for the source generator to add all the types it finds in casts as dummy fields of a big class or something, which has the necessary attributes on to stop it from being trimmed? Or maybe this is the TypeMap concept? But would it be very difficult just to add a quick fix version to the 2.3 branch? If the class needs to already exist due to the source generator not creating new classes then I don't mind adding an empty class marked with an attribute to my project somewhere for this purpose.

[benstevens48]

Actually, it seems like the DynamicWindowsRuntimeCastAttribute source generator effectively already does something like this but it requires this attribute to be added for each type. The analyser effectively identifies all the types where it is required. So can we get a setting which combines the two i.e. takes the output types from the analyser and uses this in the DynamicWindowsRuntimeCastAttribute source generator without needing the DynamicWindowsRuntimeCast attribute? For the time being I have processed the output of the analyser using Regex and Excel to get the class names then created an empty method annotated with [DynamicDependency(DynamicallyAccessedMemberTypes.NonPublicConstructors | DynamicallyAccessedMemberTypes.PublicFields, typeof(TheType))] for each type, called somewhere once, which is effectively what the DynamicWindowsRuntimeCastAttribute source generator does.

[Sergio0694]

"I don't think it's practical for me to try to fix them all"

You don't need to do it manually. We shipped a code fixer for this, just click on the lightbulb in VS > Fix all in solution 🙂

"So can we get a setting which combines the two i.e. takes the output types from the analyser and uses this in the DynamicWindowsRuntimeCastAttribute source generator without needing the DynamicWindowsRuntimeCast attribute?"

No, unfortunately that's not possible, for performance reasons. The analyzer is fairly expensive, as it has to do a bunch of semantic analysis on a whole lot of syntax nodes, to try to identify all cases. This is mostly fine because analyzers run out-of-process and asynchronously, and don't impact the IDE. Generators on the other hand are directly part of the compiler loop and have much tighter performance requirements. Triggering off of attributes is extremely efficient, that's why we went that route. We can't have the generator do that work automatically, it would be way too slow and it would end up negatively impacting the IDE experience (e.g. IntelliSense).

[benstevens48]

Ok, yes, I understand the performance reasons - to be honest intellisense is already almost unusable in my project - hoping CsWinRT 3 will improve that! It could maybe be done as a build step though - I mean it only really needs to run on publish trimmed/AOT at some point before trimming. Not sure if this is possible/easy. Come to think of it, the vtable generation stuff isn't needed at design-time either, so maybe that could be a build step or something as well to speed up intellisense. If not possible then maybe C# needs more options on when generators are run or more build hooks!

[Sergio0694]

Yeah, unfortunately there's no way to make a generator only run at build. The best you can do is to make it only run when saving a file, which is already the default now in recent Visual Studio versions. We have no plans of doing further investments here for 2.x, and we won't be migrating this to a build task, as that would be a pretty substantial change 😅

[manodasanW]

I just want to add that the IntelliSense performance is being addressed for CsWinRT 3.0 by making most of this a build task.