Aspnetcore: Recarga en caliente para Blazor

Consulte https://github.com/aspnet/blazor/issues/193 para conocer las actualizaciones de estado de este elemento de trabajo.

Por ahora, podemos usar dotnet watch run y recompilar cada vez que ocurra el cambio.
Solo usando esto en el archivo csproj:
<DotNetCliToolReference Include="Microsoft.DotNet.Watcher.Tools" Version="2.0.0" />
<Watch Include="**\*.cshtml"/>

Hemos tenido un problema con la recarga en vivo para 0.2.0, así que muévete hasta que podamos trabajar en un diseño más robusto.

Hola, estoy usando dotnet sdk 2.2.100-preview1-009349 y blazor 0.5.1 en Mac.
La recarga en vivo no funciona con "dotnet blazor serve". Si cambio algunas marcas html en un archivo cshtml, la aplicación no se recarga sola y, después de una recarga manual del navegador, la aplicación muestra el contenido html antiguo. ¿Como puedo resolver esto?

@ danroth27 , ¿qué es https://github.com/aspnet/AspNetCore/issues/4056 entonces? ¿Debería estar cerrado?

¡Pocas preguntas!
1 ¿Realiza este seguimiento la recarga en vivo para blazor del lado del servidor y blazor del lado del cliente?

1. ¿La recarga en vivo se enviará en la versión en vivo (es decir, en net core 3.0)?
2. ¿El mecanismo de recarga en vivo perderá el estado de la página (es decir, equivalente a una actualización de F5) o se comportará de manera similar al Reemplazo de módulo en caliente en la tierra de javascript, es decir, solo se volverá a renderizar la interfaz de usuario de componentes modificada? Si es lo último, ¿habrá un mecanismo para preservar el estado del componente en el cliente entre actualizaciones?

¿Realiza este seguimiento la recarga en vivo para blazor del lado del servidor y del lado del cliente?

si

¿La recarga en vivo se enviará en la versión en vivo (es decir, en net core 3.0)?

Para .NET Core 3.0, esperamos admitir la reconstrucción automática en función de los cambios de archivo, pero aún deberá actualizar manualmente el navegador.

¿El mecanismo de recarga en vivo perderá el estado de la página (es decir, equivalente a una actualización de F5) o se comportará de manera similar al Reemplazo de módulo en caliente en la tierra de javascript, es decir, solo se volverá a renderizar la interfaz de usuario de componentes modificada? Si es lo último, ¿habrá un mecanismo para preservar el estado del componente en el cliente entre actualizaciones?

Actualmente no tenemos un plan para admitir el reemplazo de módulos en caliente de una manera que preserve el estado del cliente.

Actualmente no tenemos un plan para admitir el reemplazo de módulos en caliente de una manera que preserve el estado del cliente.

Al menos, no automágicamente. En teoría, si sigue una arquitectura similar a Redux, o cualquier otra cosa que desacople estrictamente el estado de la pantalla, entonces podría serializar ese estado antes de descargarlo y restaurarlo al volver a cargarlo. Sin embargo, esto no es algo que planeemos incorporar como característica, ya que no todos quieren seguir ese tipo de arquitectura.

entonces podría serializar ese estado antes de descargar y restaurar al recargar.

Gracias. Por favor, una vez que esté listo, podría documentar los ganchos apropiados (antes de descargar / recargar, etc.) provistos en el diseño para facilitar esto. ¡Me gustaría comenzar con un paquete nuget de implementación / ayuda para habilitar este patrón para aquellos que lo deseen!

No se pudo hacer que el dotnet watch run funcionara, intenté seguir y otras opciones también,

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

Acabo de terminar con la siguiente solución cruda usando nodemon :

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

Pensé que se suponía que debía correr:
dotnet watch --project BlazorTest.Client run
Pero eso me dio un error.

Si usé:
dotnet watch --project BlazorTest.Server run

Con lo siguiente en el archivo BlazorTest.Server.csproj del proyecto:

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

Recogió cambios en el proyecto BlazorTest.Client y reinició el servidor, por lo que solo tuve que hacer una actualización manual en el navegador.

Recogió cambios en el proyecto BlazorTest.Client y reinició el servidor, por lo que solo tuve que hacer una actualización manual en el navegador.

¿Eso significa que el servidor se reinicia cada vez que hay un cambio css, html ?

@dazinator , sí :-)

.. ok solo comprobando pero eso es algo malo ¿no? Es decir, el reinicio del servidor debería ser innecesario para un cambio de archivo html o css, ya que una actualización del navegador (con la caché invalidada) debería ser suficiente.

Tienes razón, eso no es necesario. Simplemente agregue o elimine las extensiones de archivo que le interesan dentro de <ItemGroup> . Actualicé mi respuesta para evitar confusiones.

Lo siento si no está relacionado con el tema, ¿hay alguna forma de recargar en vivo desde Visual Studio en este momento (lado del cliente Blazor)? En este momento, para cada cambio, excepto los archivos wwwroot, tengo que compilar el proyecto (Ctrl Shift B) y volver a cargar el navegador. Sería maravilloso si VS pudiera construir automáticamente al guardar cambios.

@datvm Hemos habilitado esto para proyectos Blazor del lado del servidor, pero necesitamos trabajar un poco para habilitarlo nuevamente para proyectos Blazor del lado del cliente y bibliotecas de clases Razor. Probablemente pasará un poco antes de que lleguemos a esto, ya que ahora estamos enfocados en enviar .NET Core 3.0.

Para el lado del cliente, probablemente pueda usar cualquier cosa que solo actualice la página completa cuando algo cambia en el servidor. Enchufe descarado: consulte NetPack: ejecute el proyecto de muestra y navegue hasta el ejemplo de / BrowserReload: https://github.com/dazinator/NetPack/blob/develop/src/NetPack.Web/Views/Home/BrowserReload.cshtml - que podría ayudarte. De lo contrario, existen otras soluciones para activar una recarga de la página del lado del cliente en función de los cambios del archivo del lado del servidor si no puede esperar a una solución lista para usar.

