Aspnetcore: Hot Reload für Blazor

Erstellt am 25. Jan. 2018  ·  130Kommentare  ·  Quelle: dotnet/aspnetcore

  • [] [Build Performance Optimization] (https://github.com/dotnet/aspnetcore/issues/22566)
  • [] Über dotnet watch
  • [] Entwicklungs-Middleware (Websocket-Verbindung zum Empfangen von Updates)
Components Big Rock Design affected-most area-blazor enhancement severity-major

Hilfreichster Kommentar

Dies ist für .NET 5 geplant, das für November 2020 geplant ist. Wir haben noch viele Diskussionen darüber, welchen Ansatz wir hier verfolgen möchten.

Alle 130 Kommentare

Unter https://github.com/aspnet/blazor/issues/193 finden Sie Statusaktualisierungen für dieses Arbeitselement.

Im Moment können wir dotnet watch run und jedes Mal neu kompilieren, wenn die Änderung auftritt.
Verwenden Sie dies einfach in der csproj-Datei:
<DotNetCliToolReference Include="Microsoft.DotNet.Watcher.Tools" Version="2.0.0" />
<Watch Include="**\*.cshtml"/>

Wir haben mit Live-Reload für 0.2.0 einen Haken bekommen, also verschieben Sie dies, bis wir ein robusteres Design durcharbeiten können.

Hallo, ich verwende Dotnet SDK 2.2.100-Preview1-009349 und Blazor 0.5.1 unter Mac.
Live-Reload funktioniert nicht mit "Dotnet Blazor Serve". Wenn ich ein HTML-Markup in einer cshtml-Datei ändere, lädt sich die App nicht neu und nach einem manuellen erneuten Laden des Browsers zeigt die App den alten HTML-Inhalt an. Wie kann ich das lösen?

@ danroth27 , was ist dann https://github.com/aspnet/AspNetCore/issues/4056 ? Sollte es geschlossen sein?

Einige Fragen!
1 Wird dieser Track sowohl für serverseitigen als auch für clientseitigen Blazor live neu geladen?

  1. Wird Live Reload Schiff in Go Live Release (dh in Net Core 3.0)?
  2. Verliert der Live-Reload-Mechanismus den Seitenstatus (dh entspricht einer f5-Aktualisierung) oder verhält er sich ähnlich wie das Ersetzen von Hot-Modulen in Javascript-Land - dh nur die geänderte Benutzeroberfläche für Komponenten wird neu gerendert? Wenn letzteres der Fall ist, gibt es einen Mechanismus, um den Komponentenstatus auf dem Client zwischen den Aktualisierungen beizubehalten?

Wird dieser Track sowohl für serverseitigen als auch für clientseitigen Blazor live neu geladen?

Ja

Wird Live Reload Schiff in Go Live Release (dh in Net Core 3.0)?

Für .NET Core 3.0 wird erwartet, dass die automatische Neuerstellung basierend auf Dateiänderungen unterstützt wird. Sie müssen den Browser jedoch weiterhin manuell aktualisieren.

Verliert der Live-Reload-Mechanismus den Seitenstatus (dh entspricht einer f5-Aktualisierung) oder verhält er sich ähnlich wie das Ersetzen von Hot-Modulen in Javascript-Land - dh nur die geänderte Benutzeroberfläche für Komponenten wird neu gerendert? Wenn letzteres der Fall ist, gibt es einen Mechanismus, um den Komponentenstatus auf dem Client zwischen den Aktualisierungen beizubehalten?

Wir haben derzeit keinen Plan, den Austausch von Hot-Modulen so zu unterstützen, dass der Client-Status erhalten bleibt.

Wir haben derzeit keinen Plan, den Austausch von Hot-Modulen so zu unterstützen, dass der Client-Status erhalten bleibt.

Zumindest nicht automatisch. Wenn Sie einer Redux-ähnlichen Architektur folgen oder etwas anderes, das den Status strikt von der Anzeige entkoppelt, können Sie diesen Status theoretisch serialisieren, bevor Sie ihn entladen und beim erneuten Laden wiederherstellen. Wir planen jedoch nicht, dies als Feature einzubacken, da nicht jeder dieser Art von Architektur folgen möchte.

Dann können Sie diesen Status vor dem Entladen serialisieren und beim erneuten Laden wiederherstellen.

Vielen Dank. Wenn Sie fertig sind, können Sie bitte die entsprechenden Haken (vor dem Entladen / Nachladen usw.) dokumentieren, die im Design enthalten sind, um dies zu erleichtern. Ich möchte mit einem Implementierungs- / Helfer-Nuget-Paket beginnen, um dieses Muster für diejenigen zu aktivieren, die es möchten!

Das dotnet watch run konnte nicht zum

dotnet watch --project "Portfolio.Client" run --project "Portfolio.Server"

Wir haben gerade die folgende grobe Lösung mit nodemon :

npx nodemon --watch "Portfolio.Client" -e razor,css,html,cs --exec 'dotnet run --project "Portfolio.Server"'

Ich dachte, ich sollte rennen:
dotnet watch --project BlazorTest.Client run
Aber das gab mir einen Fehler.

Wenn ich verwendet hätte:
dotnet watch --project BlazorTest.Server run

Mit der folgenden Datei im Projekt BlazorTest.Server.csproj:

<ItemGroup>
    <Watch Include="..\**\*.razor" />
    <Watch Include="..\**\*.scss" />
    <Watch Include="..\**\*.cs" />
</ItemGroup>

Es hat Änderungen im BlazorTest.Client-Projekt übernommen und den Server neu gestartet, sodass ich nur eine manuelle Aktualisierung im Browser durchführen musste.

Es hat Änderungen im BlazorTest.Client-Projekt übernommen und den Server neu gestartet, sodass ich nur eine manuelle Aktualisierung im Browser durchführen musste.

Bedeutet das, dass der Server jedes Mal neu gestartet wird, wenn sich aa css, html ändert?

@dazinator , ja :-)

.. ok nur überprüfen, aber das ist eine schlechte Sache, oder? Dh ein Neustart des Servers sollte für eine Änderung der HTML- oder CSS-Datei nicht erforderlich sein, da eine Browseraktualisierung (mit ungültigem Cache) ausreichen sollte.

Sie haben Recht, das ist nicht nötig. Fügen Sie einfach die Dateierweiterungen, an denen Sie interessiert sind, innerhalb von <ItemGroup> hinzu oder entfernen Sie sie. Meine Antwort wurde aktualisiert, um Verwirrung zu vermeiden.

Entschuldigung, wenn nicht zum Thema gehört, gibt es jetzt überhaupt ein Live-Reload aus Visual Studio (Blazor-Client-Seite)? Im Moment muss ich für jede Änderung mit Ausnahme von wwwroot-Dateien das Projekt erstellen (Strg-Umschalttaste B) und den Browser neu laden. Wäre wunderbar, wenn VS automatisch auf dem Speichern von Änderungen aufbauen kann.

@datvm Wir haben dies für serverseitige Blazor-Projekte aktiviert, müssen jedoch einige Arbeiten ausführen, um dies für clientseitige Blazor-Projekte und Razor-Klassenbibliotheken wieder zu aktivieren. Es wird wahrscheinlich ein bisschen dauern, bis wir dazu kommen, da wir uns gerade auf den Versand von .NET Core 3.0 konzentrieren.

Auf der Clientseite können Sie wahrscheinlich alles verwenden, was nur eine vollständige Seitenaktualisierung durchführt, wenn sich auf dem Server etwas ändert. Schamloser Plug: Schauen Sie sich NetPack an - führen Sie das Beispielprojekt aus und navigieren Sie zum Beispiel / BrowserReload: https://github.com/dazinator/NetPack/blob/develop/src/NetPack.Web/Views/Home/BrowserReload.cshtml - das könnte dir helfen. Wenn nicht, gibt es andere Lösungen zum Auslösen eines erneuten Ladens einer clientseitigen Seite basierend auf serverseitigen Dateiänderungen, wenn Sie nicht auf eine sofort einsatzbereite Lösung warten können.

