CsWinRT/WinUI Authoring Support #1111
Conversation
|
Should review/revise the |
|
thanks @j0shuams !
Is there an expectation that there are no ABI changes between different versions of this binary? IOW is it always safe to swap one WinRT.Runtime for another? |
* edits & formatting
|
|
||
| **Note:** With C#/WinRT 1.3.5 or later, project references to a C#/WinRT component require .NET 6. | ||
| ```xml | ||
| <?xml version="1.0" encoding="utf-8"?> |
There was a problem hiding this comment.
does the manifest not need a <supportedOS> entry for unpackaged?
There was a problem hiding this comment.
I'm not aware of this, perhaps thats why the unpackged scenario doesn't work? When I made the unpackaged scenario I followed the docs here.
There was a problem hiding this comment.
I think the docs are missing some scenarios. I had filed this: MicrosoftDocs/windows-dev-docs#3691
Also this MicrosoftDocs/windows-dev-docs#3695
@JesseCol fyi
j0shuams
force-pushed
the
jlarkin/authoring
branch
from
af8cd6b to
02d8398
Compare
This PR includes changes to our authoring targets that fix gaps in our WinUI support. The issue we were seeing was with native apps referencing cswinrt components; the managed projection binaries the component depended on (e.g. Microsoft.WinUI.dll) were not being copied to the output folder of the native app. We leverage the item group
AllItemsFullPathWithTargetPathto place the binaries correctly. This also removes some of the logic we were using to place CsWinRT binaries like WinRT.Runtime, as the new target will handle that for us.Because we ship a WinRT.Runtime.dll and the .NET SDK also has its own version, we explicitly pick the dll with the latest version for copying.
This has been tested using Windows App SDK 1.1 (experimental build) and VS2022.