Aspnetcore: Hot recarregar para Blazor

Consulte https://github.com/aspnet/blazor/issues/193 para atualizações de status sobre este item de trabalho.

Por enquanto, podemos usar dotnet watch run e recompilar sempre que ocorrer a mudança.
Apenas usando isso no arquivo csproj:
<DotNetCliToolReference Include="Microsoft.DotNet.Watcher.Tools" Version="2.0.0" />
<Watch Include="**\*.cshtml"/>

Nós encontramos um obstáculo com o live reload para 0.2.0, então movendo isso até que possamos trabalhar em um design mais robusto.

Olá, estou usando o dotnet sdk 2.2.100-preview1-009349 e o blazor 0.5.1 no Mac.
Recarregar ao vivo não funciona usando "dotnet blazor serve" Se eu alterar alguma marcação html em um arquivo cshtml, o aplicativo não recarrega a si mesmo e, depois de uma recarga manual do navegador, o aplicativo exibe o conteúdo html antigo. Como posso resolver isso?

@ danroth27 , o que é https://github.com/aspnet/AspNetCore/issues/4056 então? Deve ser fechado?

Algumas perguntas!
1 Esta faixa recarrega ao vivo para o blazor do lado do servidor e para o blazor do lado do cliente?

1. O live reload será enviado na versão go live (ou seja, no net core 3.0)?
2. O mecanismo de recarregamento em tempo real perderá o estado da página (ou seja, equivalente a uma atualização f5) ou se comportará de maneira semelhante à substituição de módulo ativo em javascript - ou seja, apenas a IU de componentes alterada será renderizada novamente? Nesse último caso, haverá um mecanismo para preservar o estado do componente no cliente entre as atualizações?

Esta faixa recarrega ao vivo para o blazor do lado do servidor e para o blazor do lado do cliente?

sim

O live reload será enviado na versão go live (ou seja, no net core 3.0)?

Para o .NET Core 3.0, esperamos oferecer suporte à reconstrução automática com base nas alterações do arquivo, mas você ainda precisará atualizar o navegador manualmente.

O mecanismo de recarregamento em tempo real perderá o estado da página (ou seja, equivalente a uma atualização f5) ou se comportará de maneira semelhante à substituição de módulo ativo em javascript - ou seja, apenas a IU de componentes alterada será renderizada novamente? Nesse último caso, haverá um mecanismo para preservar o estado do componente no cliente entre as atualizações?

No momento, não temos um plano para oferecer suporte à substituição de módulos ativos de uma forma que preserve o estado do cliente.

No momento, não temos um plano para oferecer suporte à substituição de módulos ativos de uma forma que preserve o estado do cliente.

Pelo menos, não automagicamente. Teoricamente, se você seguir uma arquitetura semelhante ao Redux, ou qualquer outra coisa que desvincule estritamente o estado da tela, então você poderia serializar esse estado antes de descarregar e restaurar na recarga. No entanto, isso não é algo que estamos planejando como um recurso, já que nem todo mundo quer seguir esse tipo de arquitetura.

então você poderia serializar esse estado antes de descarregar e restaurar na recarga.

Obrigado. Por favor, quando estiver pronto, você seria capaz de documentar os ganchos apropriados (antes de descarregar / recarregar, etc.) fornecidos no projeto para facilitar isso. Gostaria de iniciar um pacote nuget de implementação / auxiliar para habilitar esse padrão para aqueles que o desejam!

Não foi possível fazer o dotnet watch run funcionar, tentei seguir e outras opções também,

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

Acabei ficando com a seguinte solução crua usando nodemon :

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

Eu pensei que deveria correr:
dotnet watch --project BlazorTest.Client run
Mas isso me deu um erro.

Se eu usasse:
dotnet watch --project BlazorTest.Server run

Com o seguinte no arquivo do projeto BlazorTest.Server.csproj:

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

Ele pegou as mudanças no projeto BlazorTest.Client e reiniciou o servidor, então eu só tive que fazer uma atualização manual no navegador.

Ele pegou as mudanças no projeto BlazorTest.Client e reiniciou o servidor, então eu só tive que fazer uma atualização manual no navegador.

Isso significa que o servidor é reiniciado sempre que houver uma alteração de css, html ?

@dazinator , sim :-)

.. ok apenas checando mas isso é uma coisa ruim né? Ou seja, a reinicialização do servidor deve ser desnecessária para uma alteração de arquivo html ou css, pois uma atualização do navegador (com o cache invalidado) deve ser suficiente?

Você está certo, isso não é necessário. Basta adicionar ou remover as extensões de arquivo nas quais você está interessado em <ItemGroup> . Atualizei minha resposta para evitar confusão.

Desculpe, se fora do tópico, há alguma maneira de atualizar em tempo real do Visual Studio agora (lado do cliente Blazor)? Agora, para cada alteração, exceto arquivos wwwroot, tenho que construir o projeto (Ctrl Shift B) e recarregar o navegador. Seria maravilhoso se o VS pudesse construir automaticamente ao salvar as alterações.

@datvm Habilitamos isso para projetos Blazor do lado do servidor, mas precisamos fazer algum trabalho para habilitá-lo novamente para projetos Blazor do lado do cliente e bibliotecas de classes do Razor. Provavelmente levará um pouco até chegarmos a esse ponto, pois estamos focados agora em lançar o .NET Core 3.0.

Para o lado do cliente, você provavelmente pode usar qualquer coisa que apenas faça uma atualização completa da página quando algo muda no servidor. Plugue sem vergonha: verifique o NetPack - execute o projeto de amostra e navegue até o exemplo / BrowserReload: https://github.com/dazinator/NetPack/blob/develop/src/NetPack.Web/Views/Home/BrowserReload.cshtml - que pode te ajudar. Caso contrário, existem outras soluções por aí para acionar uma recarga da página do lado do cliente com base nas alterações de arquivo do lado do servidor, se você não puder esperar por uma solução pronta para uso.

