[GeneratedComInterface] Produces SYSLIB1051 in WinUI3 project even though I have DisableRuntimeMarshalling=true

[jevansaks]

Description

In a WinUI3 project I get errors telling me that I need to set DisableRuntimeMarshalling but I have done so. And if I add [assembly:DisableRuntimeMarshalling] then I get a "duplicate attribute defined" later during compile.

Reproduction Steps

I pushed a repro up here: https://github.com/jevansaks/WinUI3ComGeneratorsRepro

But the repro is:

1. File => New Project "WinUI Blank App (Packaged)"
2. Add this to the csproj:

    <AllowUnsafeBlocks>true</AllowUnsafeBlocks>
    <PublishAot>true</PublishAot>
    <DisableRuntimeMarshalling>true</DisableRuntimeMarshalling>

3. Add this to app.xaml.cs:

    [Guid("00000000-0000-0000-0000-000000000003"), InterfaceType(ComInterfaceType.InterfaceIsIUnknown), GeneratedComInterface]
    public partial interface IRepro
    {
        void Test(global::System.Drawing.Point pt);
    }

Expected behavior

Compiles.

Actual behavior

Gives a confusing error:

App.xaml.cs(33,48,33,50): error SYSLIB1051: Runtime marshalling must be disabled in this project by applying the 'System.Runtime.CompilerServices.DisableRuntimeMarshallingAttribute' to the assembly to enable marshalling this type. The generated source will not handle marshalling of parameter 'pt'. (https://learn.microsoft.com/dotnet/fundamentals/syslib-diagnostics/syslib1051)

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

This seems to be because XamlPreCompile doesn't get all the things passed to it that CoreCompile does. Again. Why does this target exist? :)

[dotnet-policy-service[bot]]

Tagging subscribers to this area: @dotnet/interop-contrib See info in area-owners.md if you want to be subscribed.

[jkoritzinsky]

This is an issue in the XAML integration targets. They aren't pulling in the SDK-generated AssemblyInfo file. Moving to the sdk.

[Sergio0694]

Possibly related to other various bugs around this target we've found before:

• #43908
• #30708
• #17890

@jlaanstra you helped investigate this last time, may I nerd snipe you again into helping to take a look at this? 😄

[jlaanstra]

https://github.com/dotnet/sdk/blob/3133f8d9ca86202701e8e256af61c08d90903212/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.GenerateAssemblyInfo.targets#L58 No dependency on XamlPreCompile.

[jlaanstra]

Probably want to do the same as in the first issue referenced by @Sergio0694. Switch to AfterTargets="PrepareForBuild" as recommended by @rainersigwald

[marcpopMSFT]

Triage: @jlaanstra @Sergio0694 were ya'll going to put up a PR per the suggestion above or looking for someone else to?

[jevansaks]

@marcpopMSFT The fix seems "simple" and I'd be ok contributing it... but re-ordering targets could have some fall-out. Is there existing test collateral that would help validate these that I could add this new regression test to and also make sure I don't break other cases and cause a whack-a-mole kinda thing?

[marcpopMSFT]

That is super tricky to test and no testing is really sufficient here. @dsplaisted any suggestions on how to be safe about moving around targets?

[dsplaisted]

If Rainer recommends switching it to PrepareForBuild and it passes our tests, that's probably the best we can do. It would be safer to put a change like that in .NET 11 so that we have a long preview period to hopefully catch any regressions.

It seems like it would be safer to add XamlPreCompile to the BeforeTargets for GenerateAssemblyInfo.

[Sergio0694]

If we're touching XamlPreCompile again, could we also squeeze in a fix for https://task.ms/57204991 while at it? 😅

[jevansaks]

Here's how I worked around this issue in our repo:

    <CoreCompileDependsOn>$(CoreCompileDependsOn);GenerateAssemblyInfo</CoreCompileDependsOn>

And that worked, so if you feel better about that kind of change, that's fine with me. But I agree with @Sergio0694 that we should also fix the EmitCompilerGeneratedFiles issue too. So maybe you can take this one, @dsplaisted ?

[dsplaisted]

If we're touching XamlPreCompile again, could we also squeeze in a fix for https://task.ms/57204991 while at it? 😅

That one should be fixed by https://github.com/dotnet/msbuild/pull/12885