Verwenden lokaler Inhalte in WebView2-Apps

Zusätzlich zum Laden von Remoteinhalten können Inhalte auch lokal in WebView2 geladen werden. Es gibt mehrere Ansätze, um lokale Inhalte in ein WebView2-Steuerelement zu laden, z. B.:

  • Navigieren zu einer Datei-URL.
  • Navigieren zu einer HTML-Zeichenfolge.
  • Zuordnung virtueller Hostnamen.
  • Behandeln des WebResourceRequested Ereignisses.

Detaillierter Inhalt:

Auswählen eines Ansatzes

Die verschiedenen Möglichkeiten zum Laden lokaler Inhalte in ein WebView2-Steuerelement unterstützen die folgenden Szenarien:

Szenario Durch Navigieren zu einer Datei-URL Durch Navigieren zu einer HTML-Zeichenfolge Mithilfe der Namenszuordnung für virtuelle Hosts Verwenden Sie dazu WebResourceRequested
Ursprungsbasierte DOM-APIs ✔️ Nein Nein ❌ ✔️ Nein ✔️ Nein
DOM-APIs, die einen sicheren Kontext erfordern Nein ❌ Nein ❌ ✔️ Nein ✔️ Nein
Dynamischer Inhalt Nein ❌ ✔️ Nein Nein ❌ ✔️ Nein
Zusätzliche Webressourcen ✔️ Nein Nein ❌ ✔️ Nein ✔️ Nein
Zusätzliche Webressourcen, die im WebView2-Prozess aufgelöst wurden ✔️ Nein Nein ❌ ✔️ Nein Nein ❌

Diese Szenarien werden im Folgenden beschrieben.

Laden lokaler Inhalte durch Navigieren zu einer Datei-URL

WebView2 ermöglicht die Navigation zu Datei-URLs, um einfaches HTML oder ein PDF zu laden. Dies ist der einfachste und effizienteste Ansatz zum Laden lokaler Inhalte. Es ist jedoch weniger flexibel als die anderen Ansätze. Wie in einem Webbrowser sind Datei-URLs in einigen Funktionen eingeschränkt:

  • Das Dokument hat einen Ursprung, der für seinen Dateipfad eindeutig ist. Dies bedeutet, dass Web-APIs, die einen Ursprung wie localStorage "oder indexedDB " erfordern, funktionieren, aber die gespeicherten Daten für andere lokale Dokumente, die aus anderen Dateipfaden geladen wurden, nicht verfügbar sind.

  • Einige Web-APIs sind nur auf sichere HTTPS-URLs beschränkt und nicht für Dokumente verfügbar, die von Datei-URLs geladen werden. Dazu gehören APIs navigator.mediaDevices.getUserMedia() zum Erfassen von Video oder Sound, navigator.geolocation.getCurrentPosition() zum Zugriff auf den Standort des Geräts oder Notification.requestPermission() zum Anfordern der Berechtigung des Benutzers zum Anzeigen von Benachrichtigungen.

  • Für jede Ressource muss der vollständige Pfad angegeben werden.

  • Um Verweise auf andere lokale Dateien aus Datei-URIs zuzulassen oder XML-Dateien mit angewendeten XSL-Transformationen anzuzeigen, können Sie das --allow-file-access-from-files Browser-Argument festlegen. Siehe CoreWebView2EnvironmentOptions.AdditionalBrowserArguments Eigenschaft.

Überlegungen zum Laden lokaler Inhalte durch Navigieren zu einer Datei-URL

Datei-URLs verhalten sich wie im Browser. Sie können z. B. kein XMLHttpRequest (XHR) in einer Datei-URL erstellen, da Sie nicht im Kontext einer Webseite arbeiten.

Sie müssen für jede Ressource den vollständigen Pfad der Datei angeben. Zum Beispiel:

file:///C:/Users/username/Documents/GitHub/Demos/demo-to-do/index.html
Ursprungsübergreifende Ressourcen

Wenn Sie eine Datei-URL angeben, navigiert die App zu einer Datei auf dem Datenträger, nicht zu einer Domäne im Netzwerk. Daher ist es nicht möglich, ursprungsübergreifende Ressourcen in dem resultierenden Dokument zu verwenden.

Ursprungsbasierte DOM-APIs