Vielen Dank für die Lösung, kann tatsächlich für jemand anderen nützlich sein. Für mich wird es nur eine Verbesserung der Lebensqualität sein, nichts Kritisches. Ich liebe immer noch das Produkt und die Mühe, die jeder unternimmt. Das zusätzliche Drücken von Strg + Umschalttaste B funktioniert für mich (jetzt).

Meine Lösung sieht derzeit so aus:
Ich habe eine separate Exe BlazorDebugLauncher, die von launchsettings.json gestartet wird und mit dem Port und dem Hostnamen parametrisiert ist, unter denen der Browser geöffnet werden soll.
Es dann

  • startet eine separate kleine Exe DebugAttacher, die Visual Studio löst und wieder anbringt
  • Startet die Dotnet-Überwachung im Projektordner
  • aktualisiert den Browser, sobald der Serverprozess aktiv ist (funktioniert einwandfrei mit MS Edge :-))

Wenn jemand interessiert ist, kann ich das irgendwo hinstellen ...

@AdmiralSnyder sicher, ich wäre interessiert, das zu sehen, wenn Sie Lust haben zu teilen!

Das ist meine Lösung. ein wenig hacky, funktioniert aber: https://github.com/AdmiralSnyder/BlazorAutoRebuildDemo
(Ich werde nächste Woche aufräumen und eine Readme-Datei hinzufügen…)

@dazinator hast du zufällig einen Blick darauf

@AdmiralSnyder Ich habe einen Blick darauf
Ich habe mich jedoch für diesen Ansatz zum Neuladen des Browsers entschieden (es ist nicht überraschend, dass es sich um meine eigene Bibliothek handelt). https://github.com/dazinator/NetPack/blob/develop/src/NetPack.Web.Blazor.Host/Startup.cs - der ausgeführt wird Der Watcher in der App selbst (mit IFileProvider) startet keine externen Prozesse und löst ein erneutes Laden mit Signal r und einer clientseitigen Blazor-Komponente aus, die Sie Ihrem Blazor-Layout hinzufügen. In Preview6 hat es für mich gut funktioniert und ich werde bald auf Preview7 upgraden und hoffe, dass es weiterhin funktioniert :-)

Ich wollte die erfrischenden Funktionen nicht in das Projekt einbringen. Wie können Sie die Lücke zum Entfernen, Wiederherstellen, Neustarten und erneuten Anhängen schließen, ohne einen externen Prozess zu haben?

Ich wollte die erfrischenden Funktionen nicht in das Projekt einbringen

Sie müssen sie nicht im engeren Sinne in das Projekt einbringen. Beispielsweise können Sie die Paketreferenzen mit einer Bedingung in ein Kompilierungssymbol einfügen (dh debug = true) und den Startcode in eine Kompilierungsanweisung (#if debug) einfügen - und jetzt, wenn Sie die App im Release-Modus ausführen, werden Sie dies nicht tun haben die Entwurfszeitpakete oder den Code darin.

Wie können Sie die Lücke zum Entfernen, Wiederherstellen, Neustarten und erneuten Anhängen schließen, ohne einen externen Prozess zu haben?

Da ich das Host-Projekt über VS ausführe, kann es das referenzierte Blazor-Client-Projekt nach Bedarf neu erstellen (Netpack überwacht die Blazor-Projekte IFileProvider), ohne den Host-Prozess stoppen oder trennen zu müssen. Es gibt nur dann eine "Lücke", wenn ich eine Codeänderung an meiner Hostanwendung selbst vornehmen muss (nicht am Blazor-Client). In diesem Fall hoffe ich sehr, dass "Bearbeiten und Fortfahren" eines Tages wieder funktioniert, da dies das letzte Problem lösen wird. Ohne das gibt es jedoch zwei Möglichkeiten für meinen Ansatz:

  1. Verwenden Sie VS nicht, um den Host auszuführen, verwenden Sie dotnet run watch und hängen Sie den Debugger dann manuell an (ein Schmerz).
  2. Stoppen Sie VS, nehmen Sie die Änderung am Host vor und starten Sie Vs erneut (dies ist normalerweise das, was ich tue).
    @AdmiralSnyder hat dies bearbeitet, um Ihre Fragen hoffentlich besser zu beantworten

Ich sehe ~ 10 Sekunden für einen Wiederaufbau mit dotnet watch . Gibt es Pläne, inkrementelle Builds zu beschleunigen? Das ist ziemlich schmerzhaft, wenn Komponenten iteriert werden.

Es sieht so aus, als würde ein Großteil der Zeit für den Bau der Rasiererkomponenten aufgewendet. Bedeutet das, dass diese Bauzeiten linear skaliert werden? (Bei komplexeren Apps dauert die Erstellung mehr als 30 Sekunden?)

Gibt es Pläne, inkrementelle Builds zu beschleunigen? Das ist ziemlich schmerzhaft, wenn Komponenten iteriert werden.

Wenn dies clientseitiges Blazor ist, sollten Sie die Verknüpfung für Debug-Builds deaktivieren.

  <PropertyGroup Condition="'$(Configuration)' == 'Debug'">
    <BlazorLinkOnBuild>false</BlazorLinkOnBuild>
  </PropertyGroup>

Ich habe mit einigen Leuten gesprochen, die verwirrt sind über die automatische Wiederherstellung und automatische Aktualisierung.
Dies ist hauptsächlich auf die Tatsache zurückzuführen, dass beim Ändern von Code in Visual Studio die Funktion zur automatischen Neuerstellung aktiviert wird und Sie auch feststellen, dass im Browser "etwas" passiert. Dies wird oft mit einem Live-Nachladeversuch verwechselt.
Dann (aufgrund der Tatsache, dass die Signal-R-Verbindung nicht wieder mit dem alten Status verbunden werden kann) erhalten Sie die Meldung "Fehler beim erneuten Verbinden mit dem Server". Error. Für Blazor-Neulinge scheint das System jedoch versucht zu haben, eine automatische Aktualisierung durchzuführen, bei der dies fehlschlägt. Dies ist eine schlechte Erfahrung.

Da es keine ETA für die Live Reload-Funktion gibt, ist es möglich, keine automatische Wiederverbindung zu versuchen, wenn die Verbindung aufgrund eines Builds unterbrochen wurde. Oder zumindest eine bessere Fehlermeldung geben, also anstelle von "Fehler beim erneuten Herstellen der Verbindung zum Server" so etwas wie "Browser aktualisieren"?

@chucker danke für den Tipp zum Deaktivieren des Linkers. Das macht den Build geringfügig, aber dann ist das anschließende Neuladen des Browsers viel langsamer, da jetzt viel mehr Spreu heruntergeladen wird. Ich bin mir nicht sicher, ob es insgesamt geholfen hat oder nicht :-), aber es lohnt sich zu wissen.
Wenn jemand neugierig ist, Blazor Reload in Aktion (für Blazor Client / Wasm) -Projekte zu sehen, können Sie dieses Projekt hier ausführen, um zu sehen, was ich meine: https://github.com/dazinator/NetPack/blob/develop/src/NetPack .Web.Blazor.Host / Startup.cs

@Postlagerkarte Wir versuchen, die Verbindung Blog-Beitrag zur

@Postlagerkarte hat diese Fehlermeldung in Vorschau8 verbessert

Lohnt es sich, je nach Horizont / Zeitplan für das Live-Reload ein separates Problem in Betracht zu ziehen, um die Kompilierungsgeschwindigkeit zu verbessern? Vielleicht über eine Caching-Strategie, die der Funktionsweise von MVC / cshtml ähnelt (ich glaube, nur geänderte Ansichten werden neu kompiliert)? Gibt es hier potenzielle niedrig hängende Früchte?

