Problem
Many tests (1052) are still running in UAP mode, which isn't a supported mode in WinUI 3. Having UAP tests has several downsides, including:
- They aren't running in a supported mode, so they may potentially miss issues in a supported mode.
- These tests have kept deprecated APIs in use, such as
Window.Current, causing build warnings and preventing future removal of these deprecated APIs.
- WinUI has needed to keep some UAP-specific code, such as UWPWindowImpl.
- The Microsoft.UI.Content and Microsoft.UI.Input layers have needed to keep UAP-specific code to allow these tests to keep running, which has occasionally comprised design of new code.
- Running tests locally more frequently requires passing
-HostingMode: to specify if tests in WPF mode or UAP mode should be selected. Eliminating UAP mode will greatly reduce the need to specify a mode.
- Having UAP tests provides the false impression this mode is supported, despite aspects where UAP mode will break or misbehave due to missing support.
Proposal
Convert all UAP tests to run in WPF mode, fixing anything which is broken or missing which currently blocks that.
Once that is done, product code for this mode can also be deleted as a separate task.
Problem
Many tests (1052) are still running in UAP mode, which isn't a supported mode in WinUI 3. Having UAP tests has several downsides, including:
Window.Current, causing build warnings and preventing future removal of these deprecated APIs.-HostingMode:to specify if tests in WPF mode or UAP mode should be selected. Eliminating UAP mode will greatly reduce the need to specify a mode.Proposal
Convert all UAP tests to run in WPF mode, fixing anything which is broken or missing which currently blocks that.
Once that is done, product code for this mode can also be deleted as a separate task.