Windows 8.1迁移UWP后navto://自定义URI scheme失效求助

Hey there, I’ve dealt with almost the exact same URI scheme issue when migrating a Windows 8.1 app to UWP, so let me walk you through the fixes that worked for me.

1. Fix the URI Protocol Declaration in Your Package Manifest #

Windows 8.1 and UWP handle protocol registration differently—this is probably the root cause. Open your Package.appxmanifest and replace any old Win8.1-style protocol declarations with the UWP-specific format:

<Applications>
  <Application Id="App" Executable="$targetnametoken$.exe" EntryPoint="YourAppName.App">
    <!-- Other existing code -->
    <Extensions>
      <uap:Extension Category="windows.protocol">
        <uap:Protocol Name="navto">
          <uap:DisplayName>NavTo Navigation Protocol</uap:DisplayName>
        </uap:Protocol>
      </uap:Extension>
    </Extensions>
  </Application>
</Applications>

Make sure you’re using the uap namespace (not the old Windows 8.1 protocol namespace) and that the Name attribute exactly matches your scheme ("navto").

2. Handle Protocol Activation in Your App’s Code #

UWP doesn’t let JS directly intercept custom URIs like Win8.1 did—you need to handle activation at the app level. Open App.xaml.cs and override the OnActivated method to catch protocol launches:

protected override void OnActivated(IActivatedEventArgs args)
{
    if (args.Kind == ActivationKind.Protocol)
    {
        var protocolArgs = args as ProtocolActivatedEventArgs;
        var targetUri = protocolArgs.Uri.AbsoluteUri;

        // Set up the root frame if it doesn't exist
        Frame rootFrame = Window.Current.Content as Frame;
        if (rootFrame == null)
        {
            rootFrame = new Frame();
            Window.Current.Content = rootFrame;
        }

        // Pass the URI to your main page (or WebView container)
        rootFrame.Navigate(typeof(MainPage), targetUri);
        Window.Current.Activate();
    }
}

Once you have the URI in your page, you can pass it to your WebView’s JS using InvokeScriptAsync to trigger your original navigation logic.

3. Intercept WebView Navigation to Block System Prompts #

If your UI is hosted in a WebView, you need to intercept navigation requests to navto:// links before the system tries to handle them. Add this event handler to your WebView:

private void YourWebView_Navigating(WebView sender, WebViewNavigatingEventArgs args)
{
    if (args.Uri.Scheme.Equals("navto", StringComparison.OrdinalIgnoreCase))
    {
        // Cancel the default system navigation
        args.Cancel = true;

        // Call your original JS handler with the URI
        sender.InvokeScriptAsync("handleNavTo", new[] { args.Uri.ToString() });
    }
}

This way, clicking the link in your web page triggers your existing JS logic instead of popping up that annoying "need a new app" message.

4. Verify Protocol Registration #

To make sure your protocol is properly registered, open Command Prompt and run:

start navto://test

If your app launches, the registration is working. If not, double-check your manifest spelling, redeploy the app, or restart your machine (sometimes Windows needs a refresh to pick up new protocol registrations).

These steps fixed the issue for me—let me know if you hit any snags with any of them!

内容的提问来源于stack exchange，提问作者Gopal Devra