Scott Jones

The sequence is backwards - WinUI-Samples should be made public first, and only then used as a submodule in another public repo

Thanks Rafael - sounds like we might be holding it wrong with native libs, although the default .NET SDK build behavior should warn that a native dll is being omitted....

This is fixed in Windows App SDK 1.2 Preview 2. For a workaround, see: https://github.com/microsoft/WindowsAppSDK/issues/1856#issuecomment-1262705228

This issue is fixed in the next release of Windows App SDK, 1.2 Preview 1. Internal: https://dev.azure.com/microsoft/WinUI/_git/microsoft-ui-xaml-lift/pullrequest/7348995?_a=files

It's generally best to leave closing to the opener, after verifying.

Closing, as this issue was fixed in cppwinrt: https://github.com/microsoft/cppwinrt/pull/1004/files

@triplef This might be helpful: https://github.com/microsoft/cppwinrt/tree/master/nuget

@chausner, yes, I've discovered this works for both single-project and wapproj-based solutions, and keeps the .NET Object Allocations tool enabled (which is what I was after): Choose Target: Installed App…...

I've opened a new issue with Visual Studio, as the Centennial detection logic appears not to be covering Windows App SDK apps: https://developercommunity.visualstudio.com/t/performance-profiler-fails-with-windows-app-sdk-ap/1663956?from=email

VS just reported a fix for this: [Performance Profiler fails with Windows App SDK app: "Failed to disable Process Lifecycle Management (PLM)" - Visual Studio Feedback](https://developercommunity.visualstudio.com/t/performance-profiler-fails-with-windows-app-sdk-ap/1663956?from=email) This may be available...