Ein Dokument, das über eine Datei-URL geladen wird, hat einen Ursprung, der für seinen Dateipfad eindeutig ist, genau wie im Browser. Web-APIs, die einen Ursprung wie localStorage oder indexedDB erfordern. Unterschiedliche Dokumente, die von unterschiedlichen Datei-URLs geladen werden, werden jedoch nicht als vom selben Ursprung stammend betrachtet und haben keinen Zugriff auf dieselben gespeicherten Daten.

DOM-APIs, die einen sicheren Kontext erfordern

Einige Web-APIs sind nur auf sichere HTTPS-URLs beschränkt und nicht für Dokumente verfügbar, die von Datei-URLs geladen werden. Dazu gehören APIs navigator.mediaDevices.getUserMedia() zum Erfassen von Video oder Sound, navigator.geolocation.getCurrentPosition() zum Zugriff auf den Standort des Geräts oder Notification.requestPermission() zum Anfordern der Berechtigung des Benutzers zum Anzeigen von Benachrichtigungen. Weitere Informationen finden Sie unter Sichere Kontexte auf MDN.

Dynamischer Inhalt

Wenn ein Dokument über eine Datei-URL geladen wird, stammt der Inhalt des Dokuments aus einer statischen Datei auf der Festplatte. Das bedeutet, dass es nicht möglich ist, diesen lokalen Inhalt dynamisch zu ändern. Dies unterscheidet sich vom Laden von Dokumenten von einem Webserver, wo jede Antwort dynamisch generiert werden kann.

Zusätzliche Webressourcen

Die relative URL-Auflösung funktioniert auch für Dokumente, die über eine Datei-URL geladen wurden. Das bedeutet, dass das geladene Dokument Verweise auf zusätzliche Webressourcen wie CSS-, Skript- oder Bilddateien enthalten kann, die ebenfalls über Datei-URLs bereitgestellt werden.

Zusätzliche Webressourcen, die im WebView2-Prozess aufgelöst wurden

Datei-URLs werden in WebView2-Prozessen aufgelöst. Dies ist eine schnellere Option als WebResourceRequested, die im UI-Thread des Host-App-Prozesses aufgelöst wird.

APIs zum Laden lokaler Inhalte durch Navigieren zu einer Datei-URL

Beispiel für eine Datei-URL

In diesem Abschnitt wird gezeigt, wie eine Datei-URL für einen Dateipfad mit lokalem Inhalt auf plattformunabhängige Weise aussieht.

Eine WebView2-App muss lokale Datei-URLs mit einem Präfix und Schrägstrichen file:/// codieren. Für das Demo-To-Do-Beispiel wäre der Pfad beispielsweise:

file:///C:/Users/username/Documents/GitHub/Demos/demo-to-do/index.html

So kopieren Sie den vollständigen Pfad mit dem Präfix "file" für eine lokale Datei:

  1. Klonen Sie optional das Demos-Repository, damit Sie eine lokale Kopie erhalten. Weitere Informationen finden Sie in Schritt 5: Klonen des Demos-Repositorys in Installieren der DevTools-Erweiterung für Visual Studio Code.

  2. Drücken Sie in Microsoft Edge STRG+O , um eine Datei zu öffnen. Öffnen Sie eine lokale .html Datei, z.B. die lokal geklonte Datei Demos/demo-to-do/index.html:

    C:\Users\username\Documents\GitHub\Demos\demo-to-do\index.html

    Die Adressleiste zeigt anfangs nicht das file:/// Präfix an, sondern beginnt mit dem Laufwerkbuchstaben:

    C:/Users/username/Documents/GitHub/Demos/demo-to-do/index.html

    Adressleiste von Microsoft Edge, die das file:/// Präfix anfänglich ausblendet

  3. Klicken Sie auf die Adressleiste, und drücken Sie dann die Home-Taste , oder drücken Sie STRG+A , um den gesamten Pfad auszuwählen.

    Adressleiste von Microsoft Edge zeigt jetzt das file:/// Präfix

    Der gesamte Dateipfad einschließlich file:/// wird in den Zwischenablagepuffer kopiert, sodass Sie den vollständigen Pfad einschließlich des file:/// Präfixes einfügen können:

    file:///C:/Users/username/Documents/GitHub/Demos/demo-to-do/index.html

Siehe auch:

Beispiel für die Navigation zu einer Datei-URL

