Fix WACK certification error for transitive WinUI references

[llongley]

WACK expects to be able to find WinMDs for type resolution purposes in the root of the AppX, but when WinUI 2 is referenced via framework package, the WinMD is instead placed in a WinMetadata subdirectory. As a result, applications that reference nuget packages with references to WinUI 2, WACK certification fails. I'm not sure whether placing the WinMD file in that directory is still needed, so to work around this issue in the safest manner, this adds an additional build target that places the WinMD where WACK certification needs it to be.

An example of an issue that will be resolved by this fix: CommunityToolkit/Lottie-Windows#214

[StephenLPeters]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[llongley]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[kmahone]

Our Release Pipeline runs WACK tests. Could we add a test that covers this scenario? We already have another test app "AppThatUsesMUXIndirectly" that is covering the scenario that you are doing the fix for. So it might just be a case of including that app in the WACK test?

[kmahone]

🕐

[llongley]

Our Release Pipeline runs WACK tests. Could we add a test that covers this scenario? We already have another test app "AppThatUsesMUXIndirectly" that is covering the scenario that you are doing the fix for. So it might just be a case of including that app in the WACK test?

I don't think that would work - to repro the issue, you need a NuGet package with a WinMD that includes a type that references a WinUI 2 type. I can see about creating an app that repros the issue, though.

[llongley]

OK, I've added a test case that exercises this scenario - we now have a new project that produces a local NuGet package that contains a type that implements an interface from the WinUI 2 NuGet package, which does fail the WACK certification test without this change.

[llongley]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[llongley]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[llongley]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[StephenLPeters]

@llongley this build failure has the same message that my animated icon checkin had a while back. That one was caused by a complier bug that was resolved in RS3. We worked around that issue by disabling reflection on the offending method which you can see I did in this commit 32c5d58

Hope this helps

[kmahone]

[StephenLPeters]

@llongley I might suggest merging in master so we can try rerunning this with some of the recent changes

[llongley]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[llongley]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[llongley]

Don't merge this just yet - I'm still seeing a build issue when running the release pipeline that I'm investigating.

[llongley]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[llongley]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[llongley]

OK, I've gotten everything passing in a release run that tests both the nupkg and the framework package - all looks good, this can be checked in once the PR run succeeds.

[ghost]

Apologies, while this PR appears ready to be merged, I've been configured to only merge when all checks have explicitly passed. The following integrations have not reported any progress on their checks and are blocking auto-merge:

1. GitHub Pages

These integrations are possibly never going to report a check, and unblocking auto-merge likely requires a human being to update my configuration to exempt these integrations from requiring a passing check.

Give feedback on this

From the bot dev team

We've tried to tune the bot such that it posts a comment like this only when auto-merge is blocked for exceptional, non-intuitive reasons. When the bot's auto-merge capability is properly configured, auto-merge should operate as you would intuitively expect and you should not see any spurious comments.

Please reach out to us at [email protected] to provide feedback if you believe you're seeing this comment appear spuriously. Please note that we usually are unable to update your bot configuration on your team's behalf, but we're happy to help you identify your bot admin.