Obrigado pela solução, pode realmente ser útil para outra pessoa. Para mim, será apenas uma melhoria na qualidade de vida, nada crítico. Ainda amo o produto e o esforço que todos estão fazendo. O pressionamento extra de Ctrl Shift B funciona para mim (agora).

Minha solução atualmente se parece com isto:
Eu tenho um exe BlazorDebugLauncher separado que é iniciado por launchsettings.json parametrizado com a porta e o nome do host que o navegador deve ser aberto.
Isso então

• inicia um pequeno exe separado DebugAttacher que desanexa e reanexa o Visual Studio
• inicia o dotnet watch run na pasta do projeto
• atualiza o navegador assim que o processo do servidor está ativo (funciona bem com o MS Edge :-))

Se alguém estiver interessado, posso colocar isso em algum lugar ...

@AdmiralSnyder claro que ficaria interessado em ver se você quiser compartilhar!

Vale a pena conferir: https://github.com/RickStrahl/Westwind.AspnetCore.LiveReload

esta é a minha solução. um pouco hacky, mas funciona: https://github.com/AdmiralSnyder/BlazorAutoRebuildDemo
(Vou limpar e adicionar um readme na próxima semana ...)

@dazinator por acaso você deu uma olhada?

@AdmiralSnyder Eu
No entanto, decidi usar essa abordagem para recarregar o navegador (é minha própria biblioteca, sem surpresa) https://github.com/dazinator/NetPack/blob/develop/src/NetPack.Web.Blazor.Host/Startup.cs - que é executado o observador dentro do próprio aplicativo (usando IFileProvider) em vez de iniciar qualquer processo externo, e dispara uma recarga usando o sinal r e um componente do lado do cliente blazor que você adiciona ao seu layout do blazor. Tem funcionado bem para mim no preview6 e logo irei atualizar para o preview7 e espero que continue funcionando :-)

Eu não queria trazer recursos de atualização para o projeto. Como você abre a lacuna detach-rebuild-restart-reantach sem ter um processo externo?

Eu não queria trazer os recursos de atualização para o projeto

Você não precisa incluí-los no projeto em sentido estrito. Por exemplo, você pode incluir as referências do pacote com uma condição em um símbolo de compilação (ou seja, debug = true) e pode colocar o código de inicialização em uma diretiva de compilação (#if debug) - e agora, quando você executar o aplicativo no modo de lançamento, não ter os pacotes de tempo de design ou código nele.

Como você abre a lacuna detach-rebuild-restart-reantach sem ter um processo externo?

Como eu executo o projeto host do VS, ele pode reconstruir o projeto do cliente blazor referenciado conforme necessário (o netpack observa os projetos blazor IFileProvider) sem ter que parar ou se desconectar do processo host. A única vez em que há uma "lacuna" é se eu preciso fazer uma alteração de código em meu próprio aplicativo host (não no cliente Blazor). Nesse caso, espero que um dia "Editar e continuar" funcione novamente, pois isso resolverá este último problema. No entanto, sem isso, existem duas opções para minha abordagem:

1. Não use o VS para executar o host, use dotnet run watch e conecte o depurador manualmente (uma dor)
2. Pare o VS, faça a mudança para o host, inicie o Vs novamente (isso é normalmente o que eu faço)
   @AdmiralSnyder editou isto para responder melhor às suas perguntas

Estou vendo ~ 10 segundos para uma reconstrução usando dotnet watch . Existem planos para acelerar compilações incrementais? Isso é bastante doloroso ao iterar nos componentes.

Parece que grande parte do tempo é gasto construindo os componentes do barbeador, então isso significa que esses tempos de construção serão escalonados ~ linearmente? (com aplicativos mais complexos levando mais de 30 segundos para construir?)

Existem planos para acelerar compilações incrementais? Isso é bastante doloroso ao iterar nos componentes.

Se este for o Blazor do lado do cliente, considere desativar a vinculação para compilações de depuração.

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

Falei com algumas pessoas que estão confusas sobre a reconstrução e atualização automáticas.
Isso se deve principalmente ao fato de que, quando você altera o código no Visual Studio, o recurso de reconstrução automática é ativado e você também vê que "algo" está acontecendo no navegador. Esse algo é freqüentemente confundido com uma tentativa de recarga ao vivo.
Então (devido ao fato de que a conexão do sinal-r não pode se reconectar ao estado antigo) você obtém a mensagem "Falha ao reconectar ao servidor." erro. No entanto, para pessoas novas no Blazor, parece que o sistema tentou uma atualização automática, mas falhou, o que é uma experiência ruim.

Como não há ETA no recurso Live Reload, é possível não tentar uma reconexão automática se a conexão for interrompida devido a uma construção? Ou pelo menos fornecer uma mensagem de erro melhor, então em vez de "Falha ao reconectar ao servidor" algo como "Atualizar navegador"?

@chucker, obrigado pela dica para desativar o linker. Isso prejudica a construção marginalmente, mas o recarregamento subsequente do navegador é muito mais lento, pois agora baixa muito mais lixo - não tenho certeza se no geral ajudou ou não :-) mas vale a pena saber.
Se alguém estiver curioso para ver o blazor reload em ação (para blazor client / wasm) projetos, você pode executar este projeto aqui para ver o que quero dizer: https://github.com/dazinator/NetPack/blob/develop/src/NetPack .Web.Blazor.Host / Startup.cs

@Postlagerkarte Tentamos reconectar, mas como o estado do servidor desaparece quando o processo é reciclado, a reconexão falha. Fizemos alguns trabalhos neste espaço para tentar melhorar a experiência do usuário. Consulte a seção "Lógica de reconexão aprimorada para aplicativos do Blazor Server" na postagem do blog de anúncio do

@Postlagerkarte melhorou essa mensagem de erro na visualização 8

