Skip to content
Discussion options

You must be logged in to vote

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.

  • Ben

Replies: 1 comment 3 replies

Comment options

You must be logged in to vote
3 replies
@Balkoth
Comment options

@BenJKuhn
Comment options

@Balkoth
Comment options

Answer selected by Balkoth
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Category
Q&A
Labels
None yet
2 participants