Derzeit ist die Zykluszeit von 10 Sekunden zwischen dem Vornehmen einer Änderung und dem Anzeigen im Browser nur ein wirklich großes Problem und erheblich größer als bei Webpack-basierten Plattformen mit ähnlichem Anwendungsmaßstab. Und um klar zu sein, ich spreche hier nur von serverseitigem Blazor.

Lohnt es sich, ein separates Problem in Betracht zu ziehen, um die Kompilierungsgeschwindigkeit zu verbessern?

Ja, wenn Sie langsame Build-Zeiten feststellen, melden Sie bitte ein Problem mit Details zu Ihrer Build-Umgebung.

Das erneute Laden der gesamten Blazor-Client-Anwendung (erneutes Herunterladen aller DLLs), wenn Sie eine geringfügige Änderung "nur HTML" an einer Komponente vornehmen (z. B. einige statische HTML-Inhalte ändern), ist ... nicht sehr optimal.

Hat das Team irgendetwas, um Verbesserungen dieser Erfahrung zu verfolgen, oder sollte ich eine neue Ausgabe eröffnen?

@dazinator Aus dem Titel der Ausgabe geht nicht klar hervor, aber wir verwenden diese Ausgabe, um den Austausch heißer Module sowie das Live-Reload zu verfolgen. Wir haben eine Reihe von Investitionen geplant, die wir im Zeitrahmen von .NET 5 in diesem Bereich tätigen möchten.

Persönlich macht es mir nichts aus, F5 zu drücken, und ich denke daher nicht, dass das Nachladen eines Top-Prio-Features heiß ist.
Um jedoch in den Fluss zu kommen, finde ich es entscheidend, dass die
Code ändern, f5, Code ändern, f5, Workflow ändern Code ist blitzschnell (Wortspiel beabsichtigt) schnell. Bitte arbeiten Sie zuerst daran :)

Wir haben dies für serverseitige Blazor-Projekte aktiviert, müssen jedoch einige Arbeiten ausführen, um dies für clientseitige Blazor-Projekte und Razor-Klassenbibliotheken wieder zu aktivieren. Es wird wahrscheinlich ein bisschen dauern, bis wir dazu kommen, da wir uns gerade auf den Versand von .NET Core 3.0 konzentrieren.

Aus verschiedenen GitHub-Problemen konnte ich feststellen, dass das Live-Reload nur auf serverseitigem Blazor funktioniert, das ohne Debugging ausgeführt wird (und der Entwickler muss das Aktualisieren der Seite erzwingen). Ist das korrekt? Ich konnte keine endgültige Dokumentation zu diesem Thema finden.

Was wir derzeit haben, ist die Unterstützung für die automatische Neuerstellung von ASP.NET Core-Projekten, bei der VS das Dateisystem auf Änderungen überwacht und das Projekt dann automatisch neu erstellt und erneut ausführt. Dies funktioniert nur, wenn der Debugger nicht angehängt ist und für Dateien im aktuellen Projekt (abhängige Projekte werden nicht überwacht).

Ist es möglich, den Versuch der automatischen erneuten Verbindung zu deaktivieren, wenn der Grund für den Verbindungsverlust ein Build war? Oder deaktivieren Sie die automatische Wiederverbindung während der Entwicklung? Ich möchte nur die fehlgeschlagenen Wiederverbindungsversuche loswerden, weil sie mich nerven und ich trotzdem F5 drücke :)

Es sollte also ziemlich einfach sein, VS automatisch zu trennen und wieder anzuschließen, oder?

Kann ich die endgültige Lösung für Live Reloading für Blazor Server Apps mit Debugging erhalten?

@ bansalankit2601 Wird in .NET 5.0 implementiert

Ich starte den Watcher als dotnet watch run und benutze VS, um den Code zu bearbeiten. Wenn ich speichere, wird der Code neu kompiliert und der Browser wird gesperrt, sodass ich neu laden soll.

Ich habe es satt, F5 zu drücken und bleibe lieber in VS, während ich die Dinge TamperMonkey zur Rettung:

`` `// == UserScript ==
// @name Lädt die Seite neu
// @namespace http://tampermonkey.net/
// @version 0.1
// @description versuche die Welt zu übernehmen!
// @author You
// @match http: // localhost : 5000 / *
// @grant keine
// == / UserScript ==

const reloader = () => {
    if (document.body.innerText.indexOf("Reload the page") >= 0) document.location = document.location;
    else setTimeout(reloader, 300);
}
console.log('Blazor reloader installed');
setTimeout(reloader, 300);

`` `
Lassen Sie das Skript unter http: // localhost : 5000 / * ausführen

Dies funktioniert auf der Serverseite: https://github.com/martasp/BlazorLiveReload

Der Client pingt den Server alle 200 ms an. Wenn der Server aufgrund einer Neukompilierung von dotnet watch run ausfällt, wird ein Flag umgeschaltet, und wenn der Server zurückkommt, wird automatisch F5s angezeigt.

Das Repo hat bei mir nicht funktioniert, aber ich habe ein Problem mit Javascript geöffnet, das funktioniert (zumindest bei 3.0).

Wie ist der Status von "Live Reload" im Moment. Wird es unterstützt (ohne F5 im Browser)?
Wenn nicht, gibt es Pläne, diese Funktion freizugeben?

@moemar im neuesten Community-Standup David Fowler sagt, es gibt Pläne für möglicherweise die nächste Version, aber es wurde noch nichts eingerichtet. https://youtu.be/bBc_NTUVtbE?list=PL1rZQsJPBU2St9-Mz1Kaa7rofciyrwWVx&t=5010

Was ist das Neueste dazu? 2,5 Monate seit dem letzten Update ...

Ich warte auch darauf.

Dies ist für .NET 5 geplant, das für November 2020 geplant ist. Wir haben noch viele Diskussionen darüber, welchen Ansatz wir hier verfolgen möchten.

Was ist mit der Verwendung des Mechanismus für Blazor- Server ?

@dharmaturtle präsentierte eine Lösung, die den Server alle 200 ms abruft. Es funktioniert, ist aber ärgerlich, da es ständig Anforderungen auslöst, selbst wenn der Server ausgeführt wird.

Wenn Sie Blazor.defaultReconnectionHandler._reconnectionDisplay vom Javascript-Blazor-Client überschreiben, können Sie Verbindungsabbrüche abfangen und den Server abrufen und warten, bis er wieder aktiv wird.

Der Vorteil ist, dass Sie nur Anforderungen haben, wenn der Server nicht verbunden ist.

Der Nachteil ist, dass '_reconnectionDisplay' ein privates Mitglied ist und Sie wissen ... das ist böse.

Fügen Sie zur Schadensbegrenzung den Javascript-Code in <environment include="Development"> . Der Produktionsserver wird nicht ausgeblutet.

Volles Repo hier.

Ich habe vor ein paar Minuten auf diese Lösung umgestellt: https://remibou.github.io/Make-your-Blazor-development-faster/

Es pingt den Server nicht kontinuierlich an und kompiliert nicht die gesamte SLN-Datei neu, wenn sich die Änderung in einer HTML-, CSS- oder JS-Datei befindet. es lädt lediglich die Seite neu, was großartig ist.