Dependendo do horizonte / linha do tempo para recarregar ao vivo, vale a pena considerar um problema separado para melhorar a velocidade de compilação? Talvez por meio de uma estratégia de cache semelhante a como funciona MVC / cshtml (acredito que apenas as visualizações que foram alteradas são recompiladas)? Há algum potencial fruto mais fácil aqui?

No momento, o tempo de ciclo de 10 segundos entre fazer uma alteração e vê-la no navegador é apenas um grande problema e é significativamente maior do que as plataformas baseadas em webpack em escala de aplicativo semelhante. E para ser claro, estou falando apenas sobre blazor do lado do servidor.

Vale a pena considerar um problema separado para melhorar a velocidade de compilação?

Sim, se você está tendo tempos de compilação lentos, registre um problema com os detalhes do seu ambiente de compilação.

Ter que recarregar todo o aplicativo cliente do blazor (baixar novamente todas as dll) quando você faz uma pequena alteração "apenas html" em um componente (por exemplo, alterar algum conteúdo html estático) ... não é muito ideal.

A equipe tem algo para rastrear melhorias nessa experiência ou devo abrir um novo problema?

@dazinator Não está muito claro no título do problema, mas estamos usando esse problema para rastrear a substituição de módulos ativos, bem como a recarga ativa. Temos muitos investimentos que planejamos fazer no período do .NET 5 nesta área.

Pessoalmente, não me importo em apertar F5 e, portanto, não considero recarregar a quente um recurso prio superior,
No entanto, para entrar no fluxo, acho crucial que o
alterar código, f5, alterar código, f5, o fluxo de trabalho de alteração de código é extremamente rápido. Por favor, trabalhe nisso primeiro :)

Nós habilitamos isso para projetos Blazor do lado do servidor, mas precisamos fazer algum trabalho para habilitar isso novamente para projetos do Blazor do lado do cliente e bibliotecas de classes do Razor. Provavelmente levará um pouco até chegarmos a esse ponto, pois estamos focados agora em lançar o .NET Core 3.0.

Pelo que pude constatar em vários problemas do GitHub, é que o live-reload só funciona no Blazor do lado do servidor que é executado sem depuração (e o desenvolvedor deve forçar a atualização da página). Isso é correto? Não consegui encontrar nenhuma documentação definitiva sobre o assunto.

O que temos agora é, na verdade, suporte de reconstrução automática para projetos ASP.NET Core, onde o VS observará o sistema de arquivos em busca de alterações e, em seguida, reconstruirá e executará novamente o projeto automaticamente. Funciona apenas quando o depurador não está anexado e para arquivos no projeto atual (projetos dependentes não são monitorados).

É possível desativar a tentativa de reconexão automática caso o motivo da perda de conexão seja uma construção? Ou talvez desabilite a reconexão automática durante o desenvolvimento? Eu só quero me livrar dessas tentativas de reconexão com falha porque elas me incomodam e pressiono F5 de qualquer maneira :)

Portanto, deve ser bastante fácil ter o VS desconectado e reconectado automaticamente, certo?

Posso obter a solução final para Live Reload para Blazor Server Apps com depuração?

@ bansalankit2601 Para ser implementado em .NET 5.0

Eu executo o observador como dotnet watch run e uso o VS para editar o código. Quando salvo, o código é recompilado e o navegador trava, dizendo que devo recarregar.

Cansei de pressionar F5 e prefiro ficar no VS enquanto ajusto as coisas, então

