-
I can not find any documentation on what it does nor if or why it is needed. The application seems to run even if you omit the call. So what gives? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 3 replies
-
It actually works the other way around. It ensures that the process can run XAML, and provides a deterministic error if a check fails. Otherwise, it quietly does nothing. This was originally introduced to ensure that attempting to run Windows App SDK from an elevated process gave a "nice" error until we could provide full support, at which point the check was removed. Without this check, the app would fail during WinRT type lookup, leading to a "type not found" error that would be difficult to root-cause. Now that elevated processes are supported, the check is a no-op but the function is retained for binary compatibility.
|
Beta Was this translation helpful? Give feedback.
It actually works the other way around. It ensures that the process can run XAML, and provides a deterministic error if a check fails. Otherwise, it quietly does nothing.
This was originally introduced to ensure that attempting to run Windows App SDK from an elevated process gave a "nice" error until we could provide full support, at which point the check was removed. Without this check, the app would fail during WinRT type lookup, leading to a "type not found" error that would be difficult to root-cause.
Now that elevated processes are supported, the check is a no-op but the function is retained for binary compatibility.