webView.CoreWebView2.Navigate(
          "file:///C:/Users/username/Documents/GitHub/Demos/demo-to-do/index.html");

Laden lokaler Inhalte durch Navigieren zu einer HTML-Zeichenfolge

Eine weitere Methode zum Laden lokaler Inhalte ist die NavigateToString Methode. Bei diesem Ansatz wird der Inhalt direkt aus einer Zeichenfolge in WebView2 geladen. Dies kann nützlich sein, wenn Sie den Inhalt über den App-Code verpacken oder wenn Sie den Inhalt dynamisch erstellen möchten.

Ein weiteres Szenario, in dem die Navigation zu einer Zeichenfolge nützlich sein kann, ist, wenn Sie Inhalte laden möchten, auf die nicht über eine URL zugegriffen werden kann. Wenn Sie beispielsweise über eine In-Memory-Darstellung eines HTML-Dokuments verfügen, können Sie die NavigateToString Methode verwenden, um diesen Inhalt in das WebView2-Steuerelement zu laden. Dies kann nützlich sein, wenn Sie vermeiden möchten, dass der Inhalt vor dem Laden in das Steuerelement in eine Datei oder einen Server geschrieben werden muss.

Überlegungen zum Laden lokaler Inhalte durch Navigieren zu einer HTML-Zeichenfolge

Die HTML-Inhaltszeichenfolge, die an die NavigateToString Methode übergeben wird, hat eine Größenbeschränkung von 2 MB. Diese Größenbeschränkung kann leicht überschritten werden, wenn die Zeichenfolge Inline-zusätzliche Ressourcen enthält. Wenn dieses Größenlimit überschritten wird, wird ein Fehler zurückgegeben: "Wert liegt nicht im erwarteten Bereich".

Ursprungsbasierte DOM-APIs

Bei einem Dokument, das mit der NavigateToString Methode geladen wird, ist sein Speicherort auf about:blank und sein Ursprung auf nullgesetzt. Dies bedeutet, dass Web-APIs, die von der Definition eines Ursprungs abhängen, wie z. B localStorage . oder indexedDB, nicht verwendet werden können.

DOM-APIs, die einen sicheren Kontext erfordern

Einige Web-APIs sind nur auf sichere HTTPS-URLs beschränkt und stehen für Dokumente, die über die NavigateToString Methode geladen werden, nicht zur Verfügung, da ihr Speicherort auf about:blankfestgelegt ist. Dazu gehören APIs navigator.mediaDevices.getUserMedia() zum Erfassen von Video oder Sound, navigator.geolocation.getCurrentPosition() zum Zugriff auf den Standort des Geräts oder Notification.requestPermission() zum Anfordern der Berechtigung des Benutzers zum Anzeigen von Benachrichtigungen. Weitere Informationen finden Sie unter Sichere Kontexte auf MDN.

Dynamischer Inhalt

Wenn Sie lokale Inhalte über die NavigateToString Methode laden, stellen Sie den Inhalt direkt als Parameter für die Methode bereit. Das bedeutet, dass Sie zur Laufzeit die Kontrolle über den Inhalt haben und ihn bei Bedarf dynamisch generieren können.

Zusätzliche Webressourcen

Das Laden lokaler Inhalte mithilfe der NavigateToString Methode ermöglicht es dem resultierenden Dokument nicht, auf zusätzliche Webressourcen wie CSS-, Bild- oder Skriptdateien zu verweisen. Mit dieser Methode können Sie nur den Zeichenfolgeninhalt des HTML-Dokuments angeben. Verwenden Sie einen der anderen in diesem Artikel beschriebenen Ansätze, oder stellen Sie diese zusätzlichen Webressourcen inline im HTML-Dokument dar, um aus Ihrem HTML-Dokument auf zusätzliche Webressourcen zu verweisen.

Zusätzliche Webressourcen, die im WebView2-Prozess aufgelöst wurden

NavigateToString unterstützt keine zusätzlichen Webressourcen, wie oben erwähnt.

APIs zum Laden lokaler Inhalte durch Navigieren zu einer HTML-Zeichenfolge

Beispiel für die Zeichenfolgendarstellung einer Webseite

Im Folgenden finden Sie die Zeichenfolgendarstellung der Demo To Do-Webseite . In der folgenden Auflistung wurde zur besseren Lesbarkeit ein Zeilenumbruch hinzugefügt. In der Praxis werden diese Zeilen zu einer einzelnen langen Linie verkettet:

`<html lang="en"><head>\n   
<meta charset="UTF-8">\n   
<meta name="viewport" content="width=device-width, initial-scale=1.0">\n   
<title>TODO app</title>\n   
<link rel="stylesheet" href="styles/light-theme.css" media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)">\n   
<link rel="stylesheet" href="styles/dark-theme.css" media="(prefers-color-scheme: dark)">\n   
<link rel="stylesheet" href="styles/base.css">\n   
<link rel="stylesheet" href="styles/to-do-styles.css">\n   
<link rel="icon" href="data:image/svg+xml,<svg xmlns=%22http://www.w3.org/2000/svg%22 viewBox=%220 0 100 100%22><text y=%22.9em%22 font-size=%2290%22>📋
</text></svg>">\n 
</head>\n\n 
<body>\n   
<h1>📋 My tasks</h1>\n   
<form>\n     
<div class="new-task-form" tabindex="0">\n       
<label for="new-task">➕ Add a task</label>\n       
<input id="new-task" autocomplete="off" type="text" placeholder="Try typing 'Buy milk'" title="Click to start adding a task">\n       
<input type="submit" value="➡️">\n     
</div>\n     
<ul id="tasks"><li class="divider">No tasks defined</li></ul>\n   
</form>\n\n    \x3Cscript src="to-do.js">\x3C/script>\n  \n\n
</body>
</html>`

So erhalten Sie die obige Zeichenfolge:

  1. Zur Demo To Do.

  2. Klicken Sie mit der rechten Maustaste auf die Webseite, und wählen Sie dann "Untersuchen " aus, um DevTools zu öffnen.

  3. Geben Sie in der Konsole der DevTools Folgendes ein: document.body.parentElement.outerHTML. Die Konsole gibt eine Zeichenfolgendarstellung der Webseite aus:

    Eine Zeichenfolgendarstellung der Demo To Do-Webseite

Beispiel für die Navigation zu einer HTML-Zeichenfolge

// Define htmlString with the string representation of HTML as above.
webView.CoreWebView2.NavigateToString(htmlString);

Laden lokaler Inhalte mithilfe der Namenszuordnung für virtuelle Hosts

Eine weitere Möglichkeit zum Laden lokaler Inhalte in einem WebView2-Steuerelement ist die Verwendung der Zuordnung virtueller Hostnamen. Dies umfasst die Zuordnung eines lokalen Domänennamens zu einem lokalen Ordner, damit das WebView2-Steuerelement beim Versuch, eine Ressource für diese Domäne zu laden, den Inhalt stattdessen vom angegebenen Speicherort des lokalen Ordners lädt. Der Ursprung des Dokuments ist auch der Name des virtuellen Hosts.

Mit diesem Ansatz können Sie den ursprungsübergreifenden Zugriff mithilfe der CoreWebView2HostResourceAccessKind Aufzählung angeben.

Aufgrund einer aktuellen Einschränkung können Mediendateien, auf die mit einem virtuellen Hostnamen zugegriffen wird, langsam geladen werden.

Überlegungen zum Laden lokaler Inhalte mithilfe der Namenszuordnung virtueller Hosts

Ursprungsbasierte DOM-APIs

Lokale Inhalte, die über die Zuordnung virtueller Hostnamen geladen werden, führen zu einem Dokument mit einer HTTP- oder HTTPS-URL und einem entsprechenden Ursprung. Dies bedeutet, dass Web-APIs, die einen Ursprung wie localStorage "oder indexedDB " erfordern, und andere Dokumente, die zum selben Ursprung gehören, die gespeicherten Daten verwenden können. Weitere Informationen finden Sie unter Same-origin-policy on MDN.

DOM-APIs, die einen sicheren Kontext erfordern

Einige Web-APIs sind nur auf sichere HTTPS-URLs beschränkt. Mithilfe der Namenszuordnung für virtuelle Hosts wird eine HTTPS-URL für Ihre lokalen Inhalte bereitgestellt. Dies bedeutet, dass APIs navigator.mediaDevices.getUserMedia() wie zum Erfassen von Video oder Sound, navigator.geolocation.getCurrentPosition() zum Zugriff auf den Gerätestandort oder Notification.requestPermission() zum Anfordern der Berechtigung des Benutzers zum Anzeigen von Benachrichtigungen verfügbar sind. Weitere Informationen finden Sie unter Sichere Kontexte auf MDN.