`` `// == UserScript ==
// @name Recarrega a página
// @namespace http://tampermonkey.net/
// @ versão 0.1
// @description tente dominar o mundo!
// @author You
// @match http: // localhost : 5000 / *
// @grant none
// == / 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 o script seja executado em http: // localhost : 5000 / *

Isso funciona para o lado do servidor: https://github.com/martasp/BlazorLiveReload

O cliente efetua ping no servidor a cada 200 ms. Quando o servidor cai devido a ser recompilado de dotnet watch run , um sinalizador é alternado, e quando o servidor volta, automaticamente F5s.

O repo não funcionou para mim, mas abri um problema com algum javascript que funciona (pelo menos para mim no 3.0)

Qual é o status de "Live reload" no momento. É compatível (sem F5 no navegador)?
Se não, há planos de lançar esse recurso?

@moemar no último standup da comunidade David Fowler diz que há planos para possivelmente a próxima versão, mas nada foi feito ainda. https://youtu.be/bBc_NTUVtbE?list=PL1rZQsJPBU2St9-Mz1Kaa7rofciyrwWVx&t=5010

Quais são as novidades sobre isso? 2,5 meses desde a última atualização ...

Também estou esperando o mesmo.

Isso está planejado para o .NET 5, que está programado para novembro de 2020. Ainda estamos tendo muitas discussões sobre a abordagem que queremos adotar aqui.

Para Blazor serverside, que tal usar o mecanismo que desconexões punho:

@dharmaturtle apresentou uma solução que busca o servidor a cada 200ms. Funciona, mas é irritante porque dispara solicitações constantemente, mesmo quando o servidor está em execução.

Se você substituir Blazor.defaultReconnectionHandler._reconnectionDisplay do cliente javascript blazor, você pode capturar as desconexões e começar a buscar o servidor e esperar que ele fique ativo novamente.

A vantagem é que você só recebe solicitações quando o servidor está desconectado.

A desvantagem é que '_reconnectionDisplay' é um membro privado e você sabe ... isso é mau.

Para atenuar, coloque o código javascript em <environment include="Development"> . Não vai sangrar no servidor de produção.

Repo completo aqui.

Acabei de mudar para esta solução há alguns minutos: https://remibou.github.io/Make-your-Blazor-development-faster/

Ele não executa ping continuamente no servidor e não recompila todo o .sln se a alteração estiver em um arquivo .html, .css ou .js; simplesmente recarrega a página, o que é ótimo.

Apenas vinculando outro exemplo aqui que é um pouco diferente das abordagens acima. Basta executar o projeto - ele não requer vigilância dotnet no projeto do cliente wasm. Ele será recarregado imediatamente se você alterar qualquer arquivo css, html ou js na pasta wwwroot do wasm do cliente. Ele será reconstruído e recarregado, se você alterar qualquer código no projeto wasm do cliente, como um arquivo de barbear, etc. Você tem o controle disso em seu startup.cs, e é por isso que isso é um pouco diferente de outras soluções. Se acontecer de você ainda usar javascript ou outros arquivos estáticos que devem ser pré-processados ​​em seu projeto, você também pode encontrar outros exemplos no mesmo repositório que podem ser úteis, como SystemJS HMR, rollup etc.

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

Fez uma biblioteca que compila componentes do razor em tempo de execução.

Em resposta, temos a substituição de módulo quente, esse recurso nos permite alterar o código e ver as alterações imediatamente em seu navegador. Podemos fazer um recurso semelhante no blazor usando o compilador Roslyn. Compilar componentes do razor em tempo de execução e servir com WebSockets em cada alteração de arquivo usando o observador de arquivo.

Como funciona

Ele usa o mecanismo de navalha versão 3 para compilar componentes para classes c #. Em seguida, usando o compilador Roslyn, compilei essas classes para o assembly. Finalmente, carreguei o componente app.razor de uma montagem com reflexão e com a biblioteca modificada do host de teste Steve Sanderson, transformei o componente em HTML simples. Para servir arquivos HTML em tempo real, usei WebSockets para ter uma comunicação full-duplex.

Como pode ser melhor

Corrigindo rotas em vez de usar / preview, isso poderia ser implementado injetando o cliente WebSocket em cada contexto de solicitação HTTP.

No Blazor web assembly, talvez possamos carregar e descarregar assemblies no navegador?

Usando dois servidores de compilação, um para visualização rápida e outro servidor com compilação de relógio dotnet para compilações reais mais longas.

No Blazor web assembly, talvez possamos carregar e descarregar assemblies no navegador?

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

@martasp

No Blazor web assembly, talvez possamos carregar e descarregar assemblies no navegador?

É uma versão mono runtime que executa aplicativos blazor wasm, mas infelizmente você não pode criar novos AppDomains (que eu saiba) e você não pode descarregar assemblies do AppDomain padrão.

Você pode realizar o carregamento lento de assemblies, que é como estou carregando dinamicamente assemblies de componentes apenas no primeiro uso (para acelerar o tempo de carregamento inicial do aplicativo), mas uma vez que eles são carregados, a única maneira de carregar uma nova versão que eu posso ver é talvez para carregar uma nova versão do mesmo assembly no mesmo AppDomain e mudar todas as referências para aquele novo - deixando o antigo lá - não tenho certeza se isso é suportado, pois ainda estou para tentar. Se você fizer em estradas; Avise-se me!

Espero que um dia possamos fazer com que o runtime .net principal seja executado no navegador, em vez de seu suporte para AssemblyLoadContexts e Assembly.Unload ()

Olá @ danroth27 ,
você viu https://www.livesharp.net/?
Ele substitui o código durante a execução .

Há uma vitrine onde ele atualiza o Blazor on-the-fly (embora seja necessário navegar para longe e voltar para a rota atual).
E também um mostruário onde até mesmo um texto de saída do console em um loop é substituído _ durante sua execução_ !

Isso está muito próximo da experiência que eu desejaria!

@warappa isso é incrível. Eu me pergunto como isso funciona! Posso pensar em alguns mecanismos possíveis para substituir métodos por proxies dinâmicos.
No entanto, funciona, parabéns ao (s) desenvolvedor (es). Também gostaria de uma experiência como esta, mas de preferência sem um servidor de desenvolvimento separado, prefiro apenas clicar em reproduzir no VS.

@dazinator LiveSharp Server serializa o código atualizado e o envia ao aplicativo. Em seguida, o aplicativo o desserializa na árvore de expressão e o injeta em métodos atualizados. Há muito mais coisas acontecendo lá dentro, mas essa é a essência.

A propósito, o LiveSharp Server precisa ser iniciado apenas uma vez. Depois disso, basta iniciar o aplicativo como de costume.

Aqui está uma demonstração do Blazor stateful hot-reload com LiveSharp: https://www.youtube.com/watch?v=MCh5-44UBpM

Isenção de responsabilidade: sou o autor do LiveSharp

@ionoy kudos, foi um bom trabalho lá!

A experiência que se desenvolveu para Blazor a partir de agora é muito dolorosa. Editar, reconstruir, atualizar, depurar ...
Ficaria feliz em pagar 9 $ por mês até que isso seja corrigido, aumentaria a produtividade em pelo menos 5x.

Ao projetar isso, leve em consideração que nem todos nós usamos o Visual Studio. obrigado

@wocar LiveSharp já é multiplataforma e não depende de nenhum IDE. Então, você poderia teoricamente usá-lo com notepad.exe

@wocar Se você não estiver usando o VS, também considere dotnet watch : https://docs.microsoft.com/en-us/aspnet/core/tutorials/dotnet-watch

@SteveSandersonMS - dotnet watch mata o estado, como você sem dúvida sabe. O LiveSharp realmente empurra as alterações sem forçar um recarregamento e, portanto, permite o ajuste fino da IU com loop de feedback instantâneo. Eu realmente gostaria que vocês implementassem algo equivalente em breve, é extremamente necessário.

Sim, claro. Eu não estava sugerindo que fosse o mesmo que LiveSharp. Apenas me certificando de que @wocar estava ciente da opção.

Obrigado. Já baixei o Livesharp e funciona muito bem, gostaria de ver algo parecido implementado.

Não me interpretem mal, vocês fizeram um trabalho incrível, no entanto, se você quiser um feedback honesto, depurar o blazor é uma dor. Eu usei o relógio dotnet e meio que funciona (é lento) e não posso depurar (pelo menos não com o Rider), tanto quanto gostaria de usar o blazor, não posso por causa da produtividade. Portanto, decidi ficar com páginas de barbear.

Obrigado.

Obrigado pelo feedback, @wocar! Eu sei que recarregar a quente é importante. É algo que desejamos muito adicionar e estamos procurando maneiras de trazê-lo para o .NET 5 em geral.

Não consigo depurar (pelo menos não com Rider)

Você já deve estar ciente, mas caso não esteja, é possível depurar de uma forma independente de IDE usando o navegador como o depurador .NET: https://docs.microsoft.com/en-us/aspnet/core /blazor/debug?view=aspnetcore-3.1#debug -in-the-browser

Você já deve estar ciente, mas caso não esteja, é possível depurar de uma forma independente de IDE usando o navegador como o depurador .NET: https://docs.microsoft.com/en-us/aspnet/core /blazor/debug?view=aspnetcore-3.1#debug -in-the-browser

Obrigado, você não estava ciente.

Se eu usar o razor pages (.cshtml) e modificar o HTML e pressionar F5, pelo menos posso ver as mudanças. Por que isso não é possível com Componentes Razor (.razor)

Eu adoraria obter um ciclo de desenvolvimento mais rápido também. Uma vez que tínhamos o hot-reload funcionando para o Vue, foi tão bom fazer uma mudança e vê-la 1,0 a 2,0 segundos depois no navegador. Agora vejo a necessidade de algo assim aqui.

dotnet watch run nos ajuda a parte do caminho aqui - haveria uma resposta intermediária mais simples, talvez alguma maneira de acelerar a construção para que seja mais rápida quando nada além de um arquivo .razor mudou? Isso não evitaria a necessidade de reiniciar o host e recarregar a página, como dbulic disse acima, mas ter que esperar 1 segundo em vez de 20 segundos para a construção seria muito grande.

Existe algum plano para resolver isso tendo uma espécie de "compilação em tempo de execução" para arquivos .razor em execução no navegador, semelhante à compilação em tempo de execução de arquivos .cshtml que está disponível no servidor? Por exemplo, para que os próprios arquivos .razor sejam carregados diretamente no navegador (em vez dos assemblies pré-compilados) e depois compilados lá, e então se forem editados no servidor, o arquivo .razor alterado pode ser recarregado no navegador e recompilado lá? Eu gosto dos paralelos aqui com cshtml e me pergunto se este é um caminho em consideração?

Isso está planejado para o .NET 5, que está programado para novembro de 2020. Ainda estamos tendo muitas discussões sobre a abordagem que queremos adotar aqui.

Olá @ danroth27 , uma direção tomou forma? Se nada para compartilhar ainda, será que veremos algo no Build 2020?

Olá, @mrlife. Esperamos nos concentrar principalmente no lançamento do Blazor WebAssembly na BUILD. O suporte para hot reload é algo que esperamos examinar para o .NET 5. A direção específica de como isso será alcançado ainda não foi determinada.

Eu penso muito sobre esse assunto. Todos os dias, eu uso o Padrão 1. O Padrão 2 é uma mudança de paradigma na prática em comparação com o Padrão 1; isso o torna menos fácil de adotar em comparação com o aprimoramento direto do Padrão 1. Espero que o Padrão 3 esteja próximo do que é possível. Eu sinto que o Padrão 4 é apenas uma aspiração com base nos comentários acima, no entanto, depois de ver o que é possível no MAUI, o Padrão 6 parece muito bom.

Padrão 1 (atual fora da caixa):

1. Salve as alterações em qualquer número de arquivos
2. Clique em um botão ou pressione o comando do teclado para compilar
3. Atualize o navegador

Padrão 2 ( dotnet watch run ):

1. Salve as alterações em um arquivo
2. Recompilação automática
3. Salve todos os outros arquivos necessários e espere por recompilações adicionais
4. Atualize o navegador

Padrão 3:

1. Salve as alterações em qualquer número de arquivos
2. Parcial ou nenhuma recompilação necessária
3. Atualize o navegador

Padrão 4:

1. Salve as alterações em qualquer número de arquivos
2. O navegador reflete as mudanças em seu estado atual

Padrão 5 (como recarga automática MAUI ):

1. Não salve as alterações em um arquivo
2. O navegador reflete as mudanças em seu estado atual

O que é alcançável?

Meu padrão atual com dotnet watch run :

1. Salve as alterações em todos os arquivos com Ctrl Shift S
2. Recompilação automática
3. A atualização automática do navegador é descrita aqui .

Este problema está rastreando a compilação / recarga ativa para o Blazer Server e o Web Assembly ou há um separado para o Web Assembly?

Qual é o status disso? Atualmente usando https://github.com/OYIon/LiveSharp

tudo isso é muito desconfortável. Também não consigo fazer com que a solução alternativa do dotnet watch funcione a partir de um projeto .dcproj também conhecido como docker-compose.Espero que algo aconteça em breve.

uma grande tecnologia também precisa de ótimas ferramentas!

as coisas são constantemente destacadas em vermelho e a intellisense só funciona modestamente.

O mesmo aqui, minha solução alternativa:

• Mate devenv.exe
• remover .vs \ pasta
• Reiniciar projeto

O ferramental funcionará novamente. Faça isso algumas vezes por dia. Com refatoração, algumas vezes por hora. Experimente combiná-lo com sua ida à máquina de café

as coisas são constantemente destacadas em vermelho e a intellisense só funciona modestamente.

Eu sei que isso é difícil, mas você tem alguma etapa de reprodução para isso? Por exemplo, você tem algum código de projeto que possa compartilhar que, em uma versão específica do VS ou do Código do VS, produz de forma confiável intellisense incorreto ou erros? Definitivamente, queremos rastrear e corrigir quaisquer problemas como esse.

cc @NTaylorMullen - você conhece alguma etapa de diagnóstico que poderia ser executada aqui para nos ajudar a rastrear isso?

@SteveSandersonMS

Fácil:

• Renomear um arquivo de componente do Razor existente

(arquivos com o mesmo prefixo também serão renomeados)

• Atualizar o nome da classe na classe parcial

• Atualizar / renomear referências em outros componentes (manual, recurso de ferramenta muito perdido)

• Construir trabalhos

• Ferramental quebrado

• Após deletar .\vs pasta vs recupera

as coisas são constantemente destacadas em vermelho e a intellisense só funciona modestamente.

Eu sei que isso é difícil, mas você tem alguma etapa de reprodução para isso? Por exemplo, você tem algum código de projeto que possa compartilhar que, em uma versão específica do VS ou do Código do VS, produz de forma confiável intellisense incorreto ou erros? Definitivamente, queremos rastrear e corrigir quaisquer problemas como esse.

cc @NTaylorMullen - você conhece alguma etapa de diagnóstico que poderia ser executada aqui para nos ajudar a rastrear isso?

obrigado pela resposta, vou ficar de olho nisso. todo tipo de refatoração é definitivamente problemático, como JvanderStad já deu como exemplo. caso contrário, não consegui ver nenhum padrão até agora.
Por exemplo, acabei de abrir um arquivo de 219 linhas e tenho 167 erros de intellisense. regras: CS0121 CS0229 CS1503

seria útil criar um problema extra no github para coletar os problemas do intellisense? ou isso já existe? porque esse problema é definitivamente o lugar errado.

obrigado pela resposta, vou ficar de olho nisso. todo tipo de refatoração é definitivamente problemático, como JvanderStad já deu como exemplo. caso contrário, não consegui ver nenhum padrão até agora.
Por exemplo, acabei de abrir um arquivo de 219 linhas e tenho 167 erros de intellisense. regras: CS0121 CS0229 CS1503

seria útil criar um problema extra no github para coletar os problemas do intellisense? ou isso já existe? porque esse problema é definitivamente o lugar errado.

É quase que se o banco de dados intellisense for corrompido / serviço de linguagem travar, ele persiste após a reinicialização do 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>

Estou usando rider em vez de vs e parece funcionar muito bem. Também estou usando uma ferramenta chamada livesharp, embora não seja tão boa ou confiável, ela faz o trabalho e posso obter atualizações de IU sem ter que recompilar.

@ cubed-it Este PowerShell mata o Visual Studio, remove a pasta .vs \ e reinicia a solução. São necessárias menos viagens para o 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 aqueles que desejam manter o VS, você pode usar esta extensão para a solução alternativa ( https://marketplace.visualstudio.com/items?itemName=pragmatrix.BuildOnSave ) que cria automaticamente ao salvar e só pode ser habilitada para iniciar o projeto (neste caso, seu projeto blazor). Para uma melhor experiência, desative o "Lunch Browser" no VS para que ele não feche o navegador automaticamente. Mas você terá que pressionar F5 no navegador :-(

Sinta totalmente toda a sua dor em relação ao ferramental Razor. Felizmente, é algo que estamos procurando resolver no período do .NET 5. Se você gostaria de experimentar esta ferramenta (avisando que é super experimental atualmente), você pode baixar a versão de visualização mais recente do VS e marcar a seguinte caixa de seleção do recurso de visualização (Ferramentas -> Opções -> Ambiente -> Recursos de visualização):

É muito provável que isso resolva muitos dos problemas do editor do Razor mencionados nesta edição. Dito isso, sabemos que o novo editor tem várias lacunas e até mesmo alguns bugs ruins em comparação com o editor existente, mas ficaríamos curiosos para ouvir seus comentários, independentemente se foi uma experiência geral melhor para suas necessidades.

baixe a versão mais recente do VS
https://visualstudio.microsoft.com/vs/preview/

@NTaylorMullen Há um problema em que posso registrar erros relacionados ao ferramental Razor? A última visualização não funciona de todo :(

@JvanderStad , acredito que a sintaxe deve ser "@(row => ...

@JvanderStad , acredito que a sintaxe deve ser "@(row => ...

Funciona bem na versão atual

@JvanderStad ah, se você está falando de cores, isso está quebrado, assim como muitas outras coisas

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

Eu perdi a postagem do blog de Daniels. Eu sei agora o que esperar. Thnx

@NTaylorMullen Há um problema em que posso registrar erros relacionados ao ferramental Razor? A última visualização não funciona de todo :(

A colorização semântica Ya C # é algo que ainda não implementamos no novo editor 😄

@ danroth27 Se o hot reload para blazor wasm for complicado devido à arquitetura, você acha que o hot-reload para o servidor blazor pode resolver o problema. A ideia é renderizar perfeitamente os componentes do razor (do projeto blazor wasm) por meio do renderizador de servidor durante o desenvolvimento, mantendo todas as verificações de compatibilidade que garantem a implantação do blazor wasm e fazer o teste de estágio final e implantação no modelo wasm real.

há alguma atualização para recarregamento a quente, estaria em .net5 ou já está na visualização?

@ qin-guan O Hot reload não está planejado para .NET 5 devido ao tempo limitado restante nessa versão. Esperamos entregar o hot reload para .NET 6.

@ danroth27 ahhhh booooooo !!

Por favor, perdoe minha opinião talvez tendenciosa e talvez lamentavelmente ignorante, mas às vezes eu sinto que as melhorias de produtividade ficam em segundo plano em relação às melhorias de desempenho ( nas quais muito trabalho foi investido )

Adoraria ver o blog sobre as 250 melhorias de produtividade que você fez neste lançamento em suas ferramentas, por exemplo.
Da minha perspectiva pessoal, se os desenvolvedores não obtiverem a cadeia produtiva de ferramentas de que precisam, eles não serão capazes de produzir o software rápido o suficiente para vencer os concorrentes no mercado, e o resultado é que seus aplicativos não sobreviverão em o mercado para colher os benefícios de todas essas melhorias de desempenho brilhantes e agradáveis. Então, dessa perspectiva, é um pouco agravante.

No entanto, adoro a aparência das melhorias de desempenho. Eu realmente espero que o .NET 6 não esteja muito atrás do .NET 5 e vejamos a produtividade no Blazor começar a se igualar a outros frameworks!

@ qin-guan O Hot reload não está planejado para .NET 5 devido ao tempo limitado restante nessa versão. Esperamos entregar o hot reload para .NET 6.

isso é tão triste, eu estava esperando esse recurso para .net5 😭😭😭

@dazinator @ buster95 Compartilhamos sua decepção! O hot reload estava praticamente no topo da nossa lista de coisas que queríamos fazer no .NET 5 e ainda está perto do topo da nossa lista de pendências. Esperava-se que fosse parte de um esforço mais amplo de hot reload em .NET, mas tudo foi enviado para .NET 6. Fazer um hot reload bem é um problema complicado - significa encontrar maneiras confiáveis ​​de atualizar o aplicativo em execução o mais rápido possível e com alta fidelidade. Só requer mais tempo para fazer bem do que tínhamos disponível no .NET 5.

Para a produtividade do desenvolvedor, estamos reformulando completamente o editor do Razor, que deve permitir uma série de recursos de produtividade para o desenvolvimento do Blazor (refatoração, vá para def / impl, ações de código, etc.). Fizemos o novo editor disponível como um recurso de visualização opcional pela primeira vez no início deste mês, e esperamos torná-lo o editor Navalha padrão provavelmente no início do próximo ano.

Também temos vários outros recursos da estrutura Blazor chegando no .NET 5, incluindo isolamento CSS, carregamento lento, definir o foco da IU, modificar o HTML Head, upload de arquivo, armazenamento de navegador protegido, virtualização, etc.

@dazinator @ buster95 Compartilhamos sua decepção! O hot reload estava praticamente no topo da nossa lista de coisas que queríamos fazer no .NET 5 e ainda está perto do topo da nossa lista de pendências. Esperava-se que fosse parte de um esforço mais amplo de hot reload em .NET, mas tudo foi enviado para .NET 6. Fazer um hot reload bem é um problema complicado - significa encontrar maneiras confiáveis ​​de atualizar o aplicativo em execução o mais rápido possível e com alta fidelidade. Só requer mais tempo para fazer bem do que tínhamos disponível no .NET 5.

Para a produtividade do desenvolvedor, estamos reformulando completamente o editor do Razor, que deve permitir uma série de recursos de produtividade para o desenvolvimento do Blazor (refatoração, vá para def / impl, ações de código, etc.). Fizemos o novo editor disponível como um recurso de visualização opcional pela primeira vez no início deste mês, e esperamos torná-lo o editor Navalha padrão provavelmente no início do próximo ano.

Também temos vários outros recursos da estrutura Blazor chegando no .NET 5, incluindo isolamento CSS, carregamento lento, definir o foco da IU, modificar o HTML Head, upload de arquivo, armazenamento de navegador protegido, virtualização, etc.

Existe a possibilidade de criar uma extensão gratuita como https://www.livesharp.net e ser gratuita para todos?

esta extensão é simples de configurar, mas por enquanto estou usando a versão de teste de 15 dias 😢

Eu tenho uma pergunta, o hot reload vai funcionar para MacOS como está planejado atualmente? Porque editar e continuar não funciona no momento.

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

@wocar Sim, qualquer solução que

@ danroth27 você pode fornecer uma solução de desempenho não tão boa, mas também fácil de trabalhar?
Por exemplo, ter um middleware de desenvolvimento com conexão de websocket que atualiza a página após uma reconstrução completa lenta?

@ danroth27 você pode fornecer uma solução de desempenho não tão boa, mas também fácil de trabalhar?
Por exemplo, ter um middleware de desenvolvimento com conexão de websocket que atualiza a página após uma reconstrução completa lenta?

@xrkolovos se você tiver VS você pode usar ctrl-shift-b , ctrl-alt-enter (manualmente após a compilação) se você tiver BrowserLink instalado: https://docs.microsoft.com/en- us / aspnet / core / client-side / using-browserlink? view = aspnetcore-3.1

você pode fornecer uma solução de desempenho não tão bom, mas também fácil de trabalhar?
Por exemplo, ter um middleware de desenvolvimento com conexão de websocket que atualiza a página após uma reconstrução completa lenta?

Estamos trabalhando para fazer exatamente isso com dotnet watch para .NET 5: https://github.com/dotnet/aspnetcore/pull/24574

@dazinator @ buster95 Compartilhamos sua decepção! O hot reload estava praticamente no topo da nossa lista de coisas que queríamos fazer no .NET 5 e ainda está perto do topo da nossa lista de pendências. Esperava-se que fosse parte de um esforço mais amplo de hot reload em .NET, mas tudo foi enviado para .NET 6. Fazer um hot reload bem é um problema complicado - significa encontrar maneiras confiáveis ​​de atualizar o aplicativo em execução o mais rápido possível e com alta fidelidade. Só requer mais tempo para fazer bem do que tínhamos disponível no .NET 5.

@ danroth27 O "reload mais amplo" para .NET também deve funcionar para projetos que não sejam da web? E há algum problema em que eu possa rastrear isso?

Mudamos esse problema para o marco Backlog. Isso significa que não será trabalhado no próximo lançamento. Iremos reavaliar o backlog após o lançamento atual e considerar este item naquele momento. Para saber mais sobre nosso processo de gerenciamento de problemas e ter uma melhor expectativa em relação aos diferentes tipos de problemas, você pode ler nosso Processo de triagem .

Obrigado por nos contatar.
Estamos movendo este problema para o marco Next sprint planning para avaliação / consideração futura. Avaliaremos a solicitação quando estivermos planejando o trabalho para a próxima etapa. Para saber mais sobre o que esperar e como esse problema será tratado, você pode ler mais sobre nosso processo de triagem aqui .

Agora está disponível no .NET5, como posso ativá-lo?

Agora está disponível em .NET5, como posso ativar

Cara, verifique os comentários acima, isso estava planejando para .net 6-preview 😢

@ buster95 então o que diabos steve sanderson fez no .NET Conf 2020 dia 1 em 2h38mm36ss para atualizar a página automática?
Link para o vídeo: https://www.youtube.com/watch?v=mS6ykjdOVRg

em 2h38mm36ss

@yasserss , naquela época Safia Abdalla estava falando sobre o componente <Virtualize> . Você pode enviar o link de vídeo adequado no horário especificado clicando no botão de compartilhamento do YouTube.

@BrunoBlanes, desculpe, aqui está: https://youtu.be/mS6ykjdOVRg?t=8917

Tenho certeza que ele está usando dotnet watch.

Se você verificar o vídeo em 2h: 25m: 40s, ele está usando dotnet watch run para executar o aplicativo, talvez tenhamos uma melhora em dotnet watch run , lembro-me da última vez que usei o dotnet, o desempenho do relógio estava ruim. não sei agora

Sim, trabalhamos no .NET 5 para melhorar o desempenho de dotnet watch . Por exemplo, agora é mais inteligente não executar dotnet restore cada vez que você faz uma alteração na fonte e é capaz de disparar recarregamentos no navegador.

Esta não é a visão definitiva para recarga a quente. Ainda planejamos fazer um verdadeiro recurso hot reload no .NET 6, mas as melhorias de dotnet watch perf no .NET 5 são um passo à frente nesse meio tempo.

Também ativamos o suporte para atualização automática do navegador em dotnet watch e no VS. Para ativar esse recurso no VS, você precisa definir esta opção:

Isso é diferente do hot reload, pois o aplicativo ainda está sendo reiniciado e o aplicativo recarregado no navegador. Mas permite que você se concentre na edição do código enquanto a ferramenta reconstrói e atualiza o navegador para você.

@ danroth27 Alguma notícia sobre atualização automática com Visual Studio para Mac?

@mrlife algo que estamos procurando para adicionar suporte em breve. FYI @jongalloway

@ danroth27

Também ativamos o suporte para atualização automática do navegador em dotnet watch e no VS. Para ativar esse recurso no VS, você precisa definir esta opção:

Isso é diferente do hot reload, pois o aplicativo ainda está sendo reiniciado e o aplicativo recarregado no navegador. Mas permite que você se concentre na edição do código enquanto a ferramenta reconstrói e atualiza o navegador para você.

Com isso habilitado deve ser suficiente ter depuração e recarregar ao salvar no VS2019? Quer dizer, eu habilitei isso com a opção que você mencionou, e quando eu pressiono F5 e começo a depurar e faço uma alteração no meu código, o navegador não recarrega. Isso ocorre quando eu executo o dotnet watch no console do gerenciador de pacotes. Como posso obter essa funcionalidade apenas pressionando F5 durante a depuração?

Dada pela seção Auto refresh with dotnet watch das notas de lançamento do ASP.NET Core 5, não acho que dotnet watch a atualização automática esteja disponível no Visual Studio ainda:

Esperamos trazer a funcionalidade de atualização automática para o Visual Studio no futuro.

@BrunoBlanes O suporte de atualização automática agora está disponível com o Visual Studio com a atualização 16.8. Você apenas tem que ativá-lo usando a opção que indiquei acima. Vou atualizar as notas de lançamento para remover esse comentário.

@porkopek A reconstrução e atualização automáticas funcionam apenas quando você não está executando o depurador.

A atualização / construção automática não está funcionando, mesmo selecionando uma opção no visual studio 2019 16.8. Às vezes, recebo exceção de referência nula no pop-up do Visual Studio quando seleciono Auto build e atualizo o navegador após salvar as alterações. há algo mais precisa ser alterado no Visual Studio 2019 16.8 para que funcione. @ danroth27

Eu entendo que será uma experiência completa no .NET 6. E quanto ao .NET 5 e ao Blazor Webassembly atuais?

Esta opção "Opção de construção e atualização automática" também deve funcionar para os conjuntos Web Blazor? O que devo fazer mais (do que definir esta opção para: "Auto build and refresh ..." e ir para o arquivo Filename.razor, alterando algo e CTRL + S? :) Deve recarregar o navegador?

Como (ou está) relacionado ao link do navegador?

@MussaratAziz As informações sobre essas informações de hot-reload estão incompletas e nem uma página do msdn está disponível.
No meu caso, tive que seguir o perfil do IIS Express e executar o projeto sem o depurador.
Isso fez com que o hot-reload ou melhor, a reinicialização a quente acontecesse, mas apenas para o projeto do Blazor Server. Não testei a versão WASM.

Eu realmente espero que o ASP Core Dev Team (você é incrível!) Inclua isso, já que ajustar a interface do usuário sem hotreload é muito doloroso.

Espero que ajude :)

USE LIVESHARP ... não consigo acreditar que uma criança em seu porão conseguiu fazer algo que a Microsoft não consegue.

Edit: desculpe, não me entenda mal, a Microsoft fez um trabalho excelente .. mas esse recurso é obrigatório ... apenas para alterar um DIV ou um atributo é como 45 segundos no mínimo

BTW: por enquanto, estou usando o LiveSharp. Sim, pode ser caro para entusiastas e também gostaria de ver o apoio oficial da equipe em Redmond.
Porém, o produto é ótimo, o suporte é muito bom e funciona.
https://www.livesharp.net/blazor/

Felicidades!

@wocar @ChristianWeyer Agradeço muito seu apoio, pessoal! Mas, por favor, não subestime os esforços da MS. Quase sempre é mais fácil para um terceiro criar uma solução completamente nova porque não sou responsável por ninguém. Isso me permite correr riscos.

De qualquer forma, mais cooperação, menos antagonismo.

Não, não estou minimizando - au contraire :-) No final das contas, é sobre prios.