Verknüpfen Sie hier einfach ein anderes Beispiel, das sich ein wenig von den oben genannten Ansätzen unterscheidet. Führen Sie einfach das Projekt aus - es erfordert keine Dotnet-Überwachung für das Client-Wasm-Projekt. Es wird sofort neu geladen, wenn Sie eine CSS-, HTML- oder JS-Datei im Ordner wwwroot des Client-Wasms ändern. Es wird neu erstellt und dann neu geladen, wenn Sie Code im Client-Wasm-Projekt wie eine Rasiermesserdatei usw. ändern. Sie haben die Kontrolle darüber in Ihrer startup.cs, weshalb dies etwas anders ist als bei anderen Lösungen. Wenn Sie auch weiterhin Javascript oder andere statische Dateien verwenden, die in Ihrem Projekt vorverarbeitet werden müssen, finden Sie im selben Repo auch andere Beispiele, die möglicherweise nützlich sind, z. B. SystemJS HMR, Rollup usw.

https://github.com/dazinator/NetPack/blob/develop/src/NetPack.Web.Blazor.Host/Startup.cs

Erstellt eine Bibliothek, die Rasiererkomponenten zur Laufzeit kompiliert.

LivePreview

Als Reaktion darauf haben wir einen Hot-Module-Austausch. Mit dieser Funktion können wir den Code ändern und Änderungen sofort in Ihrem Browser sehen. Mit dem Roslyn-Compiler können wir eine ähnliche Funktion in Blazor erstellen. Kompilieren von Rasiererkomponenten zur Laufzeit und Bereitstellen mit WebSockets bei jeder Dateiänderung mithilfe von File Watcher.

Wie es funktioniert

Es verwendet die Razor Engine Version 3, um Komponenten zu C # -Klassen zu kompilieren. Dann habe ich mit dem Roslyn-Compiler diese Klassen bis zur Assembly kompiliert. Schließlich habe ich die app.razor-Komponente aus einer Assembly mit Reflection geladen und mit der vom Steve Sanderson Test Host modifizierten Bibliothek die Komponente in einfaches HTML umgewandelt. Um HTML-Dateien in Echtzeit bereitzustellen, habe ich WebSockets für eine Vollduplex-Kommunikation verwendet.

Wie kann es besser sein

Das Korrigieren von Routen anstelle von / Preview kann implementiert werden, indem der WebSocket-Client in jeden HTTP-Anforderungskontext eingefügt wird.

In Blazor Web Assembly können wir möglicherweise Assemblys im Browser laden und entladen?

Verwenden Sie zwei Build-Server, einen für die schnelle Vorschau und einen anderen Server mit Dotnet-Watch-Build für tatsächlich längere Builds.

In Blazor Web Assembly können wir möglicherweise Assemblys im Browser laden und entladen?

Quelle: https://github.com/martasp/BlazorLiveReload

@martasp

In Blazor Web Assembly können wir möglicherweise Assemblys im Browser laden und entladen?

Es ist eine Version von Mono Runtime, die Blazor Wasm Apps ausführt, aber leider können Sie (meines Wissens nach) keine neuen AppDomains erstellen und keine Assemblys aus der Standard-AppDomain entladen.

Sie können Baugruppen verzögert laden. Auf diese Weise lade ich Komponentenbaugruppen derzeit nur beim ersten Gebrauch dynamisch (um die anfängliche Ladezeit der App zu beschleunigen). Sobald sie jedoch geladen sind, kann ich möglicherweise nur eine neue Version laden, die ich sehen kann Um eine neue Version derselben Assembly in dieselbe AppDomain zu laden und alle Verweise auf diese neue zu wechseln - lassen Sie die alte dort -, sind Sie sich nicht sicher, ob dies unterstützt wird, da ich es noch nicht ausprobiert habe. Wenn Sie in Straßen machen; Gib mir Bescheid!

Ich hoffe, dass wir eines Tages die .net-Kernlaufzeit stattdessen im Browser ausführen können, da sie AssemblyLoadContexts und Assembly.Unload () unterstützt.

Hi @ danroth27 ,
Hast du https://www.livesharp.net/ gesehen
Es ersetzt den Code während der Ausführung .

Es gibt ein Schaufenster, in dem Blazor on-the-fly aktualisiert wird (obwohl man weg und zurück zur aktuellen Route navigieren muss).
Und auch ein Schaufenster, in dem sogar ein Konsolenausgabetext in einer Schleife ersetzt wird, während er ausgeführt wird !

Dies kommt der Erfahrung sehr nahe, die ich mir wünschen würde!

@warappa das ist
Wie auch immer, ein großes Lob an die Entwickler. Ich hätte auch gerne eine Erfahrung wie diese, aber vorzugsweise ohne einen separaten Entwickler-Server würde ich lieber einfach auf VS in Play klicken.

@dazinator LiveSharp Server serialisiert aktualisierten Code und sendet ihn an die Anwendung. Anschließend deserialisiert die Anwendung es in Expression Tree und fügt es in aktualisierte Methoden ein. Im Inneren ist noch viel mehr los, aber das ist der Kern davon.

LiveSharp Server muss übrigens nur einmal gestartet werden. Danach starten Sie einfach die App wie gewohnt.

Hier ist eine Demo von Stateful Blazor Hot-Reload mit LiveSharp: https://www.youtube.com/watch?v=MCh5-44UBpM

Haftungsausschluss: Ich bin der Autor von LiveSharp

@ionoy Kudos, das ist eine

Die Erfahrung, die sich ab sofort für Blazor entwickelt, ist sehr schmerzhaft. Bearbeiten, neu erstellen, aktualisieren, debuggen ...
Würde gerne 9 $ pro Monat zahlen, bis dies behoben ist, würde die Produktivität mindestens 5x steigern.

Bitte berücksichtigen Sie bei der Gestaltung, dass nicht alle von uns Visual Studio verwenden. Vielen Dank

@wocar LiveSharp ist bereits plattformübergreifend und hängt von keiner IDE ab. Sie können es also theoretisch mit notepad.exe verwenden

@wocar Wenn Sie VS nicht verwenden, sollten Sie auch dotnet watch berücksichtigen: https://docs.microsoft.com/en-us/aspnet/core/tutorials/dotnet-watch

@SteveSandersonMS - dotnet watch tötet den Staat, wie Sie zweifellos wissen. LiveSharp überträgt die Änderungen tatsächlich, ohne ein erneutes Laden zu erzwingen, und ermöglicht so eine Feinabstimmung der Benutzeroberfläche mit einer sofortigen Rückkopplungsschleife. Ich wünschte wirklich, ihr würdet bald etwas Äquivalentes implementieren, es wird dringend benötigt.

Ja natürlich. Ich habe nicht vorgeschlagen, dass es dasselbe ist wie LiveSharp. Stellen Sie nur sicher, dass informiert war.

Vielen Dank. Bereits heruntergeladen Livesharp und funktioniert sehr gut, würde gerne so etwas implementiert sehen.

Versteh mich nicht falsch, ihr habt eine großartige Arbeit geleistet, aber wenn ihr ehrliches Feedback wollt, ist das Debuggen von Blazor ein Schmerz. Ich habe Dotnet Watch verwendet und es funktioniert irgendwie (es ist langsam) und ich kann nicht so viel debuggen (zumindest nicht mit Rider), wie ich Blazor verwenden möchte, was ich aus Produktivitätsgründen nicht kann. Also habe ich mich stattdessen für Rasierseiten entschieden.

Vielen Dank.

Danke für das Feedback, @wocar! Ich weiß, dass Hot Reload wichtig ist. Es ist etwas, das wir unbedingt hinzufügen möchten, und wir prüfen, wie es allgemein auf .NET 5 übertragen werden kann.

Ich kann nicht debuggen (zumindest nicht mit Rider)

Möglicherweise ist Ihnen dies bereits bekannt, aber falls dies nicht der Fall ist, können Sie IDE-unabhängig debuggen, indem Sie den Browser als .NET-Debugger verwenden: https://docs.microsoft.com/en-us/aspnet/core /blazor/debug?view=aspnetcore-3.1#debug -in-the-browser