Dynamischer Inhalt

Beim Laden lokaler Inhalte über eine Zuordnung virtueller Hostnamen ordnen Sie einen virtuellen Hostnamen einem lokalen Ordner zu, der statische Dateien auf dem Datenträger enthält. Das bedeutet, dass es nicht möglich ist, diesen lokalen Inhalt dynamisch zu ändern. Dies unterscheidet sich vom Laden von Dokumenten von einem Webserver, wo jede Antwort dynamisch generiert werden kann.

Zusätzliche Webressourcen

Lokale Inhalte, die über die Namenszuordnung virtueller Hosts geladen werden, verfügen über eine HTTP- oder HTTPS-URL, die die relative URL-Auflösung unterstützt. Dies bedeutet, dass das geladene Dokument Verweise auf zusätzliche Webressourcen wie CSS-, Skript- oder Bilddateien enthalten kann, die ebenfalls über die Zuordnung virtueller Hostnamen bereitgestellt werden, mit Ausnahme von Quellzuordnungen. Weitere Informationen finden Sie unten unter Quellzuordnungen mit Zuordnung virtueller Hostnamen.

Zusätzliche Webressourcen, die im WebView2-Prozess aufgelöst wurden

URLs virtueller Hostnamen werden in WebView2-Prozessen aufgelöst. Dies ist eine schnellere Option als WebResourceRequested, die im UI-Thread des Host-App-Prozesses aufgelöst wird.

Quellzuordnungen mit Zuordnung virtueller Hostnamen

Quellzuordnungen werden benötigt, um den Quellcode kompilierter Inhalte zu debuggen, einschließlich:

  • Transpiliertes JavaScript, z. B. TypeScript oder minimiertes JavaScript.
  • Kompiliertes CSS, z. B. SASS oder SCSS.

WebView2 lädt keine Quellzuordnungen, auf die von Inhalten verwiesen wird, die mithilfe der Zuordnung virtueller Hostnamen geladen wurden.

Angenommen, WebView2 wird über die Zuordnung virtueller Hostnamen geladen main.js . wenn main.js Referenzen main.js.map als Quellzuordnung, main.js.map wird nicht automatisch geladen.

Um Quellzuordnungen zusammen mit der Zuordnung virtueller Hostnamen zu verwenden, generieren Sie während der Kompilierung Ihrer Inhalte Inline-Quellzuordnungen. Inline-Sourcemaps sind in die entsprechende kompilierte Datei eingebettet.

APIs zum Laden lokaler Inhalte mithilfe der Namenszuordnung virtueller Hosts

Beispiel für die Namenszuordnung virtueller Hosts

webView.CoreWebView2.SetVirtualHostNameToFolderMapping("demo",
         "C:\Github\Demos\demo-to-do", CoreWebView2HostResourceAccessKind.DenyCors);
webView.CoreWebView2.Navigate("https://demo/index.html");

Laden lokaler Inhalte durch Behandlung des Ereignisses WebResourceRequested

Eine weitere Möglichkeit, lokale Inhalte in einem WebView2-Steuerelement zu hosten, besteht darin, sich auf das WebResourceRequested Ereignis zu verlassen. Dieses Ereignis wird ausgelöst, wenn das Steuerelement versucht, eine Ressource zu laden. Sie können dieses Ereignis verwenden, um die Anforderung abzufangen und den lokalen Inhalt bereitzustellen, wie unter Benutzerdefinierte Verwaltung von Netzwerkanforderungen beschrieben.

WebResourceRequested ermöglicht es Ihnen, das Verhalten lokaler Inhalte pro Anforderung anzupassen. Dies bedeutet, dass Sie entscheiden können, für welche Anforderungen Ihre eigenen Inhalte abgefangen und bereitgestellt werden sollen und welche Anforderungen vom WebView2-Steuerelement normal verarbeitet werden sollen. Das Anpassen des Verhaltens erfordert jedoch mehr Code, z. B. die virtuelle Hostzuordnung, und erfordert HTTP-Kenntnisse, um eine geeignete Antwort erstellen zu können.

