Aspnetcore: Rechargement à chaud pour Blazor

Voir https://github.com/aspnet/blazor/issues/193 pour les mises à jour de statut sur cet élément de travail.

Pour l'instant, nous pouvons utiliser dotnet watch run et recompiler à chaque fois que le changement se produit.
Juste en utilisant ceci dans le fichier csproj:
<DotNetCliToolReference Include="Microsoft.DotNet.Watcher.Tools" Version="2.0.0" />
<Watch Include="**\*.cshtml"/>

Nous avons rencontré un problème avec le rechargement en direct pour la version 0.2.0, alors supprimez cela jusqu'à ce que nous puissions travailler sur une conception plus robuste.

Bonjour, j'utilise dotnet sdk 2.2.100-preview1-009349 et blazor 0.5.1 sous Mac.
Le rechargement en direct ne fonctionne pas avec "dotnet blazor serve". Si je modifie un balisage html dans un fichier cshtml, l'application ne se recharge pas et après un rechargement manuel du navigateur, l'application affiche l'ancien contenu html. Comment puis-je resoudre ceci?

@ danroth27 , qu'est-ce que https://github.com/aspnet/AspNetCore/issues/4056 alors? Doit-il être fermé?

Quelques questions!
1 Cette piste se recharge-t-elle en direct pour le blazor côté serveur et le blazor côté client?

1. Live Reload sera-t-il disponible dans la version Go Live (c'est-à-dire dans Net Core 3.0)?
2. Le mécanisme de rechargement en direct perdra-t-il l'état de la page (c'est-à-dire l'équivalent d'une actualisation f5) ou se comportera-t-il de la même manière que le remplacement de module à chaud dans javascript land - c'est-à-dire que seule l'interface utilisateur des composants modifiée sera rendue? Dans ce dernier cas, y aura-t-il un mécanisme pour préserver l'état des composants sur le client entre les mises à jour?

Cette piste se recharge-t-elle en direct pour le blazor côté serveur et le blazor côté client?

Oui

Live Reload sera-t-il disponible dans la version Go Live (c'est-à-dire dans Net Core 3.0)?

Pour .NET Core 3.0, nous prévoyons de prendre en charge la reconstruction automatique en fonction des modifications de fichiers, mais vous devrez toujours actualiser manuellement le navigateur.

Le mécanisme de rechargement en direct perdra-t-il l'état de la page (c'est-à-dire l'équivalent d'une actualisation f5) ou se comportera-t-il de la même manière que le remplacement de module à chaud dans javascript land - c'est-à-dire que seule l'interface utilisateur des composants modifiée sera rendue? Dans ce dernier cas, y aura-t-il un mécanisme pour préserver l'état des composants sur le client entre les mises à jour?

Nous n'avons actuellement pas de plan pour prendre en charge le remplacement de module à chaud d'une manière qui préserve l'état du client.

Nous n'avons actuellement pas de plan pour prendre en charge le remplacement de module à chaud d'une manière qui préserve l'état du client.

Du moins, pas automatiquement. Théoriquement, si vous suivez une architecture de type Redux, ou tout autre élément qui dissocie strictement l'état de l'affichage, vous pouvez sérialiser cet état avant de le décharger et de le restaurer au rechargement. Cependant, ce n'est pas quelque chose que nous prévoyons d'intégrer en tant que fonctionnalité, car tout le monde ne veut pas suivre ce type d'architecture.

alors vous pouvez sérialiser cet état avant le déchargement et restaurer lors du rechargement.

Merci. S'il vous plaît, une fois prêt, seriez-vous en mesure de documenter les crochets appropriés (avant le déchargement / rechargement, etc.) fournis dans la conception pour faciliter cela. Je voudrais commencer sur un package d'implémentation / helper nuget pour activer ce modèle pour ceux qui le souhaitent!

Impossible de faire fonctionner le dotnet watch run , j'ai essayé les options suivantes et d'autres également,

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

Je viens de terminer avec la solution brute suivante en utilisant nodemon :

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

Je pensais que j'étais censé courir:
dotnet watch --project BlazorTest.Client run
Mais cela m'a donné une erreur.

Si j'ai utilisé:
dotnet watch --project BlazorTest.Server run

Avec ce qui suit dans le fichier BlazorTest.Server.csproj du projet:

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

Il a détecté les modifications dans le projet BlazorTest.Client et redémarré le serveur, je n'avais donc qu'à faire une actualisation manuelle dans le navigateur.

Il a détecté les modifications dans le projet BlazorTest.Client et redémarré le serveur, je n'avais donc qu'à faire une actualisation manuelle dans le navigateur.

Cela signifie-t-il que le serveur redémarre à chaque fois qu'il y a un changement css, html ?

@dazinator , oui :-)

.. ok juste vérifier mais c'est une mauvaise chose non? Le redémarrage du serveur devrait-il être inutile pour un changement de fichier html ou css car une actualisation du navigateur (avec cache invalidé) devrait suffire?

Vous avez raison, ce n'est pas nécessaire. Ajoutez ou supprimez simplement les extensions de fichiers qui vous intéressent dans le champ <ItemGroup> . J'ai mis à jour ma réponse pour éviter toute confusion.

Désolé si hors sujet, existe-t-il de toute façon un rechargement en direct à partir de Visual Studio en ce moment (côté client Blazor)? À l'heure actuelle, pour chaque changement à l'exclusion des fichiers wwwroot, je dois construire le projet (Ctrl Shift B) et recharger le navigateur. Ce serait merveilleux si VS pouvait automatiquement construire sur l'enregistrement des modifications.

@datvm Nous avons activé cela pour les projets Blazor côté serveur, mais nous devons faire un peu de travail pour l'activer à nouveau pour les projets Blazor côté client et les bibliothèques de classes Razor. Ce sera probablement un peu avant d'en arriver là, car nous nous concentrons actuellement sur la livraison de .NET Core 3.0.

Côté client, vous pouvez probablement utiliser tout ce qui ne fait qu'une actualisation complète de la page lorsque quelque chose change sur le serveur. Plug Shameless: consultez NetPack - exécutez l'exemple de projet et accédez à l'exemple / BrowserReload: https://github.com/dazinator/NetPack/blob/develop/src/NetPack.Web/Views/Home/BrowserReload.cshtml pourrait vous aider. Sinon, il existe d'autres solutions pour déclencher un rechargement de page côté client en fonction des modifications de fichier côté serveur si vous ne pouvez pas attendre une solution prête à l'emploi.

