How to use AppWindow in .NET Framework

[Gaoyifei1011]

Describe the bug

How to use AppWindow in .NET Framework
在.NET Framework 中如何使用AppWindow

I tried to use some methods of AppWindow in.NET Framework (winform desktop application), found that some methods can not be called normally, would like to ask if there is any solution?

我在.NET Framework（winform 桌面应用程序）中尝试使用AppWindow的一些方法，发现部分方法不能正常调用，想问一下有没有什么解决方案？

Steps to reproduce the bug

As mentioned above

Expected behavior

当调用AppWindow的一些方法时，不再有红色错误提示
When some methods of the AppWindow are called, there is no longer a red error

Screenshots

As mentioned above

NuGet package version

Windows App SDK 1.4.3: 1.4.231115000

Packaging type

Packaged (MSIX)

Windows version

Windows 11 version 22H2 (22621, 2022 Update)

IDE

Visual Studio 2022

Additional context

No response

[castorix]

I used MoveAndResize without problem, for example at
MainWindow.xaml.cs#L60
or
Form1.cs#L39

[Gaoyifei1011]

I used MoveAndResize without problem, for example at MainWindow.xaml.cs#L60 or Form1.cs#L39

This problem occurs under the.net framework, and.NET core does not experience this problem.
Not only that, if the call InputNonClientPointerSource. SetRegionRects also can appear such problems.

[DarranRowe]

RectInt32 is a struct and not a runtime class. Could that be making a difference here?

--Edit--

No, this isn't it.

CS7063 is more like a reference not found error.

After messing around a little, I don't see this. The application is also a .NET Framework 4.8.1 console application.

To give some information on what I did to get this working.

1. Create the .NET Framework console application.
2. Add a reference to the System.Runtime.WindowsRuntime NuGet package.
3. Add a reference to the System.Runtime.Interop.WindowsRuntime NuGet package.
4. Reference the platform .winmd files, (Or the Windows.winmd union metadata file) for the version of Windows you wish to target. If you are going by the individual .winmd files, remember that you should go by the platform list as well as the desktop extension list.
5. Reference the Windows App SDK .winmd files.
6. Add the individual platforms for the application and remove AnyCPU.

I wrote a little P/Invoke wrapper for MddBootstrapInitialize2 and MddBootstrapShutdown, I also grabbed WindowsAppSDK-Version.cs from the NuGet packaged. Finally, I copied Microsoft.WindowsAppRuntime.Bootstrap.dll to the output directory. My references list was:

The application worked, it had no issues activating AppWindow and the MoveAndResize call worked.

[Gaoyifei1011]

RectInt32 is a struct and not a runtime class. Could that be making a difference here?

--Edit--

No, this isn't it.

CS7063 is more like a reference not found error.

After messing around a little, I don't see this. The application is also a .NET Framework 4.8.1 console application.

To give some information on what I did to get this working.

1. Create the .NET Framework console application.
2. Add a reference to the System.Runtime.WindowsRuntime NuGet package.
3. Add a reference to the System.Runtime.Interop.WindowsRuntime NuGet package.
4. Reference the platform .winmd files, (Or the Windows.winmd union metadata file) for the version of Windows you wish to target. If you are going by the individual .winmd files, remember that you should go by the platform list as well as the desktop extension list.
5. Reference the Windows App SDK .winmd files.
6. Add the individual platforms for the application and remove AnyCPU.

I wrote a little P/Invoke wrapper for MddBootstrapInitialize2 and MddBootstrapShutdown, I also grabbed WindowsAppSDK-Version.cs from the NuGet packaged. Finally, I copied Microsoft.WindowsAppRuntime.Bootstrap.dll to the output directory. My references list was:

The application worked, it had no issues activating AppWindow and the MoveAndResize call worked.

I am also curious how this BUG happened, is this the dependency state of my application

[DarranRowe]

That is interesting. I also saw the same thing using the Microsoft.Windows.SDK.Contracts NuGet package, but referencing Windows.winmd directly works. What's more, ildasm shows that RectInt32 should be in Windows.Foundation.UniversalApiContract.winmd, but that can't satisfy the references and it wants Windows.winmd.
For now, try directly referencing Windows.winmd instead of using the Microsoft.Windows.SDK.Contracts NuGet package. Remember, if you don't want to install the Windows SDK, you can always download and manually extract the Microsoft.Windows.SDK.CPP package. I mention the C++ version specifically because the Microsoft.Windows.SDK.Contracts package only has the facade Windows.winmd, which will not work.

[DarranRowe]

I had been doing a bit more messing around, and this is possible to trigger in tools that just work with the metadata.

The command line given in the first screenshot gives and the path to the files in the primary location where it is looking for metadata. A screenshot of which is given below.

The highlighted files, especially Windows.Foundation.UniversalApiContract.winmd is where these definitions are. What is really more telling about this problem is that it fails to resolve types in Windows.Foundation.UniversalApiContract.winmd itself. The vast majority of these name resolution failures are from types contained in Windows.Foundation.UniversalApiContract.winmd.

I would bet that some tools are assuming file name is equivalent to root namespace relations here. This would also apply to the SDK contracts NuGet package.

As you can see, the .winmd files in this package are all the separate .winmd files. They are also named after the contract, and not the root namespace. Of course, I tested this out. I renamed Windows.Foundation.FoundationContract.winmd to Windows.Foundation.winmd, I renamed Windows.Foundation.UniversalApiContract.winmd to Windows.winmd, and Windows.Networking.Connectivity.WwanContract.winmd to Windows.Networking.Connectivity.winmd. In this case, winmdidl started finding the metadata.

I really think this is either Visual Studio or the C# tools assuming a relationship between filename and contained namespaces in these metadata files. It would also explain why Visual Studio has no issues with the union metadata.

[Gaoyifei1011]

I had been doing a bit more messing around, and this is possible to trigger in tools that just work with the metadata.

The command line given in the first screenshot gives and the path to the files in the primary location where it is looking for metadata. A screenshot of which is given below.

The highlighted files, especially Windows.Foundation.UniversalApiContract.winmd is where these definitions are. What is really more telling about this problem is that it fails to resolve types in Windows.Foundation.UniversalApiContract.winmd itself. The vast majority of these name resolution failures are from types contained in Windows.Foundation.UniversalApiContract.winmd.

I would bet that some tools are assuming file name is equivalent to root namespace relations here. This would also apply to the SDK contracts NuGet package.

As you can see, the .winmd files in this package are all the separate .winmd files. They are also named after the contract, and not the root namespace. Of course, I tested this out. I renamed Windows.Foundation.FoundationContract.winmd to Windows.Foundation.winmd, I renamed Windows.Foundation.UniversalApiContract.winmd to Windows.winmd, and Windows.Networking.Connectivity.WwanContract.winmd to Windows.Networking.Connectivity.winmd. In this case, winmdidl started finding the metadata.

I really think this is either Visual Studio or the C# tools assuming a relationship between filename and contained namespaces in these metadata files. It would also explain why Visual Studio has no issues with the union metadata.

I'm not sure what this reference assembly Windows.WINMD does.