Thanks for the PR and for filing the issue — the High DPI fix is a real improvement and the before/after screenshots demonstrate the problem clearly.

The manifest files are great. The app.manifest approach with <dpiAwareness>PerMonitorV2</dpiAwareness> is the Microsoft-recommended way to declare DPI awareness for WPF apps. The .csproj references are correct. This is the right solution.

The P/Invoke code in both App.xaml.cs files should be removed. Here's why:

1. The Windows loader processes the manifest during CreateProcessInternalW, before the CLR initializes or any managed code runs. By the time OnStartup() calls EnableDpiAwareness(), PerMonitorV2 awareness is already set.

2. Calling SetProcessDpiAwareness() after the manifest has already set DPI awareness returns E_ACCESSDENIED (documented here): "The DPI awareness is already set, either by calling this API previously or through the application (.exe) manifest." Similarly, SetProcessDpiAwarenessContext() returns FALSE with ERROR_ACCESS_DENIED (documented here).

3. The try/catch blocks won't catch these failures — P/Invoke calls return error codes, they don't throw .NET exceptions. The catches would only fire for DllNotFoundException or EntryPointNotFoundException.

4. There's also a subtle marshaling issue: SetProcessDpiAwareness returns HRESULT (not BOOL), but the P/Invoke declares it as bool. E_ACCESSDENIED (0x80070005) would marshal as true, so even if you checked the return value, it would look like success.

In short: the manifests do all the work. The ~60 lines of P/Invoke per app (enums, DllImports, EnableDpiAwareness()) are dead code that silently fails every time. Removing them keeps the fix clean and correct.

If you'd like, I can trim the P/Invoke code on my end after merge — or you can update the PR to include only the manifest changes. Either way works. The manifests themselves are good to go.