Please don't compile on unsupported APIs in WinUI 3

[ivanlabsii]

Describe the bug

As described here some features from UWP have been replaced with new WinUI features. As such those features do not work and need to be replaced as suggested.

However that part 'do not work' is controversial. By any good practice those features should not compile in WinUI 3 as it is a completely independent framework. But they do, just they crash the app in the runtime.

This makes porting from UWP to WinUI very hard and prone to errors. If this was implemented properly you would get all errors at a glance on compilation and after fixing them you can consider that port is completed. Just like this you need to do many find searches. As you may store some of those objects in custom named variables it can get very extensive. And on top of that there is always a chance that you have missed something and that it will crash the app at runtime.

Steps to reproduce the bug

You can use this line: var flowDirectionSetting = Windows.ApplicationModel.Resources.Core.ResourceContext.GetForCurrentView().QualifierValues["LayoutDirection"];

Expected behavior

This should not compile. It should be presented as Error in Visual Studio.

Screenshots

No response

NuGet package version

WinUI 3 - Windows App SDK 1.2.1: 1.2.221116.1

Windows version

Windows 10 (21H2): Build 19044

Additional context

No response

[JaiganeshKumaran]

UWP XAML APIs (under the Windows.UI.Xaml namespace) already aren't recognised in a WinUI 3 project (at least in C#). This API that you mentioned, however, is a Windows system API.

[bpulliam]

The difficulty here is that the API resolves and is fine from the compiler's viewpoint. The real bug is that the behavior /expectations are different based on the programming model being used to invoke the API.

[ivanlabsii]

The difficulty here is that the API resolves and is fine from the compiler's viewpoint. The real bug is that the behavior /expectations are different based on the programming model being used to invoke the API.

While I do understand that there are some reasons for this, I think that it is also true that there is not a single framework in this world that has APIs whose only function from the perspective of that framework is to crash the app.

Hopefully Microsoft will start porting its UWP apps to WinUI at some point and for more complex apps it will be very easy to conclude that it is impossible to port them unless this (and one more issue related to XAML porting) is fixed…

[Gaoyifei1011]

Describe the bug

As described here some features from UWP have been replaced with new WinUI features. As such those features do not work and need to be replaced as suggested.

However that part 'do not work' is controversial. By any good practice those features should not compile in WinUI 3 as it is a completely independent framework. But they do, just they crash the app in the runtime.

This makes porting from UWP to WinUI very hard and prone to errors. If this was implemented properly you would get all errors at a glance on compilation and after fixing them you can consider that port is completed. Just like this you need to do many find searches. As you may store some of those objects in custom named variables it can get very extensive. And on top of that there is always a chance that you have missed something and that it will crash the app at runtime.

Steps to reproduce the bug

You can use this line: var flowDirectionSetting = Windows.ApplicationModel.Resources.Core.ResourceContext.GetForCurrentView().QualifierValues["LayoutDirection"];

Expected behavior

This should not compile. It should be presented as Error in Visual Studio.

Screenshots

No response

NuGet package version

WinUI 3 - Windows App SDK 1.2.1: 1.2.221116.1

Windows version

Windows 10 (21H2): Build 19044

Additional context

No response

The GetForCurrentView() method is called because the application has some inherent association with CoreWindow. It can be called normally when CoreWindow is present, and it will be called abnormally when CoreWindow is not present. Under Xaml islands, the application has a CoreWindow built in, so the GetForCurrentView() method can be called normally. ms removed the built-in CoreWindow after version 0.8 of the Windows app sdk, but if you want to try calling CoreWindow in a desktop application, you can manually create a CoreWindow, and after the creation is complete, You can then try calling the GetForCurrentView() method.

In addition, Winui3 has not completely removed support for the CoreApplication (UWP) application model, which can be used on UWP in some special way. NET 6+ and Winui3, so removing support for these methods at this time would be irrational and radical.

GetForCurrentView()方法是因为应用程序与CoreWindow有某种内在关联，当CoreWindow存在时，该方法就可以正常调用，CoreWindow不存在时，该方法在调用时发生异常。在Xaml islands下，应用程序内置了一个CoreWindow，所以GetForCurrentView()方法就能正常调用。在Windows app sdk 0.8版本后，ms删除了内置的CoreWindow，但如果您想尝试在桌面应用程序中调用CoreWindow，可以手动创建一个CoreWindow，在创建完成后，就可以尝试调用GetForCurrentView()方法了。

除此之外，Winui3还未完全删除对CoreApplication（UWP）应用模型的支持，可以通过某种特殊方法在UWP上使用.NET 6+和Winui3，所以，这个时候删除对这些方法的支持是不理智且过激的。

Winui3 method for creating CoreWindow Winui3创建CoreWindow的方法

https://github.com/Gaoyifei1011/GetStoreApp/blob/master/GetStoreApp/Views/Windows/MainWindow.xaml.cs

In desktop applications call DisplayInformation. GetForCurrentView () and DataTransferManager GetForCurrentView () success 在桌面应用中调用DisplayInformation.GetForCurrentView()和DataTransferManager.GetForCurrentView()成功 https://github.com/Gaoyifei1011/GetStoreApp/blob/master/GetStoreApp/UI/Controls/Download/CompletedControl.xaml.cs