Merci pour la solution, peut en fait être utile pour quelqu'un d'autre. Pour moi, ce ne sera qu'une amélioration de la qualité de vie, rien de critique. J'adore toujours le produit et l'effort que tout le monde déploie. Une pression supplémentaire sur Ctrl Shift B fonctionne pour moi (maintenant).

Ma solution ressemble actuellement à ceci:
J'ai un exe séparé BlazorDebugLauncher qui démarre par launchsettings.json paramétré avec le port et le nom d'hôte que le navigateur doit être ouvert.
Alors

• démarre un petit exe DebugAttacher séparé qui détache et rattache Visual Studio
• lance la montre dotnet sur le dossier du projet
• actualise le navigateur dès que le processus serveur est en place (fonctionne très bien avec MS Edge :-))

Si quelqu'un est intéressé, je peux mettre ça quelque part ...

@AdmiralSnyder, je serais certainement intéressé de voir ça si vous avez envie de partager!

Vaut le détour: https://github.com/RickStrahl/Westwind.AspnetCore.LiveReload

c'est ma solution. un peu hacky, mais fonctionne: https://github.com/AdmiralSnyder/BlazorAutoRebuildDemo
(Je nettoierai et ajouterai un readme la semaine prochaine…)

@dazinator avez-vous jeté un coup d'œil?

@AdmiralSnyder J'ai
J'ai choisi cette approche pour le rechargement du navigateur (c'est ma propre bibliothèque sans surprise) https://github.com/dazinator/NetPack/blob/develop/src/NetPack.Web.Blazor.Host/Startup.cs - qui fonctionne l'observateur dans l'application elle-même (en utilisant IFileProvider) plutôt que de lancer des processus externes, et il déclenche un rechargement à l'aide du signal r et d'un composant côté client blazor que vous ajoutez à votre disposition blazor. Cela fonctionne bien pour moi dans preview6 et je vais bientôt passer à preview7 et j'espère que cela continuera à fonctionner :-)

Je ne voulais pas apporter les fonctionnalités rafraîchissantes dans le projet. Comment combler l'écart de détachement-reconstruction-redémarrage-réattachement sans avoir de processus externe?

Je ne voulais pas intégrer les fonctionnalités rafraîchissantes au projet

Vous n'êtes pas obligé de les intégrer au projet au sens strict. Par exemple, vous pouvez inclure les références de package avec une condition sur un symbole de compilation (Ie debug = true) et vous pouvez placer le code de démarrage dans une directive de compilation (#if debug) - et maintenant, lorsque vous exécutez l'application en mode version, vous ne avoir les packages de conception ou le code dedans.

Comment combler l'écart de détachement-reconstruction-redémarrage-réattachement sans avoir de processus externe?

Étant donné que j'exécute le projet hôte à partir de VS, il peut reconstruire le projet client blazor référencé selon les besoins (netpack surveille les projets blazor IFileProvider) sans avoir à arrêter ou à se détacher du processus hôte. Le seul moment où il y a un «écart», c'est si je dois modifier le code de mon application hôte elle-même (pas le client Blazor). Dans ce cas - j'espère sincèrement qu'un jour "Edit and Continue" fonctionnera à nouveau car cela résoudra ce dernier problème. Cependant, sans cela, il y a deux options pour mon approche:

1. N'utilisez pas VS pour exécuter l'hôte, utilisez dotnet run watch , puis attachez le débogueur manuellement (un problème)
2. Arrêtez VS, apportez le changement à l'hôte, redémarrez Vs (c'est généralement ce que je fais)
   @AdmiralSnyder a modifié ceci pour mieux répondre à vos questions.

Je vois ~ 10 secondes pour une reconstruction en utilisant dotnet watch . Existe-t-il des plans pour accélérer les builds incrémentiels? C'est assez douloureux lors d'une itération sur des composants.

Il semble qu'une grande partie du temps soit consacrée à la construction des composants du rasoir, cela signifie-t-il que ces temps de construction vont être mis à l'échelle ~ linéairement? (avec des applications plus complexes prenant plus de 30 secondes à construire?)

Existe-t-il des plans pour accélérer les builds incrémentiels? C'est assez douloureux lors d'une itération sur des composants.

S'il s'agit de Blazor côté client, envisagez de désactiver la liaison pour les versions de débogage.

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