Aus Sicht von WebView2 wurde die Ressource über das Netzwerk empfangen, und WebView2 hält sich an die Header, die von der App als Teil der Antwort festgelegt werden. Die Verwendung des Ereignisses ist aufgrund der prozessübergreifenden Kommunikation und Verarbeitung, die WebResourceRequested für jede Anforderung erforderlich ist, auch langsamer als andere Ansätze.

Registrierung benutzerdefinierter Schemas

Wenn Sie ein benutzerdefiniertes Schema verwenden möchten, um die Webressourcenanforderung zu erstellen, die das WebResourceRequested Ereignis generiert, lesen Sie die Informationen unter Benutzerdefiniertes Schemaregistrierung in der Übersicht über WebView2-APIs.

Überlegungen zum Laden lokaler Inhalte durch Behandlung des Ereignisses WebResourceRequested

Ursprungsbasierte DOM-APIs

Lokale Inhalte, die über WebResourceRequested Ergebnisse in einem Dokument geladen werden, das über eine HTTP- oder HTTPS-URL und einen entsprechenden Ursprung verfügt. Dies bedeutet, dass Web-APIs, die einen Ursprung wie localStorage "oder indexedDB " erfordern, und andere Dokumente, die zum selben Ursprung gehören, die gespeicherten Daten verwenden können. Weitere Informationen finden Sie unter Same-origin-policy on MDN.

DOM-APIs, die einen sicheren Kontext erfordern

Einige Web-APIs sind nur auf sichere HTTPS-URLs beschränkt. Mit WebResourceRequested können Sie HTTPS-URL-Webressourcenanforderungen durch Ihre eigenen lokalen Inhalte ersetzen. Dies bedeutet, dass APIs navigator.mediaDevices.getUserMedia() wie zum Erfassen von Video oder Sound, navigator.geolocation.getCurrentPosition() zum Zugriff auf den Gerätestandort oder Notification.requestPermission() zum Anfordern der Berechtigung des Benutzers zum Anzeigen von Benachrichtigungen verfügbar sind. Weitere Informationen finden Sie unter Sichere Kontexte auf MDN.

Dynamischer Inhalt

Beim Laden von lokalen Inhalten über WebResourceRequestedgeben Sie den lokalen Inhalt an, der in Ihrem Ereignishandler geladen werden soll. Das bedeutet, dass Sie zur Laufzeit die Kontrolle über den Inhalt haben und ihn bei Bedarf dynamisch generieren können.

Zusätzliche Webressourcen

WebResourceRequested Ändert den Inhalt, der über HTTP- oder HTTPS-URLs geladen wird, die eine relative URL-Auflösung unterstützen. Das bedeutet, dass das resultierende Dokument Verweise auf zusätzliche Webressourcen wie CSS-, Skript- oder Bilddateien enthalten kann, die ebenfalls über bereitgestellt werden, mit Ausnahme von WebResourceRequestedQuellzuordnungen. Weitere Informationen finden Sie unten in Quellzuordnungen mit dem WebResourceRequested Ereignis.

Zusätzliche Webressourcen, die im WebView2-Prozess aufgelöst wurden

Beim Laden von Inhalten über eine Datei-URL oder eine Zuordnung virtueller Hostnamen erfolgt die Auflösung in den WebView2-Prozessen. Das WebResourceRequested Ereignis wird jedoch im WebView2-UI-Thread Ihres Host-App-Prozesses ausgelöst, was zu einem langsameren Laden des resultierenden Dokuments führen kann.

  1. WebView2 hält zunächst das Laden der Webseite an, um auf das Senden des Ereignisses an den Host-App-Prozess zu warten.
  2. WebView2 wartet dann darauf, dass Ihr UI-Thread verfügbar ist.
  3. WebView2 wartet dann auf Ihren App-Code, um das Ereignis zu verarbeiten.

Dies kann einige Zeit dauern. Achten Sie darauf, Aufrufe auf die Webressourcen zu AddWebResourceRequestedFilter beschränken, die das WebResourceRequested Ereignis auslösen müssen.

Quellzuordnungen mit dem WebResourceRequested Ereignis

Quellzuordnungen werden benötigt, um den Quellcode kompilierter Inhalte zu debuggen, einschließlich:

  • Transpiliertes JavaScript, z. B. TypeScript oder minimiertes JavaScript.
  • Kompiliertes CSS, z. B. SASS oder SCSS.