Möglicherweise ist Ihnen dies bereits bekannt, aber falls dies nicht der Fall ist, können Sie IDE-unabhängig debuggen, indem Sie den Browser als .NET-Debugger verwenden: https://docs.microsoft.com/en-us/aspnet/core /blazor/debug?view=aspnetcore-3.1#debug -in-the-browser

Danke war dir nicht bewusst.

Wenn ich Rasierseiten (.cshtml) verwende und den HTML-Code ändere und zumindest F5 drücke, kann ich die Änderungen sehen. Warum dies mit Razor Components (.razor) nicht möglich ist

Ich würde mir auch einen schnelleren Entwicklungszyklus wünschen. Nachdem Hot-Reload für Vue funktioniert hatte, war es so schön, eine Änderung vorzunehmen und sie 1,0 bis 2,0 Sekunden später im Browser anzuzeigen. Jetzt sehe ich hier die Notwendigkeit für so etwas.

dotnet watch run bringt uns hierher - gibt es eine einfachere Zwischenantwort, vielleicht eine Möglichkeit, den Build so zu beschleunigen, dass er schneller ist, wenn sich nur eine .razor-Datei geändert hat? Es würde nicht die Notwendigkeit vermeiden, den Webhost neu zu starten und die Seite neu zu laden, wie dbulic oben sagte, aber 1 Sekunde anstatt 20 Sekunden auf den Build warten zu müssen, wäre groß.

Gibt es Pläne, dies zu beheben, indem eine Art "Laufzeitkompilierung" für .razor-Dateien im Browser ausgeführt wird, analog zur Laufzeitkompilierung von .cshtml-Dateien, die auf dem Server verfügbar ist? Zum Beispiel, damit .razor-Dateien selbst direkt in den Browser geladen werden (anstelle der vorkompilierten Assemblys) und dort kompiliert werden. Wenn sie dann auf dem Server bearbeitet werden, kann die geänderte .razor-Datei erneut in den Browser geladen und dort neu kompiliert werden? Ich mag die Parallelen hier mit cshtml und habe mich gefragt, ob dies überhaupt ein in Betracht gezogener Weg ist.

Dies ist für .NET 5 geplant, das für November 2020 geplant ist. Wir haben noch viele Diskussionen darüber, welchen Ansatz wir hier verfolgen möchten.

Hi @ danroth27 , hat eine Richtung Gestalt angenommen? Wenn noch nichts zu teilen ist, werden wir möglicherweise etwas bei Build 2020 sehen?

Hallo @mrlife. Wir gehen davon aus, dass wir uns in erster Linie auf die Blazor WebAssembly-Version bei BUILD konzentrieren werden. Die Unterstützung für das Hot-Reload wird für .NET 5 erwartet. Die genaue Richtung, wie dies erreicht werden soll, ist noch nicht festgelegt.

Ich denke viel über dieses Problem nach. Jeden Tag verwende ich Muster 1. Muster 2 ist ein Paradigmenwechsel in der Praxis im Vergleich zu Muster 1; Dies macht die Übernahme weniger einfach als die direkte Verbesserung von Muster 1. Ich hoffe, dass Muster 3 nahe an dem liegt, was erreichbar ist. Ich bin der Meinung, dass Muster 4 nur auf der Grundlage der obigen Kommentare angestrebt wird. Nachdem ich jedoch gesehen habe, was in MAUI möglich ist, sieht Muster 6 wirklich gut aus.

Muster 1 (sofort einsatzbereit):

  1. Speichern Sie Änderungen an einer beliebigen Anzahl von Dateien
  2. Klicken Sie auf eine Schaltfläche oder drücken Sie zum Kompilieren den Tastaturbefehl
  3. Aktualisieren Sie den Browser

Muster 2 ( dotnet watch run ):

  1. Speichern Sie die Änderungen in einer Datei
  2. Automatische Neukompilierung
  3. Speichern Sie alle anderen benötigten Dateien und warten Sie auf weitere Neukompilierungen
  4. Aktualisieren Sie den Browser

Muster 3:

  1. Speichern Sie Änderungen an einer beliebigen Anzahl von Dateien
  2. Teilweise oder keine Neukompilierung erforderlich
  3. Aktualisieren Sie den Browser

Muster 4:

  1. Speichern Sie Änderungen an einer beliebigen Anzahl von Dateien
  2. Der Browser zeigt Änderungen in seinem aktuellen Status an

Muster 5 (wie MAUI Hot Reload ):

  1. Speichern Sie keine Änderungen an einer Datei
  2. Der Browser zeigt Änderungen in seinem aktuellen Status an

Was ist erreichbar?

Mein aktuelles Muster mit dotnet watch run :

  1. Speichern Sie Änderungen an allen Dateien mit Ctrl Shift S.
  2. Automatische Neukompilierung
  3. Automatische Aktualisierung des Browsers beschrieben hier .

Verfolgt dieses Problem das Hot Build / Reload sowohl für Blazer Server als auch für Web Assembly oder gibt es ein separates Problem für Web Assembly?

Wie ist der Status dazu? Derzeit wird https://github.com/OYIon/LiveSharp verwendet

das ist alles sehr unangenehm. Ich kann die Problemumgehung für die Dotnet-Uhr auch nicht von einem .dcproj aka Docker-Compose-Projekt zum
Es ist momentan ein Schmerz im * *, mit Blazor von meinem POV zu arbeiten. Kein Live-Update, die Dinge werden ständig rot hervorgehoben und Intellisense funktioniert nur sehr bescheiden.

Gute Technologie braucht auch gute Werkzeuge!

Dinge werden ständig rot hervorgehoben und Intellisense funktioniert nur sehr bescheiden.

Gleich hier meine Problemumgehung:

  • Töte devenv.exe
  • Entfernen Sie den Ordner .vs \
  • Projekt neu starten

Das Werkzeug funktioniert wieder. Tun Sie dies ein paar Mal pro Tag. Mit Refactoring mehrmals pro Stunde. Kombinieren Sie es mit Ihrer Reise zur Kaffeemaschine

Dinge werden ständig rot hervorgehoben und Intellisense funktioniert nur sehr bescheiden.

Ich weiß, dass dies schwierig ist, aber haben Sie irgendwelche Repro-Schritte dafür? Haben Sie beispielsweise einen Projektcode, den Sie freigeben können und der in einer bestimmten Version von VS oder VS-Code zuverlässig zu falschem Intellisense oder Fehlern führt? Wir möchten auf jeden Fall solche Probleme aufspüren und beheben.

cc @NTaylorMullen -

@SteveSandersonMS

Einfach:

  • Benennen Sie eine vorhandene Rasiererkomponentendatei um

image
(Dateien mit demselben Präfix werden ebenfalls umbenannt)

image

  • Aktualisieren Sie den Klassennamen in der Teilklasse

  • Aktualisieren / Umbenennen von Referenzen in anderen Komponenten (manuelle, stark vermisste Werkzeugfunktion)

  • Bauarbeiten

  • Werkzeug kaputt

image

  • Nach dem Löschen des Ordners .\vs vs wird wiederhergestellt

Dinge werden ständig rot hervorgehoben und Intellisense funktioniert nur sehr bescheiden.

Ich weiß, dass dies schwierig ist, aber haben Sie irgendwelche Repro-Schritte dafür? Haben Sie beispielsweise einen Projektcode, den Sie freigeben können und der in einer bestimmten Version von VS oder VS-Code zuverlässig zu falschem Intellisense oder Fehlern führt? Wir möchten auf jeden Fall solche Probleme aufspüren und beheben.

cc @NTaylorMullen -

Vielen Dank für die Antwort, ich werde ein Auge darauf haben. Jede Art von Refactoring ist definitiv problematisch, wie JvanderStad bereits als Beispiel angeführt hat. sonst konnte ich bisher kein Muster sehen.
Ich habe gerade eine Datei mit 219 Zeilen geöffnet und 167 Intellisense-Fehler erhalten. Regeln: CS0121 CS0229 CS1503