J'ai parlé à quelques personnes qui sont confuses au sujet de la reconstruction automatique et de l'actualisation automatique.
Cela est principalement dû au fait que lorsque vous modifiez le code dans Visual Studio, la fonctionnalité de reconstruction automatique entre en action et vous voyez également que "quelque chose" se produit dans le navigateur. Ce quelque chose est souvent confondu avec une tentative de rechargement en direct.
Ensuite (en raison du fait que la connexion signal-r ne peut pas se reconnecter à l'ancien état), vous obtenez le message «Échec de la reconnexion au serveur». Erreur. Cependant, pour les nouveaux utilisateurs de Blazor, il semble que le système ait essayé une actualisation automatique, ce qui échoue, ce qui est une mauvaise expérience.

Puisqu'il n'y a pas d'ETA sur la fonction de rechargement en direct, est-il possible de ne pas essayer de se reconnecter automatiquement si la connexion est interrompue en raison d'une compilation? Ou au moins donner un meilleur message d'erreur, donc au lieu de "Impossible de se reconnecter au serveur" quelque chose comme "Actualiser le navigateur"?

@chucker merci pour le conseil de désactivation de l'éditeur de liens. Cela augmente légèrement la construction, mais le rechargement ultérieur du navigateur est beaucoup plus lent car il télécharge maintenant beaucoup plus de paillettes - je ne sais pas si globalement cela a aidé ou non :-) mais cela vaut la peine de savoir.
Si quelqu'un est curieux de voir les projets blazor recharger en action (pour le client blazor / wasm), vous pouvez exécuter ce projet ici pour voir ce que je veux dire: https://github.com/dazinator/NetPack/blob/develop/src/NetPack .Web.Blazor.Host / Startup.cs

@Postlagerkarte Nous essayons de nous reconnecter, mais comme l'état du serveur a disparu lorsque le processus est recyclé, la reconnexion échoue. Nous avons fait du travail dans cet espace pour essayer d'améliorer l'expérience utilisateur. Consultez la section «Amélioration de la logique de reconnexion pour les applications Blazor Server» dans le billet de blog de l'annonce Preview 8 .

@Postlagerkarte a amélioré ce message d'erreur dans l' aperçu8

En fonction de l'horizon / de la chronologie du rechargement en direct, cela vaut-il la peine d'envisager un problème distinct pour améliorer la vitesse de compilation? Peut-être via une stratégie de mise en cache similaire au fonctionnement de MVC / cshtml (je crois que seules les vues qui ont changé sont recompilées)? Y a-t-il des fruits potentiels à portée de main ici?

À l'heure actuelle, le temps de cycle de 10 secondes entre la modification et la visualisation dans le navigateur n'est qu'un très gros problème, et est beaucoup plus important que les plates-formes basées sur des packs Web à une échelle d'application similaire. Et pour être clair, je parle ici de blazor côté serveur.

Vaut-il la peine d'envisager un problème distinct pour améliorer la vitesse de compilation?

Oui, si vous constatez des temps de construction lents, veuillez signaler un problème avec les détails de votre environnement de construction.

Avoir à recharger l'ensemble de l'application client blazor (re-télécharger toutes les dll) lorsque vous apportez une modification mineure "html seulement" à un composant (par exemple, changer du contenu html statique) n'est ... pas très optimal.

L'équipe a-t-elle quelque chose pour suivre les améliorations apportées à cette expérience ou dois-je ouvrir un nouveau problème?

@dazinator Ce n'est pas très clair d'après le titre du problème, mais nous utilisons ce problème pour suivre le remplacement du module à chaud ainsi que le rechargement en direct. Nous avons un tas d'investissements que nous prévoyons de faire dans le délai .NET 5 dans ce domaine.

Personnellement, cela ne me dérange pas de frapper F5 et je ne considère donc pas le rechargement à chaud comme une fonctionnalité prio supérieure,
Cependant, pour entrer dans le courant, je trouve crucial que le
changer le code, f5, changer le code, f5, changer le flux de travail de code est fulgurant (jeu de mots) rapide. Veuillez d'abord travailler dessus :)

Nous l'avons activé pour les projets Blazor côté serveur, mais nous devons faire un certain travail pour l'activer à nouveau pour les projets Blazor côté client et les bibliothèques de classes Razor. Ce sera probablement un peu avant d'en arriver là, car nous nous concentrons actuellement sur la livraison de .NET Core 3.0.

D'après ce que j'ai pu collecter à partir de divers problèmes de GitHub, le rechargement en direct ne fonctionne que sur Blazor côté serveur qui est exécuté sans débogage (et le développeur doit forcer l'actualisation de la page). Est-ce exact? Je n'ai pas trouvé de documentation définitive sur le sujet.

Ce que nous avons en ce moment est vraiment la prise en charge de la reconstruction automatique pour les projets ASP.NET Core, où VS surveillera le système de fichiers pour les modifications, puis reconstruira et réexécutera automatiquement le projet. Cela ne fonctionne que lorsque le débogueur n'est pas joint et pour les fichiers du projet en cours (les projets dépendants ne sont pas surveillés).

Est-il possible de désactiver la tentative de reconnexion automatique au cas où la raison de la perte de connexion serait une construction? Ou peut-être désactiver la reconnexion automatique pendant le développement? Je veux juste me débarrasser de ces tentatives de reconnexion qui échouent car elles me dérangent et j'appuie quand même sur F5 :)

Il devrait donc être assez facile de détacher et de rattacher VS automatiquement, non?

Puis-je obtenir la solution finale pour le rechargement en direct pour les applications serveur Blazor avec le débogage?

@ bansalankit2601 À implémenter dans .NET 5.0

Je lance l'observateur en tant que dotnet watch run et j'utilise VS pour modifier le code. Lorsque j'enregistre, le code est recompilé et le navigateur se verrouille, me disant que je dois recharger.

Je suis fatigué d'appuyer sur F5 et préfère rester dans VS tout en ajustant les choses, alors TamperMonkey à la rescousse:

`` `` // == UserScript ==
// @name Recharger la page
// @namespace http://tampermonkey.net/
// @version 0.1
// @description essaie de
// @ vous
// @match http: // localhost : 5000 / *
// @grant aucun
// == / 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);

''
Autoriser le script à s'exécuter sur http: // localhost : 5000 / *

Cela fonctionne pour le côté serveur: https://github.com/martasp/BlazorLiveReload

Le client envoie une requête ping au serveur toutes les 200 ms. Lorsque le serveur tombe en panne en raison d'une recompilation à partir de dotnet watch run , un indicateur est basculé, et lorsque le serveur revient, il est automatiquement F5.

Le dépôt n'a pas fonctionné pour moi, mais j'ai ouvert un problème avec du javascript qui fonctionne (du moins pour moi sur 3.0)

Quel est le statut de "Live reload" pour le moment. Est-il pris en charge (sans F5 dans le navigateur)?
Sinon, est-il prévu de publier cette fonctionnalité?

@moemar dans le dernier https://youtu.be/bBc_NTUVtbE?list=PL1rZQsJPBU2St9-Mz1Kaa7rofciyrwWVx&t=5010

Quelle est la dernière à ce sujet? 2,5 mois depuis la dernière mise à jour ...

J'attends aussi la même chose.

Ceci est prévu pour .NET 5, qui est prévu pour novembre 2020. Nous avons encore beaucoup de discussions sur l'approche que nous voulons adopter ici.

Pour Blazor côté serveur , qu'en est-il de l'utilisation du mécanisme qui gère les déconnexions:

@dharmaturtle a présenté une solution qui récupère le serveur toutes les 200 ms. Cela fonctionne mais c'est ennuyeux car il déclenche constamment des requêtes même lorsque le serveur fonctionne.

Si vous remplacez Blazor.defaultReconnectionHandler._reconnectionDisplay du client javascript blazor, vous pouvez intercepter les déconnexions et commencer à récupérer le serveur et attendre qu'il redevienne actif.

L'avantage est que vous n'avez de demandes que lorsque le serveur est déconnecté.

L'inconvénient est que '_reconnectionDisplay' est un membre privé et vous savez ... c'est mal.

En guise d'atténuation, placez le code javascript dans <environment include="Development"> . Il ne saignera pas dans le serveur de production.

Repo complet ici.

Je viens de passer à cette solution il y a quelques minutes: https://remibou.github.io/Make-your-Blazor-development-faster/

Il ne ping pas continuellement le serveur, et il ne recompile pas le .sln entier si la modification est dans un fichier .html, un .css ou un .js; il recharge simplement la page, ce qui est génial.

Reliez simplement un autre exemple ici qui est un peu différent des approches ci-dessus. Exécutez simplement le projet - il ne nécessite pas de surveillance dotnet sur le projet client wasm. Il se rechargera immédiatement si vous modifiez un fichier css, html ou js dans le dossier wwwroot du client wasm. Il reconstruira puis rechargera, si vous modifiez un code dans le projet wasm client comme un fichier rasoir, etc. Vous en avez le contrôle dans votre startup.cs, c'est pourquoi c'est un peu différent des autres solutions. Si vous utilisez toujours javascript ou d'autres fichiers statiques qui doivent être pré-traités dans votre projet, vous pouvez également trouver d'autres exemples dans le même référentiel qui pourraient être utiles, tels que SystemJS HMR, rollup, etc.

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

Création d'une bibliothèque qui compile les composants du rasoir au runtime.

En réaction, nous avons un remplacement de module à chaud, cette fonctionnalité nous permet de changer le code et de voir immédiatement les modifications dans votre navigateur. Nous pouvons créer une fonctionnalité similaire dans blazor en utilisant le compilateur Roslyn. Compilation des composants de rasoir au moment de l'exécution et service avec WebSockets à chaque changement de fichier à l'aide de File Watcher.

Comment ça fonctionne

Il utilise la version 3 du moteur Razor pour compiler les composants en classes c #. Ensuite, en utilisant le compilateur Roslyn, j'ai compilé ces classes en assemblage. Enfin, j'ai chargé le composant app.razor à partir d'un assemblage avec réflexion et avec la bibliothèque modifiée par l'hôte Steve Sanderson Test, j'ai transformé le composant en HTML brut. Pour servir des fichiers HTML en temps réel, j'ai utilisé WebSockets pour avoir une communication en duplex intégral.

Comment ça peut être mieux

En corrigeant les routes au lieu d'utiliser / preview, cela pourrait être implémenté en injectant le client WebSocket dans chaque contexte de requête HTTP.

Dans l'assemblage Web Blazor, nous pouvons peut-être charger et décharger des assemblys dans le navigateur?

Utilisation de deux serveurs de build, un pour une prévisualisation rapide et un autre serveur avec dotnet watch build pour les versions réelles et plus longues.

Dans l'assemblage Web Blazor, nous pouvons peut-être charger et décharger des assemblys dans le navigateur?

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

@martasp

Dans l'assemblage Web Blazor, nous pouvons peut-être charger et décharger des assemblys dans le navigateur?

C'est une version de runtime mono exécutant des applications blazor wasm, mais malheureusement, vous ne pouvez pas créer de nouveaux AppDomains (à ma connaissance) et vous ne pouvez pas décharger les assemblys de l'AppDomain par défaut.

Vous pouvez charger des assemblages paresseux, c'est ainsi que je charge actuellement dynamiquement des assemblages de composants uniquement lors de la première utilisation (pour accélérer le temps de chargement initial de l'application), mais une fois qu'ils sont chargés, le seul moyen de charger une nouvelle version que je peux voir est peut-être pour charger une nouvelle version du même assembly dans le même AppDomain et basculer toutes les références vers ce nouveau - en laissant l'ancien là - je ne sais pas si cela est pris en charge car je ne l'ai pas encore essayé. Si vous faites dans les routes; faites le moi savoir!

J'espère qu'un jour nous pourrons faire fonctionner le runtime principal .net dans le navigateur à la place avec son support pour AssemblyLoadContexts et Assembly.Unload ()

Salut @ danroth27 ,
avez-vous vu https://www.livesharp.net/?
Il remplace le code pendant son exécution .

Il y a une vitrine où il met à faille naviguer et revenir à l'itinéraire actuel).
Et aussi une vitrine où même un texte de sortie de console dans une boucle est remplacé _ pendant son exécution_ !

C'est très proche de l'expérience que je souhaiterais!

@warappa c'est génial. Je me demande comment ça marche! Je peux penser à quelques mécanismes possibles remplaçant les méthodes par des proxys dynamiques.
Cependant, cela fonctionne, félicitations au / aux développeur / s. J'aimerais aussi une expérience comme celle-ci, mais de préférence sans serveur de développement séparé, je préférerais simplement cliquer sur jouer dans VS.

@dazinator LiveSharp Server sérialise le code mis à jour et l'envoie à l'application. Ensuite, l'application le désérialise dans l'Expression Tree et l'injecte dans les méthodes mises à jour. Il se passe beaucoup plus à l'intérieur, mais c'est l'essentiel.

À propos, LiveSharp Server ne doit être démarré qu'une seule fois. Après cela, démarrez simplement l'application comme vous le faites habituellement.

Voici une démonstration du rechargement à chaud de Blazor avec état avec LiveSharp: https://www.youtube.com/watch?v=MCh5-44UBpM

Avertissement: je suis l'auteur de LiveSharp

@ionoy bravo, c'est du bon travail là-bas!

L'expérience qui se développe pour Blazor à partir de maintenant est très douloureuse. Modifier, reconstruire, actualiser, déboguer ...
Je paierais volontiers 9 $ par mois jusqu'à ce que cela soit réglé, augmenterait la productivité d'au moins 5x.

Lors de la conception, veuillez tenir compte du fait que nous n'utilisons pas tous Visual Studio. Merci

@wocar LiveSharp est déjà multiplateforme et ne dépend d'aucun IDE. Vous pouvez donc théoriquement l'utiliser avec notepad.exe

@wocar Si vous n'utilisez pas VS, considérez également dotnet watch : https://docs.microsoft.com/en-us/aspnet/core/tutorials/dotnet-watch

@SteveSandersonMS - dotnet watch tue l'état, comme vous le savez sans aucun doute. LiveSharp pousse en fait les changements sans forcer un rechargement et permet ainsi un réglage fin de l'interface utilisateur avec une boucle de rétroaction instantanée. Je souhaite vraiment que vous implémentiez bientôt quelque chose d'équivalent, c'est cruellement nécessaire.

Oui bien sûr. Je ne suggérais pas que ce soit la même chose que LiveSharp. Assurez-vous simplement que

Merci. Déjà téléchargé Livesharp et fonctionne très bien, je voudrais voir quelque chose comme ça implémenté.

Ne vous méprenez pas, vous avez fait un travail incroyable, mais si vous voulez des commentaires honnêtes, le débogage de blazor est une douleur. J'ai utilisé la montre dotnet et cela fonctionne un peu (c'est lent) et je ne peux pas déboguer (du moins pas avec Rider) donc autant que je voudrais utiliser blazor, je ne peux pas à cause de la productivité. J'ai donc décidé de m'en tenir aux pages rasoir à la place.

Je vous remercie.

Merci pour vos commentaires, @wocar! Je sais que le rechargement à chaud est important. C'est quelque chose que nous voulons fortement ajouter, et nous cherchons des moyens de l'amener à .NET 5 en général.

Je ne peux pas déboguer (du moins pas avec Rider)

Vous le savez peut-être déjà, mais au cas où non, il est possible de déboguer de manière indépendante de l'IDE en utilisant le navigateur comme débogueur .NET: https://docs.microsoft.com/en-us/aspnet/core /blazor/debug?view=aspnetcore-3.1#debug -dans-le-navigateur

Vous le savez peut-être déjà, mais au cas où non, il est possible de déboguer de manière indépendante de l'IDE en utilisant le navigateur comme débogueur .NET: https://docs.microsoft.com/en-us/aspnet/core /blazor/debug?view=aspnetcore-3.1#debug -dans-le-navigateur

Merci vous n'étiez pas au courant.

Si j'utilise des pages rasoir (.cshtml) et que je modifie le HTML et que j'appuie sur F5 au moins, je peux voir les changements. Pourquoi cela n'est pas possible avec Razor Components (.razor)

J'aimerais aussi avoir un cycle de développement plus rapide. Une fois que le rechargement à chaud a fonctionné pour Vue, c'était tellement agréable de faire un changement et de le voir 1,0 à 2,0 secondes plus tard dans le navigateur. Maintenant, je vois la nécessité de quelque chose comme ça ici.

dotnet watch run nous permet de faire une partie du chemin ici - y aurait-il une réponse intermédiaire plus simple, peut-être un moyen d'accélérer la construction afin qu'elle soit plus rapide quand rien d'autre qu'un fichier .razor n'a changé? Cela n'éviterait pas le besoin de redémarrer l'hôte Web et de recharger la page, comme l'a dit dbulic ci-dessus, mais devoir attendre 1 seconde au lieu de 20 secondes pour la construction serait énorme.

Existe-t-il des plans pour résoudre ce problème en ayant une sorte de «compilation d'exécution» pour les fichiers .razor exécutés dans le navigateur, analogue à la compilation d'exécution des fichiers .cshtml qui est disponible sur le serveur? Par exemple, pour que les fichiers .razor eux-mêmes soient directement chargés dans le navigateur (au lieu des assemblys précompilés) puis compilés là-bas, puis s'ils sont modifiés sur le serveur, le fichier .razor modifié peut être rechargé dans le navigateur et recompilé là-bas? J'aime les parallèles ici avec cshtml et je me suis demandé si c'était un chemin en considération?

Ceci est prévu pour .NET 5, qui est prévu pour novembre 2020. Nous avons encore beaucoup de discussions sur l'approche que nous voulons adopter ici.

Salut @ danroth27 , une direction a-t-elle pris forme? Si rien à partager encore, est-ce que nous verrons quelque chose à Build 2020?

Salut @mrlife. Nous prévoyons de nous concentrer principalement sur la version Blazor WebAssembly de BUILD. La prise en charge du rechargement à chaud est quelque chose que nous nous attendons à examiner pour .NET 5. La direction précise de la manière dont cela sera réalisé n'a pas encore été déterminée.

Je pense beaucoup à cette question. Chaque jour, j'utilise le modèle 1. Le modèle 2 est un changement de paradigme dans la pratique par rapport au modèle 1; cela le rend moins facile à adopter par rapport à l'amélioration directe du modèle 1. J'espère que le modèle 3 est proche de ce qui est réalisable. J'ai l'impression que le modèle 4 n'est qu'aspirant basé sur les commentaires ci-dessus, cependant, après avoir vu ce qui est possible dans MAUI, le modèle 6 a l'air vraiment bien.

Motif 1 (courant hors de la boîte):

1. Enregistrer les modifications dans un nombre illimité de fichiers
2. Cliquez sur un bouton ou appuyez sur la commande clavier pour compiler
3. Actualisez le navigateur

Motif 2 ( dotnet watch run ):

1. Enregistrer les modifications dans un fichier
2. Recompilation automatique
3. Enregistrez tous les autres fichiers nécessaires et attendez des recompilations supplémentaires
4. Actualisez le navigateur

Modèle 3:

1. Enregistrer les modifications dans un nombre illimité de fichiers
2. Recompilation partielle ou non nécessaire
3. Actualisez le navigateur

Modèle 4:

1. Enregistrer les modifications dans un nombre illimité de fichiers
2. Le navigateur reflète les changements dans son état actuel

Motif 5 (comme le rechargement à chaud MAUI ):

1. Ne pas enregistrer les modifications dans un fichier
2. Le navigateur reflète les changements dans son état actuel

Qu'est-ce qui est réalisable?

Mon modèle actuel avec dotnet watch run :

1. Enregistrer les modifications apportées à tous les fichiers avec Ctrl Maj S
2. Recompilation automatique
3. Actualisation automatique du navigateur décrite ici .

Ce problème suit-il la génération / rechargement à chaud pour Blazer Server et Web Assembly, ou existe-t-il un problème distinct pour Web Assembly?

Quel est le statut à ce sujet? En utilisant actuellement https://github.com/OYIon/LiveSharp

tout cela est très inconfortable. Je ne peux pas non plus faire fonctionner la solution de contournement de la montre dotnet à partir d'un projet .dcproj aka docker-compose.J'espère que quelque chose se produira à court terme.

une grande technologie a également besoin d'un excellent outillage!

les choses sont constamment mises en évidence en rouge et l'intellisense ne fonctionne que très modestement.

Même chose ici, ma solution de contournement:

• Tuer devenv.exe
• supprimer le dossier .vs \
• Redémarrer le projet

L'outillage fonctionnera à nouveau. Faites-le plusieurs fois par jour. Avec refactoring, quelques fois par heure. Essayez de le combiner avec votre voyage à la machine à café

les choses sont constamment mises en évidence en rouge et l'intellisense ne fonctionne que très modestement.

Je sais que c'est difficile, mais avez-vous des étapes de repro pour cela? Par exemple, avez-vous du code de projet que vous pouvez partager et qui, sur une version spécifique de VS ou VS Code, produit de manière fiable une intelligence ou des erreurs incorrectes? Nous voulons vraiment localiser et résoudre tous les problèmes de ce genre.

cc @NTaylorMullen - connaissez-vous des étapes de diagnostic qui pourraient être prises ici pour nous aider à le

@SteveSandersonMS

Facile:

• Renommer un fichier de composant de rasoir existant

(les fichiers avec le même préfixe seront également renommés)

• Mettre à jour le nom de la classe dans la classe partielle

• Mettre à jour / renommer les références dans d'autres composants (fonction d'outillage manuel, très manquée)

• Construire des œuvres

• Outillage cassé

• Après avoir supprimé le dossier .\vs vs récupère

les choses sont constamment mises en évidence en rouge et l'intellisense ne fonctionne que très modestement.

Je sais que c'est difficile, mais avez-vous des étapes de repro pour cela? Par exemple, avez-vous du code de projet que vous pouvez partager et qui, sur une version spécifique de VS ou VS Code, produit de manière fiable une intelligence ou des erreurs incorrectes? Nous voulons vraiment localiser et résoudre tous les problèmes de ce genre.

cc @NTaylorMullen - connaissez-vous des étapes de diagnostic qui pourraient être prises ici pour nous aider à le

merci pour la réponse, je garderai un œil dessus. chaque type de refactoring est définitivement problématique comme JvanderStad l'a déjà donné à titre d'exemple. sinon, je ne pourrais voir aucun modèle jusqu'à présent.
Par exemple, je viens d'ouvrir un fichier de 219 lignes et j'ai 167 erreurs intellisense. règles: CS0121 CS0229 CS1503

serait-il peut-être utile de créer un problème github supplémentaire pour collecter les problèmes intellisense? ou est-ce que cela existe déjà? parce que ce problème est définitivement au mauvais endroit.

merci pour la réponse, je garderai un œil dessus. chaque type de refactoring est définitivement problématique comme JvanderStad l'a déjà donné à titre d'exemple. sinon, je ne pourrais voir aucun modèle jusqu'à présent.
Par exemple, je viens d'ouvrir un fichier de 219 lignes et j'ai 167 erreurs intellisense. règles: CS0121 CS0229 CS1503

serait-il peut-être utile de créer un problème github supplémentaire pour collecter les problèmes intellisense? ou est-ce que cela existe déjà? parce que ce problème est définitivement au mauvais endroit.

C'est presque si la base de données intellisense est corrompue / le service de langue se bloque, il persiste après le redémarrage de VS

  <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>

J'utilise rider au lieu de vs et semble très bien fonctionner. J'utilise également cet outil appelé livesharp, bien que ce ne soit pas si bon ou si fiable, il fait le travail et je peux obtenir des mises à jour de l'interface utilisateur sans avoir à recompiler.

@ cubed-it Ce PowerShell tue Visual Studio, supprime le dossier .vs \, redémarre la solution. Moins de voyages de café requis.

$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
}

Pour ceux qui veulent s'en tenir à VS, vous pouvez utiliser cette extension pour le travail ( https://marketplace.visualstudio.com/items?itemName=pragmatrix.BuildOnSave ) qui se construit automatiquement lors de l'enregistrement et ne peut être activée que pour le projet de démarrage (dans ce cas, votre projet blazor). Pour une meilleure expérience, désactivez "Lunch Browser" dans le VS afin qu'il ne ferme pas automatiquement le navigateur. Mais vous devrez appuyer sur F5 sur le navigateur :-(

Ressentez totalement toute votre douleur en ce qui concerne l'outillage Razor. Heureusement, c'est quelque chose que nous cherchons à résoudre dans le laps de temps .NET 5. Si vous souhaitez essayer cet outil (avertissement qu'il est actuellement super expérimental), vous pouvez télécharger la dernière version d'aperçu de VS et cocher la case à cocher de la fonctionnalité d'aperçu suivante (Outils -> Options -> Environnement -> Fonctionnalités d'aperçu):

Il est très probable que cela résoudra de nombreux problèmes liés à l'éditeur Razor mentionnés dans ce problème. Cela étant dit, nous savons que le nouvel éditeur présente plusieurs lacunes et même quelques mauvais bugs par rapport à l'éditeur existant, mais nous serions curieux d'entendre vos commentaires, qu'il s'agisse d'une expérience globale meilleure pour vos besoins.

télécharger la dernière version préliminaire de VS
https://visualstudio.microsoft.com/vs/preview/

@NTaylorMullen Y a-t-il un problème où je peux enregistrer des erreurs concernant l'outillage Razor? Le dernier aperçu ne fonctionne pas du tout :(

@JvanderStad Je pense que la syntaxe devrait être "@(row => ...

@JvanderStad Je pense que la syntaxe devrait être "@(row => ...

Fonctionne bien dans la version actuelle

@JvanderStad ah, si vous parlez de couleurs, c'est actuellement cassé, comme beaucoup d'autres choses

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

J'ai manqué le blog de Daniels. Je sais maintenant à quoi m'attendre. Thnx

@NTaylorMullen Y a-t-il un problème où je peux enregistrer des erreurs concernant l'outillage Razor? Le dernier aperçu ne fonctionne pas du tout :(

La colorisation sémantique Ya C # est quelque chose que nous n'avons pas encore implémenté dans le nouvel éditeur 😄

@ danroth27 Si le rechargement à chaud pour blazor wasm est délicat en raison de l'architecture, pensez-vous que le rechargement à chaud pour le serveur blazor peut faire l'affaire. L'idée est de rendre de manière transparente les composants du rasoir (à partir du projet blazor wasm) via le moteur de rendu pendant le développement en conservant toutes les vérifications de compatibilité qui garantissent le déploiement de blazor wasm et en effectuant le test final et le déploiement dans le modèle wasm réel.

existe-t-il des mises à jour pour le rechargement à chaud, serait-il disponible dans .net5 ou est-il déjà disponible dans l'aperçu?

@ qin-guan Le rechargement à chaud n'est pas prévu pour .NET 5 en raison du temps limité restant dans cette version. Nous espérons fournir une recharge à chaud pour .NET 6.

@ danroth27 ahhhh booooooo !!

Veuillez pardonner mon opinion peut-être biaisée et peut-être terriblement ignorante, mais j'ai parfois l'impression que les améliorations de la productivité passent au second plan par rapport aux améliorations de performances ( dont beaucoup de travail a été investi )

J'aimerais voir le blog sur les 250 améliorations de productivité que vous avez apportées cette version à votre outillage par exemple.
De mon point de vue personnel, si les développeurs n'obtiennent pas la chaîne d'outils productive dont ils ont besoin, ils ne pourront pas produire le logiciel assez rapidement pour battre les concurrents sur le marché, et le résultat est que leurs applications ne survivront pas. le marché pour profiter de toutes ces améliorations de performances brillantes. Donc, de ce point de vue, c'est un peu aggravant.

Cependant, j'adore l'apparence des améliorations de performance. J'espère vraiment que .NET 6 n'est pas trop loin derrière .NET 5 et que nous voyons la productivité dans Blazor commencer à rattraper d'autres frameworks!

@ qin-guan Le rechargement à chaud n'est pas prévu pour .NET 5 en raison du temps limité restant dans cette version. Nous espérons fournir une recharge à chaud pour .NET 6.

c'est tellement triste, j'attendais cette fonctionnalité pour .net5 😭😭😭

@dazinator @ buster95 Nous partageons votre déception! Le rechargement à chaud était à peu près au sommet de notre liste de choses que nous voulions faire dans .NET 5 et il est toujours près du sommet de notre backlog. À l'origine, il devait faire partie d'un effort plus large de rechargement à chaud sur .NET, mais tout cela a été transféré vers .NET 6. Bien effectuer le rechargement à chaud est un problème délicat - cela signifie trouver des moyens fiables de mettre à jour l'application en cours aussi rapidement que possible et avec une haute fidélité. Il faut juste plus de temps pour bien faire que ce que nous avions disponible dans .NET 5.

Pour la productivité des développeurs, nous sommes en train de refondre complètement l'éditeur Razor, qui devrait permettre une multitude de fonctionnalités de productivité pour le développement de Blazor (refactoring, aller à def / impl, actions de code, etc.). Nous avons rendu le nouvel éditeur disponible en tant que fonctionnalité de prévisualisation facultative pour la première fois au début du mois, et nous prévoyons d'en faire l'éditeur par défaut de Razor probablement au début de l'année prochaine.

Nous avons également un certain nombre d'autres fonctionnalités du framework Blazor à venir dans .NET 5, notamment l'isolation CSS, le chargement paresseux, la définition du focus de l'interface utilisateur, la modification de la tête HTML, le téléchargement de fichiers, le stockage protégé du navigateur, la virtualisation, etc.

@dazinator @ buster95 Nous partageons votre déception! Le rechargement à chaud était à peu près au sommet de notre liste de choses que nous voulions faire dans .NET 5 et il est toujours près du sommet de notre backlog. À l'origine, il devait faire partie d'un effort plus large de rechargement à chaud sur .NET, mais tout cela a été transféré vers .NET 6. Bien effectuer le rechargement à chaud est un problème délicat - cela signifie trouver des moyens fiables de mettre à jour l'application en cours aussi rapidement que possible et avec une haute fidélité. Il faut juste plus de temps pour bien faire que ce que nous avions disponible dans .NET 5.

Pour la productivité des développeurs, nous sommes en train de refondre complètement l'éditeur Razor, qui devrait permettre une multitude de fonctionnalités de productivité pour le développement de Blazor (refactoring, aller à def / impl, actions de code, etc.). Nous avons rendu le nouvel éditeur disponible en tant que fonctionnalité de prévisualisation facultative pour la première fois au début du mois, et nous prévoyons d'en faire l'éditeur par défaut de Razor probablement au début de l'année prochaine.

Nous avons également un certain nombre d'autres fonctionnalités du framework Blazor à venir dans .NET 5, notamment l'isolation CSS, le chargement paresseux, la définition du focus de l'interface utilisateur, la modification de la tête HTML, le téléchargement de fichiers, le stockage protégé du navigateur, la virtualisation, etc.

Est-il possible de créer une extension gratuite comme https://www.livesharp.net et d'être gratuit pour tous?

cette extension est simple à configurer mais pour l'instant j'utilise la version d'essai de 15 jours 😢

J'ai une question, le rechargement à chaud fonctionnera-t-il pour MacOS dans la mesure où il est actuellement prévu? Parce que modifier et continuer ne fonctionne pas pour le moment.

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

@wocar Oui, quelle que soit la solution que nous expédions, elle sera multiplateforme et fonctionnera sous macOS.

@ danroth27 pouvez-vous fournir une solution moins performante, mais également facile à utiliser?
Par exemple, avoir un middleware de développement avec une connexion websocket qui actualise la page après une lente reconstruction complète?

@ danroth27 pouvez-vous fournir une solution moins performante, mais également facile à utiliser?
Par exemple, avoir un middleware de développement avec une connexion websocket qui actualise la page après une lente reconstruction complète?

@xrkolovos si vous avez VS, vous pouvez utiliser ctrl-shift-b , ctrl-alt-enter (manuellement après la compilation) si BrowserLink installé: https://docs.microsoft.com/en- us / aspnet / core / côté client / using-browserlink? view = aspnetcore-3.1

pouvez-vous fournir une solution moins performante, tout en étant facile à utiliser?
Par exemple, avoir un middleware de développement avec une connexion websocket qui actualise la page après une lente reconstruction complète?

Nous travaillons à faire exactement cela avec dotnet watch pour .NET 5: https://github.com/dotnet/aspnetcore/pull/24574

@dazinator @ buster95 Nous partageons votre déception! Le rechargement à chaud était à peu près au sommet de notre liste de choses que nous voulions faire dans .NET 5 et il est toujours près du sommet de notre backlog. À l'origine, il devait faire partie d'un effort plus large de rechargement à chaud sur .NET, mais tout cela a été transféré vers .NET 6. Bien effectuer le rechargement à chaud est un problème délicat - cela signifie trouver des moyens fiables de mettre à jour l'application en cours aussi rapidement que possible et avec une haute fidélité. Il faut juste plus de temps pour bien faire que ce que nous avions disponible dans .NET 5.

@ danroth27 Le "rechargement à chaud plus large" pour .NET est-il également censé fonctionner pour les projets non Web? Et y a-t-il un problème où je pourrais suivre cela?

Nous avons déplacé ce problème vers le jalon Backlog. Cela signifie qu'il ne sera pas travaillé pour la prochaine version. Nous réévaluerons l'arriéré après la version actuelle et examinerons cet élément à ce moment-là. Pour en savoir plus sur notre processus de gestion des problèmes et pour avoir de meilleures attentes concernant différents types de problèmes, vous pouvez lire notre processus de triage .

Merci de nous avoir contacté.
Nous déplaçons ce numéro vers le jalon Next sprint planning pour une évaluation / considération future. Nous évaluerons la demande lors de la planification des travaux pour la prochaine étape. Pour en savoir plus sur ce à quoi vous attendre et comment ce problème sera traité, vous pouvez en savoir plus sur notre processus de triage ici .

Maintenant, il est disponible sur .NET5, comment puis-je l'activer?

Maintenant, il est disponible sur .NET5 comment puis-je activer

Dudeee vérifie les commentaires ci-dessus, c'était la planification de .net 6-preview 😢

@ buster95 alors qu'est-ce que le diable
Lien vers la vidéo: https://www.youtube.com/watch?v=mS6ykjdOVRg

dans 2h38mm36ss

@yasserss , à l'époque Safia Abdalla parlait du composant <Virtualize> . Vous pouvez envoyer le lien vidéo approprié à l'heure spécifiée en cliquant sur le bouton de partage de YouTube.

@BrunoBlanes désolé la voici: https://youtu.be/mS6ykjdOVRg?t=8917

Je suis presque sûr qu'il utilise dotnet watch.

Si vous regardez la vidéo en 2h: 25m: 40s, il utilise dotnet watch run pour exécuter l'application, peut-être que nous avons une amélioration dans dotnet watch run , je me souviens que la dernière fois que j'ai utilisé les performances de la montre dotnet était mauvaise. ne sais pas maintenant

Oui, nous avons travaillé dans .NET 5 pour améliorer les performances de dotnet watch . Par exemple, il est désormais plus intelligent de ne pas exécuter dotnet restore chaque fois que vous modifiez la source, et il est capable de déclencher des recharges dans le navigateur.

Ce n'est pas la vision ultime du rechargement à chaud. Nous prévoyons toujours de créer une véritable fonctionnalité de rechargement à chaud dans .NET 6, mais les améliorations de dotnet watch perf dans .NET 5 sont un pas en avant dans l'intervalle.

Nous avons également activé la prise en charge de l'actualisation automatique du navigateur dans dotnet watch et dans VS. Pour activer cette fonctionnalité dans VS, vous devez définir cette option:

Ceci est différent du rechargement à chaud, en ce que l'application est toujours en train d'être redémarrée et l'application rechargée dans le navigateur. Mais cela vous permet de vous concentrer sur l'édition du code pendant que l'outillage reconstruit et actualise le navigateur pour vous.

@ danroth27 Des nouvelles sur l'actualisation automatique avec Visual Studio pour Mac?

@mrlife, quelque chose que nous cherchons à ajouter très bientôt. FYI @jongalloway

@ danroth27

Nous avons également activé la prise en charge de l'actualisation automatique du navigateur dans dotnet watch et dans VS. Pour activer cette fonctionnalité dans VS, vous devez définir cette option:

Ceci est différent du rechargement à chaud, en ce que l'application est toujours en train d'être redémarrée et l'application rechargée dans le navigateur. Mais cela vous permet de vous concentrer sur l'édition du code pendant que l'outillage reconstruit et actualise le navigateur pour vous.

Avec cette option activée, cela devrait suffire pour avoir le débogage et le rechargement lors de l'enregistrement dans VS2019? Je veux dire, je l'ai activé avec l'option que vous avez mentionnée, et lorsque j'appuie sur F5 et que je commence le débogage et que j'apporte une modification à mon code, le navigateur ne se recharge pas. C'est le cas lorsque j'exécute dotnet watch à partir de la console du gestionnaire de packages. Comment puis-je obtenir cette fonctionnalité en appuyant simplement sur F5 pendant le débogage?

Compte tenu de l' actualisation automatique avec la section de dotnet watch soit encore disponible dans Visual Studio:

Nous espérons apporter la fonctionnalité d'actualisation automatique à Visual Studio à l'avenir.

@BrunoBlanes La prise en charge de l'actualisation automatique est désormais disponible avec Visual Studio avec la mise à jour 16.8. Il vous suffit de l'activer en utilisant l'option que j'ai indiquée ci-dessus. Je vais mettre à jour les notes de publication pour supprimer ce commentaire.

@porkopek La reconstruction automatique et l'actualisation automatique ne fonctionnent que lorsque vous n'utilisez pas le débogueur.

L'actualisation / la construction automatique ne fonctionne pas même en sélectionnant une option dans Visual Studio 2019 16.8. Parfois, j'obtiens une exception de référence nulle dans Visual Studio lorsque je sélectionne la création automatique et l'actualisation du navigateur après l'enregistrement des modifications. Y a-t-il autre chose à changer dans Visual Studio 2019 16.8 pour que cela fonctionne. @ danroth27

Je comprends que ce sera une expérience complète de .NET 6. Qu'en est-il de .NET 5 et de Blazor Webassembly actuels?

Cette option "Option de génération et d'actualisation automatique" devrait-elle également fonctionner pour les assemblys Web Blazor? Que dois-je faire de plus (que de définir cette option sur: "Auto build and refresh ..." et d'aller dans le fichier Filename.razor, changer quelque chose et CTRL + S? :) Doit-il recharger le navigateur?

Comment (ou est-il) corrélé avec le lien du navigateur?

@MussaratAziz Les informations sur ces informations de rechargement à chaud sont incomplètes et une page msdn n'est pas disponible.
Dans mon cas, j'ai dû m'en tenir au profil IIS Express et exécuter le projet sans le débogueur.
Cela a permis le rechargement à chaud ou plutôt le redémarrage à chaud, mais uniquement pour le projet Blazor Server. Je n'ai pas testé la version WASM.

J'espère vraiment que l'équipe de développement ASP Core (vous êtes génial !!) inclura cela, car modifier l'interface utilisateur sans hotreload est assez douloureux.

J'espère que ça t'as aidé :)

UTILISEZ LIVESHARP ... Je n'arrive pas à croire qu'un enfant dans son sous-sol ait réussi à faire quelque chose que Microsoft ne peut pas.

Edit: désolé ne vous méprenez pas, Microsoft a fait un travail formidable .. mais cette fonctionnalité est un must ... juste pour changer un DIV ou un attribut, c'est comme 45 secondes minimum

BTW: pour le moment, j'utilise LiveSharp. Oui, cela peut coûter cher aux amateurs et j'aimerais également voir le soutien officiel de l'équipe de Redmond.
Cependant, le produit est excellent, le support est très bon et cela fonctionne.
https://www.livesharp.net/blazor/

À votre santé!

@wocar @ChristianWeyer J'apprécie vraiment votre soutien, les gars! Mais ne minimisez pas les efforts de MS. Il est presque toujours plus facile pour un tiers de créer une solution complètement nouvelle car je ne suis responsable envers personne. Cela me permet de prendre des risques.

Quoi qu'il en soit, plus de coopération, moins antagoniste.

Non, je ne minimise pas - au contraire :-) En fin de compte, il s'agit de prix.