WebView2 lädt keine Quellzuordnungen, auf die von Inhalten verwiesen wird, die mithilfe des WebResourceRequested Ereignisses geladen wurden.

Angenommen, Sie laden main.js Ihren WebResourceRequested Ereignishandler, indem Sie die Response Eigenschaft von CoreWebView2WebResourceRequestedEventArgsfestlegen. If-Referenzen main.jsmain.js.map wie die Quellzuordnung:

  • main.js.map wird nicht automatisch geladen.
  • Ihr WebResourceRequested Ereignishandler wird zum Laden main.js.mapnicht erneut aufgerufen.

Um Quellzuordnungen zusammen mit WebResourceRequestedzu verwenden, verwenden Sie einen der folgenden Ansätze:

  • Generieren Sie Inline-Sourcemaps während der Zusammenstellung Ihrer Inhalte. Inline-Sourcemaps sind in die entsprechende kompilierte Datei eingebettet.

  • Oder separate Inline-Source-Maps werden dem Inhalt zur Laufzeit in Ihrem WebResourceRequested Ereignishandler zugeordnet. Verwenden Sie diesen Ansatz nur, wenn Ihr Buildsystem keine Inline-Source-Maps unterstützt.

APIs zum Laden lokaler Inhalte durch Behandlung des Ereignisses WebResourceRequested

Beispiel für die Behandlung des WebResourceRequested-Ereignisses

// Reading of response content stream happens asynchronously, and WebView2 does not
// directly dispose the stream once it read.  Therefore, use the following stream
// class, which properly disposes when WebView2 has read all data.  For details, see
// [CoreWebView2 does not close stream content](https://github.com/MicrosoftEdge/WebView2Feedback/issues/2513).
class ManagedStream : Stream {
    public ManagedStream(Stream s)
    {
        s_ = s;
    }

    public override bool CanRead => s_.CanRead;

    public override bool CanSeek => s_.CanSeek;

    public override bool CanWrite => s_.CanWrite;

    public override long Length => s_.Length;

    public override long Position { get => s_.Position; set => s_.Position = value; }

    public override void Flush()
    {
        throw new NotImplementedException();
    }

    public override long Seek(long offset, SeekOrigin origin)
    {
        return s_.Seek(offset, origin);
    }

    public override void SetLength(long value)
    {
        throw new NotImplementedException();
    }

    public override int Read(byte[] buffer, int offset, int count)
    {
        int read = 0;
        try
        {
            read = s_.Read(buffer, offset, count);
            if (read == 0)
            {
                s_.Dispose();
            }
        }
        catch
        {
            s_.Dispose();
            throw;
        }
        return read;
    }

    public override void Write(byte[] buffer, int offset, int count)
    {
        throw new NotImplementedException();
    }

   private Stream s_;
}
webView.CoreWebView2.AddWebResourceRequestedFilter("https://demo/*",
                                                CoreWebView2WebResourceContext.All);
webView.CoreWebView2.WebResourceRequested += delegate (object sender,
                                     CoreWebView2WebResourceRequestedEventArgs args)
{
    string assetsFilePath = "C:\\Demo\\" +
                            args.Request.Uri.Substring("https://demo/*".Length - 1);
    try
    {
        FileStream fs = File.OpenRead(assetsFilePath);
        ManagedStream ms = new ManagedStream(fs);
        string headers = "";
        if (assetsFilePath.EndsWith(".html"))
        {
            headers = "Content-Type: text/html";
        }
        else if (assetsFilePath.EndsWith(".jpg"))
        {
            headers = "Content-Type: image/jpeg";
        } else if (assetsFilePath.EndsWith(".png"))
        {
            headers = "Content-Type: image/png";
        }
        else if (assetsFilePath.EndsWith(".css"))
        {
            headers = "Content-Type: text/css";
        }
        else if (assetsFilePath.EndsWith(".js"))
        {
            headers = "Content-Type: application/javascript";
        }

        args.Response = webView.CoreWebView2.Environment.CreateWebResourceResponse(
                                                            ms, 200, "OK", headers);
    }
    catch (Exception)
    {
        args.Response = webView.CoreWebView2.Environment.CreateWebResourceResponse(
                                                        null, 404, "Not found", "");
    }
};

Siehe auch

  • Zuletzt aktualisiert um