Wäre es vielleicht nützlich, ein zusätzliches Github-Problem zu erstellen, um die Intellisense-Probleme zu sammeln? oder existiert das schon? denn dieses Problem ist definitiv der falsche Ort.

Vielen Dank für die Antwort, ich werde ein Auge darauf haben. Jede Art von Refactoring ist definitiv problematisch, wie JvanderStad bereits als Beispiel angeführt hat. sonst konnte ich bisher kein Muster sehen.
Ich habe gerade eine Datei mit 219 Zeilen geöffnet und 167 Intellisense-Fehler erhalten. Regeln: CS0121 CS0229 CS1503

Wäre es vielleicht nützlich, ein zusätzliches Github-Problem zu erstellen, um die Intellisense-Probleme zu sammeln? oder existiert das schon? denn dieses Problem ist definitiv der falsche Ort.

Es ist fast so, dass die Intellisense-Datenbank beschädigt wird / der Sprachdienst abstürzt und nach dem Neustart von VS bestehen bleibt

  <entry>
    <record>1268</record>
    <time>2020/07/08 14:35:36.779</time>
    <type>Error</type>
    <source>Editor or Editor Extension</source>
    <description>System.TimeoutException: The operation has timed out.&#x000D;&#x000A;   at Microsoft.WebTools.Languages.Html.VS.ContainedLanguage.Server.DotNetCoreServerContainedLanguageSupport.OnIdle(Object sender, EventArgs e)</description>
  </entry>

Ich benutze Rider anstelle von vs und scheint sehr gut zu funktionieren. Außerdem verwende ich dieses Tool namens Livesharp, obwohl es nicht so gut oder so zuverlässig ist, erledigt es die Arbeit und ich kann UI-Updates erhalten, ohne neu kompilieren zu müssen.

@ cubed-it Diese PowerShell beendet Visual Studio, entfernt den Ordner .vs \ und startet die Lösung neu. Weniger Kaffeetrips erforderlich.

$start = New-Object Collections.Generic.List[string]

Write-Host "Looking for Visual Studio"  -BackgroundColor DarkGreen
$devenvs = Get-CimInstance Win32_Process -Filter "name = 'devenv.exe'" | Select-Object CommandLine, ProcessId