Gracias por la solución, en realidad puede ser útil para otra persona. Para mí, será solo una mejora de la calidad de vida, nada crítico. Todavía amo el producto y el esfuerzo que todos están haciendo. Presionar más Ctrl Shift B funciona para mí (ahora).

Mi solución actualmente se ve así:
Tengo un BlazorDebugLauncher exe separado que se inicia con launchsettings.json parametrizado con el puerto y el nombre de host en el que se abrirá el navegador.
Entonces

• inicia un pequeño exe DebugAttacher separado que desconecta y vuelve a conectar Visual Studio
• inicia la ejecución de dotnet watch en la carpeta del proyecto
• actualiza el navegador tan pronto como el proceso del servidor finaliza (funciona bien con MS Edge :-))

Si alguien está interesado, puedo poner esto en alguna parte ...

@AdmiralSnyder ¡ seguro que me interesaría ver eso si tienes ganas de compartir!

Vale la pena echarle un vistazo: https://github.com/RickStrahl/Westwind.AspnetCore.LiveReload

esta es mi solución. un poco hacky, pero funciona: https://github.com/AdmiralSnyder/BlazorAutoRebuildDemo
(Limpiaré y agregaré un archivo Léame la próxima semana…)

@dazinator, ¿le

@AdmiralSnyder Eché un vistazo y gracias por compartir, estaba ansioso por ver cómo / si estabas adjuntando el depurador; tengo un poco de experiencia en el desarrollo de extensiones vs que ves :-)
Sin embargo, me he decidido por este enfoque para la recarga del navegador (como era de esperar, es mi propia biblioteca) https://github.com/dazinator/NetPack/blob/develop/src/NetPack.Web.Blazor.Host/Startup.cs - que se ejecuta el observador dentro de la propia aplicación (usando IFileProvider) en lugar de iniciar cualquier proceso externo, y activa una recarga usando la señal r y un componente del lado del cliente blazor que agrega a su diseño blazor. Me ha funcionado bien en la vista previa6 y pronto lo actualizaré a la vista previa7 y espero que siga funcionando :-)

No quería incorporar las funciones refrescantes al proyecto. ¿Cómo se abre la brecha separar-reconstruir-reiniciar-volver a conectar sin tener un proceso externo?

No quería incorporar las funciones refrescantes al proyecto.

No es necesario incorporarlos al proyecto en sentido estricto. Por ejemplo, puede incluir las referencias del paquete con una condición en un símbolo de compilación (es decir, debug = true) y puede poner el código de inicio en una directiva de compilación (#if debug), y ahora, cuando ejecute la aplicación en modo de lanzamiento, no lo hará. tener los paquetes de tiempo de diseño o el código en él.

¿Cómo se abre la brecha separar-reconstruir-reiniciar-volver a conectar sin tener un proceso externo?

Debido a que ejecuto el proyecto de host desde VS, puede reconstruir el proyecto de cliente blazor al que se hace referencia según sea necesario (netpack observa los proyectos blazor IFileProvider) sin tener que detener o desconectar el proceso del host. La única vez que hay una "brecha" es si necesito hacer un cambio de código en mi aplicación de host (no en el cliente blazor). En ese caso, espero sinceramente que algún día "Editar y continuar" funcione de nuevo, ya que eso resolverá este último problema. Sin embargo, sin eso, hay dos opciones para mi enfoque:

1. No use VS para ejecutar el host, use dotnet run watch y luego adjunte el depurador manualmente (un dolor)
2. Detenga VS, realice el cambio en el host, inicie Vs nuevamente (esto es lo que normalmente hago)
   @AdmiralSnyder ha editado esto para responder mejor a sus preguntas.

Veo ~ 10 segundos para una reconstrucción usando dotnet watch . ¿Hay planes para acelerar las compilaciones incrementales? Eso es bastante doloroso cuando se itera en componentes.

Parece que gran parte del tiempo se dedica a construir los componentes de la maquinilla de afeitar, entonces, ¿eso significa que estos tiempos de construcción se escalarán ~ linealmente? (¿Las aplicaciones más complejas tardan más de 30 segundos en construirse?)

¿Hay planes para acelerar las compilaciones incrementales? Eso es bastante doloroso cuando se itera en componentes.

Si se trata de Blazor del lado del cliente, considere la posibilidad de deshabilitar el enlace para las compilaciones de depuración.

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

He hablado con algunas personas que están confundidas acerca de la reconstrucción automática y la actualización automática.
Esto se debe principalmente al hecho de que cuando cambia el código en Visual Studio, la función de reconstrucción automática se activa y también ve que "algo" está sucediendo en el navegador. Este algo a menudo se confunde con un intento de recarga en vivo.
Luego (debido al hecho de que la conexión signal-r no puede volver a conectarse al estado anterior) aparece el mensaje "No se pudo volver a conectar al servidor". error. Sin embargo, para las personas nuevas en Blazor, parece que el sistema ha intentado una actualización automática y falla al hacerlo, lo que es una mala experiencia.

Dado que no hay ETA en la función Live Reload, ¿es posible no intentar una reconexión automática si la conexión se rompió debido a una compilación? O al menos dar un mensaje de error mejor, así que en lugar de "No se pudo volver a conectar al servidor", ¿algo como "Actualizar navegador"?

@chucker gracias por la sugerencia de desactivación del enlazador. Eso aumenta la compilación marginalmente, pero luego la recarga posterior del navegador es mucho más lenta, ya que ahora descarga mucha más basura. No estoy seguro de si en general ha ayudado o no :-) pero vale la pena saberlo.
Si alguien tiene curiosidad por ver blazor reload en acción (para blazor client / wasm) proyectos, puede ejecutar este proyecto aquí para ver lo que quiero decir: https://github.com/dazinator/NetPack/blob/develop/src/NetPack .Web.Blazor.Host / Startup.cs

@Postlagerkarte Intentamos reconectarnos, pero como el estado del servidor desaparece cuando se recicla el proceso, la reconexión falla. Hemos trabajado un poco en este espacio para intentar mejorar la experiencia del usuario. Consulte la sección "Lógica de reconexión mejorada para aplicaciones de Blazor Server" en la publicación del blog del anuncio de Preview 8 .

@Postlagerkarte mejoró ese mensaje de error en la vista previa8

Dependiendo del horizonte / línea de tiempo para la recarga en vivo, ¿vale la pena considerar un tema separado para mejorar la velocidad de compilación? ¿Quizás a través de una estrategia de almacenamiento en caché similar a cómo funciona MVC / cshtml (creo que solo se vuelven a compilar las vistas que han cambiado)? ¿Hay alguna fruta potencial que esté madura aquí?

En este momento, el tiempo de ciclo de 10 segundos entre hacer un cambio y verlo en el navegador es simplemente un gran problema, y ​​es significativamente mayor que las plataformas basadas en paquetes web a una escala de aplicación similar. Y para ser claros, solo estoy hablando de blazor del lado del servidor aquí.

¿Vale la pena considerar otro tema para mejorar la velocidad de compilación?

Sí, si observa tiempos de compilación lentos, presente un problema con los detalles de su entorno de compilación.

Tener que volver a cargar toda la aplicación cliente blazor (volver a descargar todos los dll) cuando realiza un cambio menor "sólo html" en un componente (por ejemplo, cambiar algún contenido html estático) no es ... muy óptimo.

¿Tiene el equipo algo para realizar un seguimiento de las mejoras en esa experiencia o debería abrir una nueva edición?

@dazinator No está muy claro por el título del problema, pero estamos usando este problema para rastrear el reemplazo del módulo en caliente y la recarga en vivo. Tenemos un montón de inversiones que planeamos hacer en el marco de tiempo de .NET 5 en esta área.

Personalmente, no me importa presionar F5 y, por lo tanto, no considero la recarga en caliente como una de las funciones principales,
Sin embargo, para entrar en el flujo, encuentro crucial que el
cambiar código, f5, cambiar código, f5, cambiar código, el flujo de trabajo es increíble (juego de palabras) rápido. Primero trabaja en eso :)

Hemos habilitado esto para proyectos Blazor del lado del servidor, pero necesitamos trabajar un poco para habilitarlo nuevamente para proyectos Blazor del lado del cliente y bibliotecas de clases Razor. Probablemente pasará un poco antes de que lleguemos a esto, ya que ahora estamos enfocados en enviar .NET Core 3.0.

De lo que he podido recopilar de varios problemas de GitHub es que la recarga en vivo solo funciona en Blazor del lado del servidor que se ejecuta sin depurar (y el desarrollador debe forzar la actualización de la página). ¿Es eso correcto? No pude encontrar ninguna documentación definitiva sobre el tema.

Lo que tenemos ahora es realmente soporte de reconstrucción automática para proyectos ASP.NET Core, donde VS observará los cambios en el sistema de archivos y luego reconstruirá y ejecutará automáticamente el proyecto. Solo funciona cuando el depurador no está adjunto y para los archivos del proyecto actual (los proyectos dependientes no se ven).

¿Es posible deshabilitar el intento de reconexión automática en caso de que el motivo de la pérdida de conexión sea una compilación? ¿O tal vez deshabilite la reconexión automática durante el desarrollo? Solo quiero deshacerme de esos intentos fallidos de reconexión porque me molestan y presiono F5 de todos modos :)

Entonces, debería ser bastante fácil que VS se separe y se vuelva a conectar automáticamente, ¿verdad?

¿Puedo obtener la solución final para Live Reloading para Blazor Server Apps con depuración?

@ bansalankit2601 Para ser implementado en .NET 5.0

Ejecuto el observador como dotnet watch run y uso VS para editar el código. Cuando guardo, el código se vuelve a compilar y el navegador se bloquea, diciéndome que debería volver a cargar.

Me cansé de presionar F5 y prefiero quedarme en VS mientras ajusta las cosas, así que TamperMonkey al rescate:

`` `// == UserScript ==
// @name Recargar la página
// @ espacio de nombres http://tampermonkey.net/
// @version 0.1
// @description ¡ intenta conquistar el mundo!
// @autor usted
// @match http: // localhost : 5000 / *
// @grant ninguno
// == / 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);

''
Permita que el script se ejecute en http: // localhost : 5000 / *

Esto funciona para el lado del servidor: https://github.com/martasp/BlazorLiveReload

El cliente hace ping al servidor cada 200 ms. Cuando el servidor deja de funcionar debido a que se ha vuelto a compilar desde dotnet watch run , se activa un indicador y, cuando el servidor vuelve, automáticamente F5.

El repositorio no funcionó para mí, pero abrí un problema con un javascript que sí funciona (al menos para mí en 3.0)

¿Cuál es el estado de "Recarga en vivo" en este momento? ¿Es compatible (sin F5 en el navegador)?
Si no es así, ¿hay planes para lanzar esta función?

@moemar en el último https://youtu.be/bBc_NTUVtbE?list=PL1rZQsJPBU2St9-Mz1Kaa7rofciyrwWVx&t=5010

¿Qué es lo último en esto? 2,5 meses desde la última actualización ...

También estoy esperando lo mismo.

Esto está planeado para .NET 5, que está programado para noviembre de 2020. Todavía estamos teniendo muchas discusiones sobre qué enfoque queremos tomar aquí.

Para el lado del servidor de Blazor , ¿qué pasa con el uso del mecanismo que maneja las desconexiones?

@dharmaturtle presentó una solución que recupera el servidor cada 200 ms. Funciona pero es molesto porque constantemente dispara solicitudes incluso cuando el servidor se ejecuta.

Si anula Blazor.defaultReconnectionHandler._reconnectionDisplay del cliente javascript blazor, puede detectar desconexiones y comenzar a buscar el servidor y esperar a que vuelva a estar activo.

La ventaja es que solo tiene solicitudes cuando el servidor está desconectado.

El inconveniente es que '_reconnectionDisplay' es un miembro privado y sabes ... esto es malo.

Como mitigación, incluya el código javascript en <environment include="Development"> . No sangrará en el servidor de producción.

Repo completo aquí.

Acabo de cambiar a esta solución hace unos minutos: https://remibou.github.io/Make-your-Blazor-development-faster/

No hace ping continuamente al servidor y no vuelve a compilar el .sln completo si el cambio está en un archivo .html, .css o .js; simplemente recarga la página, lo cual es genial.

Simplemente vinculando otro ejemplo aquí que es un poco diferente de los enfoques anteriores. Simplemente ejecute el proyecto, no requiere supervisión de dotnet en el proyecto wasm del cliente. Se recargará inmediatamente si cambia cualquier archivo css, html o js en la carpeta wwwroot del cliente wasm. Se reconstruirá y luego se volverá a cargar, si cambia cualquier código en el proyecto wasm del cliente como un archivo de afeitar, etc. Usted tiene el control de esto en su startup.cs, por lo que es un poco diferente a otras soluciones. Si también sigue utilizando javascript u otros archivos estáticos que deben procesarse previamente en su proyecto, también puede encontrar otros ejemplos en el mismo repositorio que podrían ser útiles, como SystemJS HMR, rollup, etc.

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

Hizo una biblioteca que compila los componentes de la maquinilla de afeitar en tiempo de ejecución.

En reaccionar tenemos reemplazo de módulo en caliente, esta función nos permite cambiar el código y ver los cambios inmediatamente en su navegador. Podemos hacer una característica similar en blazor usando el compilador Roslyn. Compila los componentes de la maquinilla de afeitar en tiempo de ejecución y sirve con WebSockets en cada cambio de archivo utilizando el observador de archivos.

Cómo funciona

Utiliza la versión 3 del motor razor para compilar componentes en clases C #. Luego, usando el compilador Roslyn, compilé esas clases para ensamblar. Finalmente, cargué el componente app.razor de un ensamblaje con reflexión y con la biblioteca modificada del host de prueba de Steve Sanderson convertí el componente en HTML simple. Para servir archivos HTML en tiempo real, utilicé WebSockets para tener una comunicación full-duplex.

Como puede ser mejor

Arreglando rutas en lugar de usar / preview, esto podría implementarse inyectando el cliente WebSocket en cada contexto de solicitud HTTP.

En el ensamblaje web de Blazor, ¿tal vez podamos cargar y descargar ensamblajes en el navegador?

Usando dos servidores de compilación, uno para una vista previa rápida y otro servidor con compilación de dotnet watch para compilaciones reales más largas.

En el ensamblaje web de Blazor, ¿tal vez podamos cargar y descargar ensamblajes en el navegador?

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

@martasp

En el ensamblaje web de Blazor, ¿tal vez podamos cargar y descargar ensamblajes en el navegador?

Es una versión de mono runtime que ejecuta aplicaciones blazor wasm, pero desafortunadamente no puede crear nuevos AppDomains (que yo sepa) y no puede descargar ensamblados del AppDomain predeterminado.

Puede cargar ensamblajes de forma diferida, que es como actualmente estoy cargando ensamblajes de componentes dinámicamente solo en el primer uso (para acelerar el tiempo de carga inicial de la aplicación), pero una vez que se cargan, la única forma de cargar una nueva versión que puedo ver es para cargar una nueva versión del mismo ensamblado en el mismo AppDomain y cambiar todas las referencias a esa nueva, dejando la anterior allí, no estoy seguro de si es compatible, ya que aún no lo he probado. Si lo hace en carreteras; ¡Házmelo saber!

Espero que algún día podamos ejecutar .net core runtime en el navegador con su soporte para AssemblyLoadContexts y Assembly.Unload ()

Hola @ danroth27 ,
¿has visto https://www.livesharp.net/?
Reemplaza el código mientras se está ejecutando .

Hay un escaparate donde actualiza Blazor sobre la marcha (aunque es necesario alejarse y regresar a la ruta actual).
¡Y también un escaparate donde incluso el texto de salida de una reemplaza _ mientras está en ejecución_ !

¡Esto está muy cerca de la experiencia que desearía!

@warappa eso es increíble. ¡Me pregunto cómo funciona! Puedo pensar en algunos posibles mecanismos que reemplazan los métodos con proxies dinámicos.
Sin embargo, funciona, felicitaciones a los desarrolladores. También me gustaría una experiencia como esta, pero preferiblemente sin un servidor de desarrollo separado, preferiría simplemente hacer clic en reproducir en VS.

@dazinator LiveSharp Server serializa el código actualizado y lo envía a la aplicación. Luego, la aplicación lo deserializa en Expression Tree y lo inyecta en métodos actualizados. Hay mucho más en el interior, pero esa es la esencia.

Por cierto, LiveSharp Server solo debe iniciarse una vez. Después de eso, simplemente inicie la aplicación como lo hace habitualmente.

Aquí hay una demostración de la recarga en caliente de Blazor con estado con LiveSharp: https://www.youtube.com/watch?v=MCh5-44UBpM

Descargo de responsabilidad: soy el autor de LiveSharp

@ionoy felicitaciones, ¡es un buen trabajo!

La experiencia que se está desarrollando para Blazor a partir de ahora es muy dolorosa. Edite, reconstruya, actualice, depure ...
Con mucho gusto pagaría 9 $ por mes hasta que esto se solucione, aumentaría la productividad al menos 5 veces.

Al diseñar esto, tenga en cuenta que no todos usamos Visual Studio. Gracias

@wocar LiveSharp ya es multiplataforma y no depende de ningún IDE. Entonces, teóricamente, podrías usarlo con notepad.exe

@wocar Si no está usando VS, considere también dotnet watch : https://docs.microsoft.com/en-us/aspnet/core/tutorials/dotnet-watch

@SteveSandersonMS - dotnet watch mata al estado, como sin duda sabe. LiveSharp en realidad impulsa los cambios sin forzar una recarga y, por lo tanto, permite un ajuste fino de la interfaz de usuario con un bucle de retroalimentación instantánea. Realmente deseo que ustedes implementen algo equivalente pronto, es muy necesario.

Sí, por supuesto. No estaba sugiriendo que sea lo mismo que LiveSharp. Solo asegurándome de que @wocar estuviera al tanto de la opción.

Gracias. Ya descargué Livesharp y funciona muy bien, me gustaría ver algo así implementado.

No me malinterpreten, ustedes han hecho un trabajo increíble, sin embargo, si quieren comentarios honestos, depurar Blazor es una molestia. He usado dotnet watch y funciona un poco (es lento) y no puedo depurar (al menos no con Rider), así que por mucho que me gustaría usar blazor, no puedo debido a productivit. Así que decidí quedarme con páginas navajas.

Gracias.

¡Gracias por los comentarios, @wocar! Sé que la recarga en caliente es importante. Es algo que queremos agregar y estamos buscando formas de llevarlo a .NET 5 en general.

No puedo depurar (al menos no con Rider)

Es posible que ya lo sepa, pero por si acaso no, es posible depurar de una manera independiente de IDE utilizando el navegador como depurador de .NET: https://docs.microsoft.com/en-us/aspnet/core /blazor/debug?view=aspnetcore-3.1#debug -in-the-browser

Es posible que ya lo sepa, pero por si acaso no, es posible depurar de una manera independiente de IDE utilizando el navegador como depurador de .NET: https://docs.microsoft.com/en-us/aspnet/core /blazor/debug?view=aspnetcore-3.1#debug -in-the-browser

Gracias no estaba al tanto.

Si utilizo páginas de afeitar (.cshtml) y modifico el HTML y presiono F5, al menos puedo ver los cambios. Por qué esto no es posible con Razor Components (.razor)

También me encantaría tener un ciclo de desarrollo más rápido. Una vez que tuvimos la recarga en caliente funcionando para Vue, fue muy agradable hacer un cambio y verlo 1.0-2.0 segundos más tarde en el navegador. Ahora veo la necesidad de algo así aquí.

dotnet watch run nos lleva parte del camino aquí: ¿habría una respuesta intermedia más simple, quizás alguna forma de acelerar la compilación para que sea más rápida cuando nada más que un archivo .razor ha cambiado? No evitaría la necesidad de reiniciar el servidor web y volver a cargar la página, como dbulic dijo anteriormente, pero tener que esperar 1 segundo en lugar de 20 segundos para la compilación sería grande.

¿Hay algún plan para solucionar este problema teniendo una especie de "compilación en tiempo de ejecución" para los archivos .razor que se ejecutan en el navegador, análoga a la compilación en tiempo de ejecución de los archivos .cshtml que está disponible en el servidor? Por ejemplo, para que los archivos .razor se carguen directamente en el navegador (en lugar de los ensamblajes precompilados) y luego se compilen allí, y luego, si se editan en el servidor, el archivo .razor modificado se puede volver a cargar en el navegador y volver a compilar allí. Me gustan los paralelos aquí con cshtml y me pregunto si esta es una ruta en consideración.

Esto está planeado para .NET 5, que está programado para noviembre de 2020. Todavía estamos teniendo muchas discusiones sobre qué enfoque queremos tomar aquí.

Hola @ danroth27 , ¿ha tomado forma una dirección? Si no hay nada que compartir todavía, ¿es posible que veamos algo en Build 2020?

Hola @mrlife. Esperamos centrarnos principalmente en el lanzamiento de Blazor WebAssembly en BUILD. El soporte para la recarga en caliente es algo que esperamos tener en cuenta para .NET 5. La dirección específica de cómo se logrará esto aún no se ha determinado.

Pienso mucho en este tema. Todos los días, utilizo el Patrón 1. El Patrón 2 es un cambio de paradigma en la práctica en comparación con el Patrón 1; esto hace que sea menos fácil de adoptar en comparación con la mejora directa del Patrón 1. Espero que el Patrón 3 esté cerca de lo que se puede lograr. Siento que el Patrón 4 es solo una aspiración basado en los comentarios anteriores, sin embargo, después de ver lo que es posible en MAUI, el Patrón 6 se ve muy bien.

Patrón 1 (actual fuera de la caja):

1. Guarde los cambios en cualquier número de archivos
2. Haga clic en un botón o presione el comando del teclado para compilar
3. Actualizar el navegador

Patrón 2 ( dotnet watch run ):

1. Guardar cambios en un archivo
2. Recompilación automática
3. Guarde cualquier otro archivo necesario y espere recompilaciones adicionales
4. Actualizar el navegador

Patrón 3:

1. Guarde los cambios en cualquier número de archivos
2. Se necesita recompilación parcial o no
3. Actualizar el navegador

Patrón 4:

1. Guarde los cambios en cualquier número de archivos
2. El navegador refleja los cambios en su estado actual

Patrón 5 (como recarga en caliente MAUI ):

1. No guarde los cambios en un archivo
2. El navegador refleja los cambios en su estado actual

¿Qué es alcanzable?

Mi patrón actual con dotnet watch run :

1. Guarde los cambios en todos los archivos con Ctrl Shift S
2. Recompilación automática
3. La actualización automática del navegador se describe aquí .

¿Este problema está rastreando la compilación / recarga en caliente para Blazer Server y Web Assembly, o hay uno separado para Web Assembly?

¿Cuál es el estado de esto? Actualmente usando https://github.com/OYIon/LiveSharp

todo esto es muy incómodo. Tampoco puedo hacer que la solución de dotnet watch funcione desde un proyecto
Actualmente es un dolor de cabeza trabajar con blazor desde mi punto de vista. sin actualización en vivo, las cosas se resaltan constantemente en rojo e intellisense solo funciona de manera muy modesta.

¡la gran tecnología también necesita excelentes herramientas!

las cosas se resaltan constantemente en rojo e intellisense solo funciona de manera muy modesta.

Lo mismo aquí, mi solución:

• Mata a devenv.exe
• eliminar carpeta .vs \
• Reiniciar proyecto

Las herramientas funcionarán de nuevo. Haga esto un par de veces al día. Con refactorización, un par de veces por hora. Prueba a combinarlo con tu viaje a la máquina de café.

las cosas se resaltan constantemente en rojo e intellisense solo funciona de manera muy modesta.

Sé que esto es difícil, pero ¿tiene algún paso de reproducción para esto? Por ejemplo, ¿tiene algún código de proyecto que pueda compartir y que, en una versión específica de VS o VS Code, produzca de manera confiable intellisense incorrecto o errores? Definitivamente queremos rastrear y solucionar cualquier problema como ese.

cc @NTaylorMullen - ¿Conoce algún paso de diagnóstico que podría tomarse aquí para ayudarnos a rastrear esto?

@SteveSandersonMS

Fácil:

• Cambiar el nombre de un archivo de componente de afeitadora existente

(los archivos con el mismo prefijo también cambiarán de nombre)

• Actualizar el nombre de la clase en la clase parcial

• Actualizar / cambiar el nombre de las referencias en otros componentes (manual, función de herramientas muy perdida)

• Construir obras

• Herramientas rotas

• Después de eliminar .\vs carpeta vs recupera

las cosas se resaltan constantemente en rojo e intellisense solo funciona de manera muy modesta.

Sé que esto es difícil, pero ¿tiene algún paso de reproducción para esto? Por ejemplo, ¿tiene algún código de proyecto que pueda compartir y que, en una versión específica de VS o VS Code, produzca de manera confiable intellisense incorrecto o errores? Definitivamente queremos rastrear y solucionar cualquier problema como ese.

cc @NTaylorMullen - ¿Conoce algún paso de diagnóstico que podría tomarse aquí para ayudarnos a rastrear esto?

gracias por la respuesta, lo vigilaré. todo tipo de refactorización es definitivamente problemático, como JvanderStad ya dio como ejemplo. de lo contrario, no pude ver ningún patrón hasta ahora.
por ejemplo, acabo de abrir un archivo de 219 líneas y obtuve 167 errores de intellisense. reglas: CS0121 CS0229 CS1503

¿Quizás sería útil crear un problema de github adicional para recopilar los problemas de intellisense? o esto ya existe? porque este problema es definitivamente el lugar equivocado.

gracias por la respuesta, lo vigilaré. todo tipo de refactorización es definitivamente problemático, como JvanderStad ya dio como ejemplo. de lo contrario, no pude ver ningún patrón hasta ahora.
por ejemplo, acabo de abrir un archivo de 219 líneas y obtuve 167 errores de intellisense. reglas: CS0121 CS0229 CS1503

¿Quizás sería útil crear un problema de github adicional para recopilar los problemas de intellisense? o esto ya existe? porque este problema es definitivamente el lugar equivocado.

Es casi si el intellisense db se corrompe / el servicio de idioma falla, persiste después de reiniciar 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>

Estoy usando rider en lugar de vs y parece funcionar muy bien. También estoy usando esta herramienta llamada livesharp, aunque no es tan buena ni tan confiable, hace el trabajo y puedo obtener actualizaciones de la interfaz de usuario sin tener que volver a compilar.

@ cubed-it Este PowerShell mata Visual Studio, elimina la carpeta .vs \, reinicia la solución. Se requieren menos viajes de café.

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

Para aquellos que quieran quedarse con VS, pueden usar esta extensión para el trabajo ( https://marketplace.visualstudio.com/items?itemName=pragmatrix.BuildOnSave ) que se basa automáticamente en guardar y solo se puede habilitar para el proyecto de inicio (este caso su proyecto blazor). Para una mejor experiencia, desactive "Lunch Browser" en el VS para que no cierre el navegador automáticamente. Pero tendrás que presionar F5 en el navegador :-(

Sienta totalmente todo su dolor con respecto a las herramientas de Razor. Afortunadamente, es algo que buscamos abordar en el marco de tiempo de .NET 5. Si desea probar esta herramienta (advirtiendo que es súper experimental actualmente), puede descargar la última versión de vista previa de VS y marcar la siguiente casilla de verificación de la función de vista previa (Herramientas -> Opciones -> Entorno -> Funciones de vista previa):

Es muy probable que se resuelvan muchos de los problemas del editor de Razor mencionados en este número. Dicho esto, sabemos que el nuevo editor tiene varias lagunas e incluso algunos errores graves en comparación con el editor existente, pero nos gustaría escuchar sus comentarios, independientemente de si fue una mejor experiencia general para sus necesidades.

descargue la última versión de vista previa de VS
https://visualstudio.microsoft.com/vs/preview/

@NTaylorMullen ¿Existe

@JvanderStad Creo que la sintaxis debería ser "@(row => ...

@JvanderStad Creo que la sintaxis debería ser "@(row => ...

Funciona bien en la versión actual

@JvanderStad ah, si estás hablando de colores, actualmente eso está roto, como muchas otras cosas

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

Me perdí la publicación de blog de Daniels. Ahora sé qué esperar. Thnx

@NTaylorMullen ¿Existe

La coloración semántica de Ya C # es algo que aún no hemos implementado en el nuevo editor 😄

@ danroth27 Si la recarga en caliente para blazor wasm es complicada debido a la arquitectura, ¿cree que la recarga en caliente para blazor server puede ser la solución? La idea es renderizar sin problemas los componentes de razor (del proyecto blazor wasm) a través del servidor-renderizador durante el desarrollo, manteniendo todas las comprobaciones de compatibilidad que garantizan la implementación de blazor wasm y realizar la prueba de etapa final y la implementación en el modelo wasm real.

¿Hay actualizaciones para la recarga en caliente, estaría disponible en .net5 o ya está disponible en la vista previa?

@ qin-guan La recarga en caliente no está prevista para .NET 5 debido al tiempo limitado que queda en esa versión. Esperamos ofrecer una recarga en caliente para .NET 6.

@ danroth27 ahhhh booooooo !!

Por favor, perdone mi opinión tal vez sesgada y tal vez lamentablemente ignorante, pero a veces siento que las mejoras de productividad pasan a un segundo plano frente a las mejoras de rendimiento ( en las que se ha invertido mucho trabajo )

Me encantaría ver el blog sobre las 250 mejoras de productividad que ha realizado en esta versión para sus herramientas, por ejemplo.
Desde mi perspectiva personal, si los desarrolladores no obtienen la cadena de herramientas productiva que necesitan, no podrán producir el software lo suficientemente rápido como para vencer a los competidores en el mercado, y el resultado es que sus aplicaciones no sobrevivirán en el mercado para aprovechar todas esas bonitas y brillantes mejoras de rendimiento. Entonces, desde esa perspectiva, es un poco irritante.

Sin embargo, me encanta el aspecto de las mejoras de rendimiento ... ¡Realmente espero que .NET 6 no se quede muy atrás de .NET 5 y veamos que la productividad en Blazor comienza a ponerse al día con otros marcos!

@ qin-guan La recarga en caliente no está prevista para .NET 5 debido al tiempo limitado que queda en esa versión. Esperamos ofrecer una recarga en caliente para .NET 6.

eso es tan triste, estaba esperando esta función para .net5 😭😭😭

@dazinator @ buster95 ¡Compartimos tu decepción! La recarga en caliente estaba prácticamente en la parte superior de nuestra lista de cosas que queríamos hacer en .NET 5 y todavía está cerca de la parte superior de nuestro trabajo pendiente. Originalmente, se esperaba que fuera parte de un esfuerzo más amplio de recarga en caliente en .NET, pero todo se envió a .NET 6. Hacer bien la recarga en caliente es un problema complicado: significa encontrar formas confiables de actualizar la aplicación en ejecución tan rápido como posible y con alta fidelidad. Solo requiere más tiempo para hacerlo bien del que teníamos disponible en .NET 5.

Para la productividad del desarrollador, estamos renovando completamente el editor de Razor, que debería habilitar una gran cantidad de funciones de productividad para el desarrollo de Blazor (refactorización, ir a def / impl, acciones de código, etc.). Hicimos que el nuevo editor estuviera disponible como una función de vista previa opcional por primera vez a principios de este mes, y esperamos convertirlo en el editor predeterminado de Razor probablemente a principios del próximo año.

También tenemos una serie de otras características del marco Blazor que vienen en .NET 5, incluido el aislamiento de CSS, la carga diferida, establecer el enfoque de la interfaz de usuario, modificar HTML Head, cargar archivos, almacenamiento protegido del navegador, virtualización, etc.

@dazinator @ buster95 ¡Compartimos tu decepción! La recarga en caliente estaba prácticamente en la parte superior de nuestra lista de cosas que queríamos hacer en .NET 5 y todavía está cerca de la parte superior de nuestro trabajo pendiente. Originalmente, se esperaba que fuera parte de un esfuerzo más amplio de recarga en caliente en .NET, pero todo se envió a .NET 6. Hacer bien la recarga en caliente es un problema complicado: significa encontrar formas confiables de actualizar la aplicación en ejecución tan rápido como posible y con alta fidelidad. Solo requiere más tiempo para hacerlo bien del que teníamos disponible en .NET 5.

Para la productividad del desarrollador, estamos renovando completamente el editor de Razor, que debería habilitar una gran cantidad de funciones de productividad para el desarrollo de Blazor (refactorización, ir a def / impl, acciones de código, etc.). Hicimos que el nuevo editor estuviera disponible como una función de vista previa opcional por primera vez a principios de este mes, y esperamos convertirlo en el editor predeterminado de Razor probablemente a principios del próximo año.

También tenemos una serie de otras características del marco Blazor que vienen en .NET 5, incluido el aislamiento de CSS, la carga diferida, establecer el enfoque de la interfaz de usuario, modificar HTML Head, cargar archivos, almacenamiento protegido del navegador, virtualización, etc.

¿Existe la posibilidad de crear una extensión gratuita como https://www.livesharp.net y ser gratuito para todos?

esta extensión es simple de configurar pero por ahora estoy usando la versión de prueba de 15 días 😢

Tengo una pregunta, ¿la recarga en caliente funcionará para MacOS como está planeado actualmente? Porque editar y continuar no funciona a partir de ahora.

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

@wocar Sí, cualquier solución que enviemos será multiplataforma y funcionará en macOS.

@ danroth27 ¿ puede proporcionar una solución que no funcione tan bien y que además sea fácil de trabajar?
Por ejemplo, ¿tiene un middleware de desarrollo con conexión websocket que actualice la página después de una reconstrucción completa lenta?

@ danroth27 ¿ puede proporcionar una solución que no funcione tan bien y que además sea fácil de trabajar?
Por ejemplo, ¿tiene un middleware de desarrollo con conexión websocket que actualice la página después de una reconstrucción completa lenta?

@xrkolovos si tiene VS puede usar ctrl-shift-b , ctrl-alt-enter (manualmente después de la compilación) si tiene BrowserLink instalado: https://docs.microsoft.com/en- us / aspnet / core / client-side / using-browserlink? view = aspnetcore-3.1

¿Puede proporcionar una solución que no funcione tan bien y que también sea fácil de trabajar?
Por ejemplo, ¿tiene un middleware de desarrollo con conexión websocket que actualice la página después de una reconstrucción completa lenta?

Estamos trabajando para hacer exactamente eso con dotnet watch para .NET 5: https://github.com/dotnet/aspnetcore/pull/24574

@dazinator @ buster95 ¡Compartimos tu decepción! La recarga en caliente estaba prácticamente en la parte superior de nuestra lista de cosas que queríamos hacer en .NET 5 y todavía está cerca de la parte superior de nuestro trabajo pendiente. Originalmente, se esperaba que fuera parte de un esfuerzo más amplio de recarga en caliente en .NET, pero todo se envió a .NET 6. Hacer bien la recarga en caliente es un problema complicado: significa encontrar formas confiables de actualizar la aplicación en ejecución tan rápido como posible y con alta fidelidad. Solo requiere más tiempo para hacerlo bien del que teníamos disponible en .NET 5.

@ danroth27 ¿Se

Hemos movido este problema al hito de Backlog. Esto significa que no se trabajará en él para la próxima versión. Reevaluaremos el trabajo pendiente después de la versión actual y consideraremos este elemento en ese momento. Para obtener más información sobre nuestro proceso de gestión de problemas y tener mejores expectativas con respecto a los diferentes tipos de problemas, puede leer nuestro Proceso de clasificación .

Gracias por contactarnos.
Estamos moviendo este problema al hito Next sprint planning para una evaluación / consideración futura. Evaluaremos la solicitud cuando estemos planificando el trabajo para el próximo hito. Para obtener más información sobre qué esperar a continuación y cómo se manejará este problema, puede leer más sobre nuestro proceso de clasificación aquí .

Ahora está disponible en .NET5, ¿cómo puedo activarlo?

Ahora está disponible en .NET5, ¿cómo puedo activarlo?

Amigo, verifique los comentarios de arriba, esto estaba planeando para .net 6-preview 😢

@ buster95 entonces, ¿qué diablos hizo Steve Sanderson en .NET Conf 2020 día 1 en 2h38mm36ss para actualizar la página automáticamente?
Enlace al video: https://www.youtube.com/watch?v=mS6ykjdOVRg

en 2h38mm36ss

@yasserss , en ese momento Safia Abdalla estaba hablando del componente <Virtualize> . Puede enviar el enlace de video adecuado a la hora especificada haciendo clic en el botón Compartir de YouTube.

@BrunoBlanes lo siento, aquí está: https://youtu.be/mS6ykjdOVRg?t=8917

Estoy bastante seguro de que está usando dotnet watch.

Si miras el video en 2h: 25m: 40s, él está usando dotnet watch run para ejecutar la aplicación, tal vez tengamos una mejora en dotnet watch run , recuerdo que la última vez que usé el rendimiento del reloj dotnet fue malo. no lo se ahora

Sí, trabajamos en .NET 5 para mejorar el rendimiento de dotnet watch . Por ejemplo, ahora es más inteligente no ejecutar dotnet restore cada vez que realiza un cambio de fuente, y puede activar recargas en el navegador.

Esta no es la visión definitiva para la recarga en caliente. Todavía planeamos hacer una verdadera característica de recarga en caliente en .NET 6, pero las mejoras dotnet watch perf en .NET 5 son un paso adelante mientras tanto.

También habilitamos la compatibilidad con la actualización automática del navegador tanto en dotnet watch como en VS. Para activar esta función en VS, debe configurar esta opción:

Esto es diferente de la recarga en caliente, ya que la aplicación aún se reinicia y la aplicación se vuelve a cargar en el navegador. Pero le permite concentrarse en editar el código mientras las herramientas reconstruyen y actualizan el navegador por usted.

@ danroth27 ¿ Alguna novedad sobre la actualización automática con Visual Studio para Mac?

@mrlife es algo para lo que estamos buscando agregar soporte muy pronto. FYI @jongalloway

@ danroth27

También habilitamos la compatibilidad con la actualización automática del navegador tanto en dotnet watch como en VS. Para activar esta función en VS, debe configurar esta opción:

Esto es diferente de la recarga en caliente, ya que la aplicación aún se reinicia y la aplicación se vuelve a cargar en el navegador. Pero le permite concentrarse en editar el código mientras las herramientas reconstruyen y actualizan el navegador por usted.

Con esto habilitado, ¿debería ser suficiente para depurar y recargar al guardar en VS2019? Quiero decir, tengo esto habilitado con la opción que mencionaste, y cuando presiono F5 y comienzo a depurar y hago un cambio en mi código, el navegador no se recarga. Sin embargo, lo hace cuando ejecuto dotnet watch desde la consola del administrador de paquetes. ¿Cómo puedo lograr esta funcionalidad simplemente presionando F5 mientras depuro?

Dado por la sección de actualización automática con dotnet watch de las notas de la versión de ASP.NET Core 5, no creo que la actualización automática dotnet watch esté disponible todavía en Visual Studio:

Esperamos llevar la funcionalidad de actualización automática a Visual Studio en el futuro.

@BrunoBlanes El soporte de actualización automática ahora está disponible con Visual Studio con la actualización 16.8. Solo tienes que encenderlo usando la opción que señalé anteriormente. Actualizaré las notas de la versión para eliminar ese comentario.

@porkopek La reconstrucción automática y la actualización automática solo funcionan cuando no se está ejecutando con el depurador.

La actualización / compilación automática no funciona ni siquiera al seleccionar una opción en Visual Studio 2019 16.8. A veces obtengo una excepción de referencia nula en la ventana emergente de Visual Studio cuando selecciono Auto construir y actualizar el navegador después de guardar los cambios. ¿Hay algo más que deba cambiarse en Visual Studio 2019 16.8 para que funcione? @ danroth27

Entiendo que será una experiencia completa en .NET 6. ¿Qué pasa con .NET 5 actual y Blazor Webassembly?

¿Esta opción "Opción de actualización y creación automática" también debería funcionar para Blazor Webassemblies? ¿Qué debo hacer más (que configurar esta opción en: "Auto construir y actualizar ..." e ir al archivo Filename.razor, cambiar algo y CTRL + S? :) ¿Debería recargar el navegador?

¿Cómo (o está) correlacionado con el enlace del navegador?

@MussaratAziz La información sobre esta información de recarga en caliente está incompleta ni hay una página de msdn disponible.
En mi caso, tuve que ceñirme al perfil de IIS Express y ejecutar el proyecto sin el depurador.
Esto hizo que se realizara la recarga en caliente o, más bien, el reinicio en caliente, pero solo para el proyecto Blazor Server. No he probado la versión WASM.

Realmente espero que ASP Core Dev Team (¡eres increíble!) Incluya esto, ya que ajustar la interfaz de usuario sin hotreload es bastante doloroso.

Espero que ayude :)

USE LIVESHARP ... no puedo creer que un niño en su sótano haya logrado hacer algo que Microsoft no puede.

Editar: lo siento, no me malinterpretes, Microsoft ha hecho un trabajo excelente ... pero esta característica es imprescindible ... solo para cambiar un DIV o un atributo es como mínimo 45 segundos

Por cierto: por el momento, estoy usando LiveSharp. Sí, puede ser caro para los aficionados y también me gustaría ver el apoyo oficial del equipo en Redmond.
Sin embargo, el producto es excelente, el soporte es muy bueno y simplemente funciona.
https://www.livesharp.net/blazor/

¡Salud!

@wocar @ChristianWeyer ¡ Realmente aprecio su apoyo, muchachos! Pero, por favor, no minimice los esfuerzos de la EM. Casi siempre es más fácil para un tercero crear una solución completamente nueva porque no soy responsable ante nadie. Esto me permite correr riesgos.

De todos modos, más cooperación, menos antagonismo.

No, no estoy minimizando - au contraire :-) Al final, se trata de prios.