foreach ($devenv in $devenvs) {

    Write-Host $devenv

    $index = $devenv.CommandLine.IndexOf("devenv.exe`" `"")
    if ($index -eq -1)
    {
        Write-Host "No params"  -BackgroundColor DarkRed
        continue
    }

    $param = $devenv.CommandLine.Substring($index + 12).Trim()
    $project = $param.Trim('"')
    if ($project.Length -eq 0)
    {
        continue
    }

    #allowed project files
    $slnTypes = New-Object System.Collections.Generic.HashSet[string]
    [void]$slnTypes.Add(".sln")
    [void]$slnTypes.Add(".slnf")

    #
    Write-Host "Project: $project"

    $extension = [System.IO.Path]::GetExtension($project)
    if (-not $slnTypes.Contains($extension))
    {
        Write-Host "No solution" -BackgroundColor DarkRed
        continue;
    }


    $vsFolder = [System.IO.Path]::GetDirectoryName($project)
    $vsFolder = "$vsFolder\.vs\"

    if ([System.IO.Directory]::Exists($vsFolder) -eq $false)
    {
        Write-Host ".vs\ folder does not exist" -BackgroundColor DarkRed
        continue
    }

    #we will restart later
    [void]$start.Add($devenv.CommandLine)

    #kill visual studio
    Write-Host "Kill: $devenv" -BackgroundColor DarkGreen
    Stop-Process -id $devenv.ProcessId -Force

    #remove devenv folder
    Write-Host "Removing: $vsFolder" -BackgroundColor DarkGreen
    Remove-Item -Recurse -Force $vsFolder
}


foreach ($devenv in $start) {

    $program =  $devenv.Substring(0, $index + 11)
    $arguments =  $devenv.Substring($index + 12)

    Write-Host "Starting: '$program'"  -BackgroundColor DarkGreen
    Write-Host "Arguments: '$arguments'"  -BackgroundColor DarkGreen

    Start-Process -FilePath $program -ArgumentList $arguments
}

Für diejenigen, die sich an VS halten möchten, können Sie diese Erweiterung für die Problemumgehung ( https://marketplace.visualstudio.com/items?itemName=pragmatrix.BuildOnSave ) verwenden, die automatisch auf save aufbaut und nur zum Starten des Projekts aktiviert werden kann (in diesem Fall Ihr Blazor-Projekt). Deaktivieren Sie für eine bessere Benutzererfahrung "Lunch Browser" im VS, damit der Browser nicht automatisch geschlossen wird. Aber Sie müssen F5 im Browser drücken :-(

Fühle all deinen Schmerz in Bezug auf das Rasiermesser-Werkzeug. Zum Glück möchten wir dies im Zeitrahmen von .NET 5 ansprechen. Wenn Sie dieses Tool ausprobieren möchten (Warnung, es ist derzeit sehr experimentell), können Sie die neueste VS-Vorschauversion herunterladen und das folgende Kontrollkästchen für die Vorschaufunktion aktivieren (Extras -> Optionen -> Umgebung -> Vorschaufunktionen):

image

Es ist sehr wahrscheinlich, dass dadurch viele der in dieser Ausgabe erwähnten Probleme mit dem Razor-Editor behoben werden. Abgesehen davon wissen wir, dass der neue Editor im Vergleich zum vorhandenen Editor einige Lücken und sogar einige schlechte Fehler aufweist. Wir würden uns jedoch über Ihr Feedback freuen, unabhängig davon, ob es insgesamt eine bessere Erfahrung für Ihre Anforderungen war.

Laden Sie die neueste VS-Vorschau herunter
https://visualstudio.microsoft.com/vs/preview/

@NTaylorMullen Gibt es ein Problem, bei dem ich Fehler in Bezug auf das Razor-

image

@JvanderStad Ich glaube, die Syntax sollte "@(row => ...

@JvanderStad Ich glaube, die Syntax sollte "@(row => ...

Funktioniert gut in der aktuellen Version

image

@ JvanderStad ah, wenn Sie über Farben sprechen, ist das derzeit kaputt, wie viele andere Dinge

https://devblogs.microsoft.com/aspnet/new-experimental-razor-editor-for-visual-studio/

Ich habe Daniels Blogpost verpasst. Ich weiß jetzt, was mich erwartet. Danke

@NTaylorMullen Gibt es ein Problem, bei dem ich Fehler in Bezug auf das Razor-

Ya C # semantische Kolorierung haben wir im neuen Editor noch nicht implementiert 😄

@ danroth27 Wenn das Hot-Reload für Blazor Wasm aufgrund der Architektur schwierig ist, kann Hot-Reload für Blazor Server den Trick machen. Die Idee ist, Rasiererkomponenten (aus dem Blazor Wasm-Projekt) während der Entwicklung nahtlos über den Server-Renderer zu rendern und dabei alle Kompatibilitätsprüfungen beizubehalten, die die Bereitstellung von Blazor Wasm sicherstellen und den Test und die Bereitstellung der letzten Phase im tatsächlichen Wasm-Modell durchführen.

Gibt es Updates für das Hot-Reloading, wäre es in .net5 verfügbar oder ist es bereits in der Vorschau verfügbar?

@ qin-guan Hot-Reload ist für .NET 5 aufgrund der begrenzten Zeit in dieser Version nicht geplant. Wir hoffen, Hot Reload für .NET 6 bereitstellen zu können.

@ danroth27 ahhhh booooooo !!

Bitte verzeihen Sie meine vielleicht voreingenommene und vielleicht völlig ignorante Meinung, aber ich habe manchmal das Gefühl, dass Produktivitätsverbesserungen den Leistungsverbesserungen ( von denen viel Arbeit investiert wurde ) in den Hintergrund treten.

Ich würde gerne den Blog über die 250 Produktivitätsverbesserungen sehen, die Sie in dieser Version beispielsweise für Ihre Werkzeuge vorgenommen haben.
Wenn Entwickler aus meiner persönlichen Sicht nicht die produktive Toolkette erhalten, die sie benötigen, können sie die Software nicht schnell genug entwickeln, um die Konkurrenz auf dem Markt zu schlagen, und das Ergebnis ist, dass ihre Anwendungen nicht überleben werden der Marktplatz, um die Vorteile all dieser schönen, glänzenden Leistungsverbesserungen zu nutzen. Aus dieser Perspektive ist es ein wenig erschwerend.

Ich mag jedoch das Aussehen der Perf-Verbesserungen. Ich hoffe nur, dass .NET 6 nicht zu weit hinter .NET 5 liegt und wir sehen, dass die Produktivität in Blazor mit anderen Frameworks Schritt hält!

@ qin-guan Hot-Reload ist für .NET 5 aufgrund der begrenzten Zeit in dieser Version nicht geplant. Wir hoffen, Hot Reload für .NET 6 bereitstellen zu können.

das ist so traurig, ich habe diese Funktion auf .net5 😭😭😭 gewartet

@dazinator @ buster95 Wir teilen Ihre Enttäuschung! Hot Reload stand so ziemlich ganz oben auf unserer Liste der Dinge, die wir in .NET 5 tun wollten, und es befindet sich immer noch ganz oben in unserem Backlog. Es wurde ursprünglich erwartet, dass es Teil eines umfassenderen Hot-Reload-Vorhabens in .NET ist, aber das alles wurde auf .NET 6 übertragen. Ein gutes Hot-Reload ist ein schwieriges Problem - es bedeutet, zuverlässige Wege zu finden, um die laufende App so schnell wie möglich zu aktualisieren möglich und mit hoher Wiedergabetreue. Es braucht nur mehr Zeit, als wir in .NET 5 zur Verfügung hatten.

Aus Gründen der Entwicklerproduktivität überarbeiten wir den Razor-Editor vollständig, der eine ganze Reihe von Produktivitätsfunktionen für die Blazor-Entwicklung ermöglichen soll (Refactoring, Def / Impl, Codeaktionen usw.). Wir haben den neuen Editor Anfang dieses Monats zum ersten Mal als optionale Vorschaufunktion verfügbar gemacht , und wir gehen davon aus, dass er voraussichtlich Anfang nächsten Jahres zum Standard-Razor-Editor wird.

Wir haben auch eine Reihe anderer Blazor-Framework-Funktionen in .NET 5, darunter CSS-Isolierung, verzögertes Laden, Festlegen des Benutzeroberflächenfokus, Ändern des HTML-Kopfs, Hochladen von Dateien, geschützter Browserspeicher, Virtualisierung usw.

@dazinator @ buster95 Wir teilen Ihre Enttäuschung! Hot Reload stand so ziemlich ganz oben auf unserer Liste der Dinge, die wir in .NET 5 tun wollten, und es befindet sich immer noch ganz oben in unserem Backlog. Es wurde ursprünglich erwartet, dass es Teil eines umfassenderen Hot-Reload-Vorhabens in .NET ist, aber das alles wurde auf .NET 6 übertragen. Ein gutes Hot-Reload ist ein schwieriges Problem - es bedeutet, zuverlässige Wege zu finden, um die laufende App so schnell wie möglich zu aktualisieren möglich und mit hoher Wiedergabetreue. Es braucht nur mehr Zeit, als wir in .NET 5 zur Verfügung hatten.

Aus Gründen der Entwicklerproduktivität überarbeiten wir den Razor-Editor vollständig, der eine ganze Reihe von Produktivitätsfunktionen für die Blazor-Entwicklung ermöglichen soll (Refactoring, Def / Impl, Codeaktionen usw.). Wir haben den neuen Editor Anfang dieses Monats zum ersten Mal als optionale Vorschaufunktion verfügbar gemacht , und wir gehen davon aus, dass er voraussichtlich Anfang nächsten Jahres zum Standard-Razor-Editor wird.

Wir haben auch eine Reihe anderer Blazor-Framework-Funktionen in .NET 5, darunter CSS-Isolierung, verzögertes Laden, Festlegen des Benutzeroberflächenfokus, Ändern des HTML-Kopfs, Hochladen von Dateien, geschützter Browserspeicher, Virtualisierung usw.

Gibt es eine Möglichkeit, eine kostenlose Erweiterung wie https://www.livesharp.net zu erstellen und für alle kostenlos zu sein?
image
Diese Erweiterung ist einfach zu konfigurieren, aber im Moment verwende ich die 15-Tage-Testversion 😢

Ich habe eine Frage: Wird Hot Reload für MacOS funktionieren, wie derzeit geplant? Weil das Bearbeiten und Fortfahren ab sofort nicht funktioniert.

https://github.com/dotnet/runtime/issues/12409

@wocar Ja, welche Lösung wir auch

@ danroth27 Kannst du eine nicht so gut funktionierende Lösung
Zum Beispiel eine Entwicklungs-Middleware mit Websocket-Verbindung, die die Seite nach einer langsamen vollständigen Neuerstellung aktualisiert?

@ danroth27 Kannst du eine nicht so gut funktionierende Lösung
Zum Beispiel eine Entwicklungs-Middleware mit Websocket-Verbindung, die die Seite nach einer langsamen vollständigen Neuerstellung aktualisiert?

@xrkolovos Wenn Sie VS haben, können Sie ctrl-shift-b , ctrl-alt-enter (manuell nach dem Erstellen) verwenden, wenn Sie BrowserLink installiert haben: https://docs.microsoft.com/en- us / aspnet / core / clientseitig / using-browserlink? view = aspnetcore-3.1

Können Sie eine nicht so gut funktionierende Lösung anbieten, mit der Sie auch leicht arbeiten können?
Zum Beispiel eine Entwicklungs-Middleware mit Websocket-Verbindung, die die Seite nach einer langsamen vollständigen Neuerstellung aktualisiert?

Wir arbeiten daran, genau das mit dotnet watch für .NET 5 zu tun: https://github.com/dotnet/aspnetcore/pull/24574

@dazinator @ buster95 Wir teilen Ihre Enttäuschung! Hot Reload stand so ziemlich ganz oben auf unserer Liste der Dinge, die wir in .NET 5 tun wollten, und es befindet sich immer noch ganz oben in unserem Backlog. Es wurde ursprünglich erwartet, dass es Teil eines umfassenderen Hot-Reload-Vorhabens in .NET ist, aber das alles wurde auf .NET 6 übertragen. Ein gutes Hot-Reload ist ein schwieriges Problem - es bedeutet, zuverlässige Wege zu finden, um die laufende App so schnell wie möglich zu aktualisieren möglich und mit hoher Wiedergabetreue. Es braucht nur mehr Zeit, als wir in .NET 5 zur Verfügung hatten.

@ danroth27 Soll das "breitere Hot-Reload" für .NET auch für Nicht-Web-Projekte funktionieren? Und gibt es ein Problem, bei dem ich das nachverfolgen könnte?

Wir haben dieses Problem auf den Backlog-Meilenstein verschoben. Dies bedeutet, dass für die kommende Version nicht daran gearbeitet wird. Wir werden den Rückstand nach der aktuellen Version neu bewerten und diesen Punkt zu diesem Zeitpunkt berücksichtigen. Um mehr über unseren Issue-Management-Prozess zu erfahren und bessere Erwartungen in Bezug auf verschiedene Arten von Issues zu haben, lesen Sie unseren Triage-Prozess .

Danke, dass sie uns kontaktiert haben.
Wir verschieben dieses Problem auf den Meilenstein von Next sprint planning für zukünftige Bewertungen / Überlegungen. Wir werden die Anfrage bewerten, wenn wir die Arbeiten für den nächsten Meilenstein planen. Um mehr darüber zu erfahren , was als nächstes zu erwarten und wie wird dieses Thema behandelt werden können Sie mehr über unseren Triage Prozess lesen hier .

Jetzt ist es auf .NET5 verfügbar. Wie kann ich es aktivieren?

Jetzt ist es auf .NET5 verfügbar. Wie kann ich es aktivieren?

Dudeee Check Kommentare oben, dies war für .net 6-Vorschau geplant 😢Screenshot_20201112-071336__01.jpg

@ buster95 was hat dann zum Teufel
Link zum Video: https://www.youtube.com/watch?v=mS6ykjdOVRg

in 2h38mm36ss

@yasserss , zu dieser Zeit sprach Safia Abdalla über die <Virtualize> -Komponente. Sie können den richtigen Videolink zum angegebenen Zeitpunkt senden, indem Sie auf die Schaltfläche zum Teilen von YouTube klicken.

@BrunoBlanes Entschuldigung, hier ist es: https://youtu.be/mS6ykjdOVRg?t=8917

Ich bin mir ziemlich sicher, dass er dotnet watch.

Wenn Sie das Video in 2h: 25m: 40s überprüfen, verwendet er dotnet watch run , um die App auszuführen. Vielleicht haben wir eine Verbesserung von dotnet watch run . Ich erinnere mich, dass ich das letzte Mal, als ich die Leistung der Dotnet-Uhr verwendet habe, schlecht war weiß es jetzt nicht

Ja, wir haben in .NET 5 gearbeitet, um die Leistung von dotnet watch zu verbessern. Zum Beispiel ist es jetzt klüger, nicht jedes Mal, wenn Sie eine Quellenänderung vornehmen, dotnet restore auszuführen, und es kann Neuladungen im Browser auslösen.

Dies ist nicht die ultimative Vision für Hot Reload. Wir planen weiterhin, eine echte Hot-Reload-Funktion in .NET 6 zu entwickeln, aber die dotnet watch Perf-Verbesserungen in .NET 5 sind in der Zwischenzeit ein Fortschritt.

Wir haben auch die Unterstützung für die automatische Aktualisierung des Browsers sowohl in dotnet watch als auch in VS aktiviert. Um diese Funktion in VS zu aktivieren, müssen Sie folgende Option festlegen:

vs-auto-refresh

Dies unterscheidet sich vom Hot-Reload dadurch, dass die App immer noch neu gestartet und die App im Browser neu geladen wird. Sie können sich jedoch darauf konzentrieren, den Code zu bearbeiten, während das Tool den Browser neu erstellt und für Sie aktualisiert.

@ danroth27 Gibt es Neuigkeiten zur automatischen Aktualisierung mit Visual Studio für Mac?

@mrlife etwas, für das wir sehr bald Unterstützung hinzufügen @jongalloway

@ danroth27

Wir haben auch die Unterstützung für die automatische Aktualisierung des Browsers sowohl in dotnet watch als auch in VS aktiviert. Um diese Funktion in VS zu aktivieren, müssen Sie folgende Option festlegen:

vs-auto-refresh

Dies unterscheidet sich vom Hot-Reload dadurch, dass die App immer noch neu gestartet und die App im Browser neu geladen wird. Sie können sich jedoch darauf konzentrieren, den Code zu bearbeiten, während das Tool den Browser neu erstellt und für Sie aktualisiert.

Wenn diese Option aktiviert ist, sollte das Debuggen und erneutes Laden beim Speichern in VS2019 ausreichen. Ich meine, ich habe dies mit der von Ihnen erwähnten Option aktiviert, und wenn ich F5 drücke und mit dem Debuggen beginne und meinen Code ändere, wird der Browser nicht neu geladen. Dies ist jedoch der Fall, wenn ich dotnet watch über die Paketmanagerkonsole ausführe. Wie kann ich diese Funktionalität erreichen, indem ich beim Debuggen nur F5 drücke?

Aufgrund des Abschnitts " Versionshinweisen zu ASP.NET Core 5 ist die automatische Aktualisierung von dotnet watch in Visual Studio derzeit noch nicht verfügbar:

Wir hoffen, die Funktion zur automatischen Aktualisierung in Zukunft in Visual Studio verfügbar zu machen.

@BrunoBlanes Die Unterstützung

@porkopek Automatische Neuerstellung und automatische Aktualisierung funktionieren nur, wenn Sie nicht mit dem Debugger ausgeführt werden.

Die automatische Aktualisierung / Erstellung funktioniert nicht einmal, wenn Sie eine Option in Visual Studio 2019 16.8 auswählen. Manchmal wird im Visual Studio-Popup eine Nullreferenzausnahme angezeigt, wenn ich nach dem Speichern von Änderungen die Option Automatisch erstellen und Browser aktualisieren auswähle. Gibt es noch etwas, das in Visual Studio 2019 16.8 geändert werden muss, damit es funktioniert? @ danroth27

Ich verstehe, dass es in .NET 6 volle Erfahrung geben wird. Was ist mit der aktuellen .NET 5- und Blazor-Webassembly?

Sollte diese Option "Option zum automatischen Erstellen und Aktualisieren" auch für Blazor-Webassemblies funktionieren? Was soll ich mehr tun (als diese Option auf "Automatisch erstellen und aktualisieren ..." zu setzen und zur Datei "Dateiname.razor" zu wechseln, etwas zu ändern und STRG + S? :) Sollte der Browser neu geladen werden?

Wie (oder ist es) korreliert mit dem Browser-Link?

@MussaratAziz Die Informationen zu diesen Hot-Reload-Informationen sind unvollständig und es ist keine MSDN-Seite verfügbar.
In meinem Fall musste ich mich an das IIS Express-Profil halten und das Projekt ohne den Debugger ausführen.
Dadurch wurde das Hot-Reload bzw. der Hot-Restart gestartet, jedoch nur für das Blazor Server-Projekt. Ich habe die WASM-Version nicht getestet.

Ich hoffe wirklich, dass das ASP Core Dev Team (Sie sind großartig !!) dies einschließt, da das Optimieren der Benutzeroberfläche ohne Hotreload ziemlich schmerzhaft ist.

Hoffentlich hilft das :)

USE LIVESHARP ... kann nicht glauben, dass ein Kind in seinem Keller etwas geschafft hat, was Microsoft nicht kann.

Bearbeiten: Entschuldigung, versteh mich nicht falsch, Microsoft hat großartige Arbeit geleistet. Aber diese Funktion ist ein Muss. Nur um einen DIV oder ein Attribut zu ändern, dauert es mindestens 45 Sekunden

Übrigens: Zur Zeit benutze ich LiveSharp. Ja, es kann für Hobbyisten teuer sein und ich würde auch gerne die offizielle Unterstützung des Teams in Redmond sehen.
Das Produkt ist jedoch großartig, der Support ist sehr gut und es funktioniert einfach.
https://www.livesharp.net/blazor/

Prost!

@wocar @ChristianWeyer Wirklich dankbar für Ihre Unterstützung, Jungs! Aber bitte spielen Sie die MS-Bemühungen nicht herunter. Für Dritte ist es fast immer einfacher, eine völlig neue Lösung zu erstellen, da ich niemandem gegenüber rechenschaftspflichtig bin. Dadurch kann ich Risiken eingehen.

Wie auch immer, mehr Zusammenarbeit, weniger Gegensätze.

Nein, ich spiele nicht herunter - au contraire :-) Am Ende geht es um Prios.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen