Aspnetcore: Горячая перезагрузка для Blazor

См. Https://github.com/aspnet/blazor/issues/193 для обновлений статуса этого рабочего элемента.

На данный момент мы можем использовать dotnet watch run и перекомпилировать каждый раз, когда происходит изменение.
Просто используя это в файле csproj:
<DotNetCliToolReference Include="Microsoft.DotNet.Watcher.Tools" Version="2.0.0" />
<Watch Include="**\*.cshtml"/>

У нас возникла проблема с живой перезагрузкой 0.2.0, поэтому убираем ее, пока не сможем разработать более надежную конструкцию.

Привет, я использую dotnet sdk 2.2.100-preview1-009349 и blazor 0.5.1 под Mac.
Живая перезагрузка не работает с использованием «dotnet blazor serve». Если я изменю некоторую разметку html в файле cshtml, приложение не перезагрузится, и после ручной перезагрузки браузера приложение отобразит старое содержимое html. Как я могу это решить?

@ danroth27 , а что тогда https://github.com/aspnet/AspNetCore/issues/4056 ? Следует ли его закрыть?

Несколько вопросов!
1 Отслеживает ли эта прямая перезагрузка как блейзер на стороне сервера, так и блейзер на стороне клиента?

1. Будет ли выпущена live-перезагрузка в действующей версии (т.е. в net core 3.0)?
2. Потеряет ли механизм живой перезагрузки состояние страницы (т.е. эквивалентно обновлению f5) или он будет вести себя аналогично горячей замене модуля в javascript land - то есть будет повторно отображаться только измененный пользовательский интерфейс компонентов? В последнем случае будет ли механизм сохранения состояния компонентов на клиенте между обновлениями?

Отслеживает ли эта прямая перезагрузка как блейзер на стороне сервера, так и блейзер на стороне клиента?

да

Будет ли выпущена live-перезагрузка в действующей версии (т.е. в net core 3.0)?

Мы ожидаем, что для .NET Core 3.0 будет поддерживаться автоматическая перестройка на основе изменений файлов, но вам все равно придется вручную обновлять браузер.

Потеряет ли механизм живой перезагрузки состояние страницы (т.е. эквивалентно обновлению f5) или он будет вести себя аналогично горячей замене модуля в javascript land - то есть будет повторно отображаться только измененный пользовательский интерфейс компонентов? В последнем случае будет ли механизм сохранения состояния компонентов на клиенте между обновлениями?

В настоящее время у нас нет плана поддержки горячей замены модуля таким образом, чтобы сохранить состояние клиента.

В настоящее время у нас нет плана поддержки горячей замены модуля таким образом, чтобы сохранить состояние клиента.

По крайней мере, не автоматически. Теоретически, если вы следуете архитектуре, подобной Redux, или чему-либо еще, что строго отделяет состояние от отображения, вы можете сериализовать это состояние перед выгрузкой и восстановить при перезагрузке. Однако это не то, что мы планируем использовать в качестве функции, поскольку не все хотят следовать такой архитектуре.

тогда вы можете сериализовать это состояние перед выгрузкой и восстановить при перезагрузке.

Благодарю. Как только вы будете готовы, сможете ли вы задокументировать соответствующие крючки (перед выгрузкой / перезагрузкой и т. Д.), Предусмотренные в проекте, чтобы облегчить это. Я хотел бы начать с пакета Nuget для реализации / помощника, чтобы включить этот шаблон для тех, кто этого хочет!

Не удалось заставить dotnet watch run работать, пробовал следовать и другие варианты,

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

Только что получил следующее грубое решение с использованием nodemon :

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

Я думал, что должен бежать:
dotnet watch --project BlazorTest.Client run
Но это дало мне ошибку.

Если бы я использовал:
dotnet watch --project BlazorTest.Server run

Со следующим в файле проекта BlazorTest.Server.csproj:

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

Он уловил изменения в проекте BlazorTest.Client и перезапустил сервер, поэтому мне нужно было только вручную обновить браузер.

Он уловил изменения в проекте BlazorTest.Client и перезапустил сервер, поэтому мне нужно было только вручную обновить браузер.

Означает ли это, что сервер перезагружается каждый раз при изменении css, html ?

@dazinator , да :-)

.. хорошо, просто проверяю, но это плохо, правда? Т.е. перезапуск сервера не должен быть необходим для изменения файла html или css, поскольку обновление браузера (с недействительным кешем) должно быть достаточным?

Вы правы, в этом нет необходимости. Просто добавьте или удалите интересующие вас расширения файлов в <ItemGroup> . Обновил свой ответ, чтобы избежать путаницы.

Извините, если не по теме, есть ли возможность прямо сейчас перезагрузить Visual Studio (на стороне клиента Blazor)? Прямо сейчас для каждого изменения, за исключением файлов wwwroot, мне нужно создать проект (Ctrl Shift B) и перезагрузить браузер. Было бы замечательно, если бы VS могла автоматически строить с сохранением изменений.

@datvm Мы включили это для серверных проектов Blazor, но нам нужно проделать некоторую работу, чтобы снова включить это для клиентских проектов Blazor и библиотек классов Razor. Пройдет немного времени, прежде чем мы доберемся до этого, поскольку сейчас мы сосредоточены на выпуске .NET Core 3.0.

На стороне клиента вы, вероятно, можете использовать что-нибудь, что просто выполняет полное обновление страницы, когда что-то изменяется на сервере. Бесстыдный плагин: проверьте NetPack - запустите образец проекта и перейдите к примеру / BrowserReload: https://github.com/dazinator/NetPack/blob/develop/src/NetPack.Web/Views/Home/BrowserReload.cshtml - это может вам помочь. Если нет, существуют другие решения для запуска перезагрузки страницы на стороне клиента на основе изменений файлов на стороне сервера, если вы не можете дождаться готового решения.

Спасибо за решение, может быть, кому-то еще пригодится. Для меня это будет просто улучшение качества жизни, ничего критичного. По-прежнему люблю продукт и усилия, которые все прилагают. Дополнительное нажатие Ctrl Shift B у меня работает (сейчас).

В настоящее время мое решение выглядит так:
У меня есть отдельный исполняемый файл BlazorDebugLauncher, который запускается с помощью launchsettings.json, параметризованного с помощью порта и имени хоста, которые необходимо открыть в браузере.
Тогда это

• запускает отдельный небольшой исполняемый файл DebugAttacher, который отключает и повторно подключает Visual Studio
• запускает dotnet watch run в папке проекта
• обновляет браузер, как только серверный процесс запускается (отлично работает с MS Edge :-))

Если кому интересно, могу куда-нибудь положить ...

@AdmiralSnyder, конечно, мне было бы интересно увидеть это, если вы захотите поделиться!

Стоит проверить: https://github.com/RickStrahl/Westwind.AspnetCore.LiveReload

это мое решение. немного хакерский, но работает: https://github.com/AdmiralSnyder/BlazorAutoRebuildDemo
(Я уберу и добавлю readme на следующей неделе ...)

@dazinator вы случайно не посмотрели?

@AdmiralSnyder Я посмотрел и спасибо за то, что поделился, мне было очень интересно узнать, как / прикрепляете ли вы отладчик - у меня есть немного опыта разработки расширений, которую вы видите :-)
Я остановился на этом подходе для перезагрузки браузера (неудивительно, что это моя собственная библиотека) https://github.com/dazinator/NetPack/blob/develop/src/NetPack.Web.Blazor.Host/Startup.cs - который запускает наблюдатель внутри самого приложения (с использованием IFileProvider), а не запускает какие-либо внешние процессы, и он запускает перезагрузку с использованием сигнала r и клиентского компонента Blazor, который вы добавляете в свой макет blazor. У меня все хорошо работает в preview6, и я скоро перейду на preview7 и надеюсь, что он продолжит работать :-)

Я не хотел привносить в проект освежающие функции. Как устранить разрыв отсоединения-восстановления-перезапуска-повторного подключения без внешнего процесса?

Я не хотел привносить в проект освежающие функции

В строгом смысле слова их не обязательно вводить в проект. Например, вы можете включить ссылки на пакеты с условием для символа компиляции (т.е. debug = true), и вы можете поместить код запуска в директиву компиляции (#if debug) - и теперь, когда вы запускаете приложение в режиме выпуска, вы не будете иметь в нем пакеты времени разработки или код.

Как устранить разрыв отсоединения-восстановления-перезапуска-повторного подключения без внешнего процесса?

Поскольку я запускаю основной проект из VS, он может при необходимости перестроить указанный клиентский проект Blazor (netpack наблюдает за проектами Blazor IFileProvider) без необходимости останавливаться или отключаться от хост-процесса. Единственный раз, когда возникает «пробел», - это когда мне нужно внести изменения в код самого хост-приложения (а не в клиенте Blazor). В таком случае - я очень надеюсь, что однажды «Редактировать и продолжить» снова заработает, поскольку это решит эту последнюю проблему. Однако без этого у меня есть два варианта подхода:

1. Не используйте VS для запуска хоста, используйте dotnet run watch а затем прикрепите отладчик вручную (боль)
2. Остановите VS, внесите изменения в хост, снова запустите Vs (обычно это то, что я делаю)
   @AdmiralSnyder отредактировал это, чтобы, надеюсь, лучше ответить на ваши вопросы

Я вижу ~ 10 секунд для восстановления с использованием dotnet watch . Есть ли планы по ускорению инкрементальных сборок? Это довольно болезненно при итерации компонентов.

Похоже, что большая часть времени уходит на сборку компонентов бритвы, значит ли это, что время сборки будет масштабироваться ~ линейно? (для создания более сложных приложений требуется 30+ секунд?)

Есть ли планы по ускорению инкрементальных сборок? Это довольно болезненно при итерации компонентов.

Если это клиентский Blazor, рассмотрите возможность отключения связывания для сборок отладки.

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

Я разговаривал с несколькими людьми, которые не понимают, что такое автоматическое восстановление и автоматическое обновление.
В основном это связано с тем, что при изменении кода в Visual Studio срабатывает функция автоперестроения, и вы также видите, что «что-то» происходит в браузере. Это часто принимают за попытку перезагрузки в реальном времени.
Затем (из-за того, что соединение signal-r не может повторно подключиться к старому состоянию) вы получите сообщение «Не удалось повторно подключиться к серверу». ошибка. Однако для людей, плохо знакомых с Blazor, похоже, что система пробовала автоматическое обновление, но это не удается, что является плохим опытом.

Поскольку для функции Live Reload нет ETA, можно ли не пробовать автоматическое переподключение, если соединение прервалось из-за сборки? Или, по крайней мере, дать лучшее сообщение об ошибке, чтобы вместо «Не удалось повторно подключиться к серверу» что-то вроде «Обновить браузер»?

@chucker благодарит за
Если кому-то интересно увидеть перезагрузку Blazor в действии (для проектов Blazor client / wasm), вы можете запустить этот проект здесь, чтобы понять, что я имею в виду: https://github.com/dazinator/NetPack/blob/develop/src/NetPack .Web.Blazor.Host / Startup.cs

@Postlagerkarte Мы пытаемся восстановить соединение, но, поскольку состояние сервера исчезло, когда процесс перезапускается, повторное подключение не удается. Мы проделали некоторую работу в этой области, чтобы попытаться улучшить взаимодействие с пользователем. См. Раздел «Улучшенная логика повторного подключения для приложений Blazor Server» в сообщении блога с анонсом Preview 8 .

@Postlagerkarte улучшил это сообщение об ошибке в preview8

В зависимости от горизонта / временной шкалы для живой перезагрузки, стоит ли рассматривать отдельный вопрос для повышения скорости компиляции? Возможно, с помощью стратегии кеширования, аналогичной тому, как работает MVC / cshtml (я считаю, что только представления, которые изменились, перекомпилируются)? Есть ли здесь потенциально низко висящие фрукты?

Прямо сейчас 10-секундный цикл между внесением изменения и его просмотром в браузере - это действительно большая проблема, и она значительно больше, чем у платформ на основе веб-пакетов при аналогичном масштабе приложений. И для ясности, я говорю здесь только о блейзере на стороне сервера.

Стоит ли рассматривать отдельный вопрос для повышения скорости компиляции?

Да, если вы наблюдаете медленное время сборки, сообщите о проблеме с подробностями о вашей среде сборки.

Необходимость перезагружать все клиентское приложение Blazor (повторно загружать все библиотеки DLL), когда вы вносите в компонент незначительное изменение "только HTML" (например, изменяете некоторый статический HTML-контент) ... не очень оптимально.

Есть ли у команды что-нибудь, чтобы отслеживать улучшения в этом опыте, или мне следует открыть новую проблему?

@dazinator Из

Лично я не против нажать F5 и, следовательно, не считаю горячую перезагрузку главной приоритетной функцией,
Однако, чтобы войти в поток, я считаю важным, чтобы
изменить код, f5, изменить код, f5, рабочий процесс смены кода идет быстро (каламбур). Пожалуйста, сначала поработайте над этим :)

Мы включили это для серверных проектов Blazor, но нам нужно поработать, чтобы снова включить это для клиентских проектов Blazor и библиотек классов Razor. Пройдет немного времени, прежде чем мы доберемся до этого, поскольку сейчас мы сосредоточены на выпуске .NET Core 3.0.

Из различных проблем с GitHub мне удалось выяснить, что live-reload работает только на серверном Blazor, который запускается без отладки (и разработчик должен принудительно обновить страницу). Это правильно? Я не смог найти какой-либо исчерпывающей документации по этому поводу.

Сейчас у нас действительно есть поддержка автоматического перестроения для проектов ASP.NET Core, где VS будет отслеживать изменения в файловой системе, а затем автоматически перестраивать и перезапускать проект. Это работает только тогда, когда отладчик не прикреплен и для файлов в текущем проекте (зависимые проекты не просматриваются).

Можно ли отключить попытку автопереподключения, если причиной потери соединения была сборка? А может вообще отключить автопереподключение при разработке? Я просто хочу избавиться от этих неудачных попыток повторного подключения, потому что они меня беспокоят, и я все равно нажимаю F5 :)

Значит, должно быть довольно легко автоматически отсоединять и повторно подключать VS, не так ли?

Могу ли я получить окончательное решение для Live Reloading for Blazor Server Apps с отладкой?

@ bansalankit2601 Будет реализовано в .NET 5.0

Я запускаю наблюдателя как dotnet watch run и использую VS для редактирования кода. Когда я сохраняю, код перекомпилируется, и браузер блокируется, сообщая мне, что я должен перезагрузить.

Я устал нажимать F5 и предпочитаю оставаться в VS, пока настраиваю вещи, поэтому TamperMonkey мне на помощь:

`` // == UserScript ==
// @name Перезагрузить страницу
// @ пространство имен http://tampermonkey.net/
// @ версия 0.1
// @description пытается захватить мир!
// @author Вы
// @ соответствие 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);

``
Разрешить запуск скрипта на http: // localhost : 5000 / *

Это работает на стороне сервера: https://github.com/martasp/BlazorLiveReload

Клиент проверяет сервер каждые 200 мс. Когда сервер выходит из строя из- dotnet watch run перекомпиляции из

Репо у меня не сработало, но я открыл проблему с некоторым javascript, который действительно работает (по крайней мере, для меня на 3.0)

Какой сейчас статус "Живая перезагрузка". Поддерживается ли оно (без F5 в браузере)?
Если нет, есть ли планы по выпуску этой функции?

@moemar в последнем выпуск, возможно, в следующей версии, но пока ничего не сделано. https://youtu.be/bBc_NTUVtbE?list=PL1rZQsJPBU2St9-Mz1Kaa7rofciyrwWVx&t=5010

Что нового по этому поводу? 2,5 месяца с момента последнего обновления ...

Я тоже жду того же.

Это запланировано на .NET 5, которое запланировано на ноябрь 2020 года. Мы все еще много обсуждаем, какой подход мы хотим здесь использовать.

Для Blazor ServerSide, что об использовании механизма , который ручка отключений:

@dharmaturtle представила решение, которое загружает сервер каждые 200 мс. Это работает, но это раздражает, потому что он постоянно запускает запросы, даже когда сервер работает.

Если вы переопределите Blazor.defaultReconnectionHandler._reconnectionDisplay из клиента javascript blazor, вы можете поймать разъединения и начать извлекать сервер и ждать, пока он снова станет активным.

Преимущество в том, что у вас есть запросы только тогда, когда сервер отключен.

Недостатком является то, что _reconnectionDisplay является закрытым участником, и вы знаете ... это зло.

В качестве меры предосторожности заключите код javascript в <environment include="Development"> . Он не будет истекать кровью на рабочем сервере.

Полное репо здесь.

Я просто перешел на это решение несколько минут назад: https://remibou.github.io/Make-your-Blazor-development-faster/

Он не выполняет постоянную проверку связи с сервером и не перекомпилирует весь .sln, если изменение находится в файле .html, .css или .js; он просто перезагружает страницу, и это здорово.

Просто привяжите здесь еще один пример, который немного отличается от приведенных выше подходов. Просто запустите проект - он не требует наблюдения dotnet в клиентском проекте wasm. Он немедленно перезагрузится, если вы измените любой файл css, html или js в папке wwwroot клиентского wasm. Он будет перестроен, а затем перезагружен, если вы измените какой-либо код в клиентском проекте wasm, например, файл бритвы и т. Д. Вы можете контролировать это в своем startup.cs, поэтому это немного отличается от других решений. Если вы также все еще используете javascript или другие статические файлы, которые должны быть предварительно обработаны в вашем проекте, вы также можете найти другие примеры в том же репозитории, которые могут быть полезны, такие как SystemJS HMR, rollup и т. Д.

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

Сделал библиотеку, которая компилирует компоненты бритвы во время выполнения.

В ответ у нас есть горячая замена модуля, эта функция позволяет нам изменять код и сразу видеть изменения в вашем браузере. Мы можем сделать аналогичную функцию в Blazor, используя компилятор Roslyn. Компиляция компонентов razor во время выполнения и обслуживание с помощью WebSockets при каждом изменении файла с помощью наблюдателя файлов.

Как это устроено

Он использует движок бритвы версии 3 для компиляции компонентов в классы C #. Затем с помощью компилятора Roslyn я скомпилировал эти классы в сборку. Наконец, я загрузил компонент app.razor из сборки с отражением и с помощью модифицированной библиотеки Стива Сандерсона Test я превратил компонент в простой HTML. Чтобы обслуживать файлы HTML в реальном времени, я использовал WebSockets для полнодуплексной связи.

Как может быть лучше

Исправление маршрутов вместо использования / preview может быть реализовано путем внедрения клиента WebSocket в каждый контекст HTTP-запроса.

Может быть, в веб-сборке Blazor мы можем загружать и выгружать сборки в браузере?

Использование двух серверов сборки: один для быстрого предварительного просмотра, а другой сервер со сборкой dotnet watch для действительно более длинных сборок.

Может быть, в веб-сборке Blazor мы можем загружать и выгружать сборки в браузере?

Источник: https://github.com/martasp/BlazorLiveReload

@martasp

Может быть, в веб-сборке Blazor мы можем загружать и выгружать сборки в браузере?

Это версия моно-среды выполнения, выполняющая приложения blazor wasm, но, к сожалению, вы не можете создавать новые домены приложений (насколько мне известно), и вы не можете выгружать сборки из домена приложений по умолчанию.

Вы можете отложить загрузку сборок, именно так я в настоящее время динамически загружаю сборки компонентов только при первом использовании (для ускорения начальной загрузки приложения), но после их загрузки единственный способ загрузить новую версию, которую я вижу, это, возможно, чтобы загрузить новую версию той же сборки в тот же домен приложений и переключить все ссылки на эту новую, оставив там старую - не уверен, поддерживается ли она, поскольку я еще не пробовал ее. Если вы делаете на дорогах; дай мне знать!

Я надеюсь, что однажды мы сможем запустить в браузере базовую среду выполнения .net с ее поддержкой AssemblyLoadContexts и Assembly.Unload ()

Привет @ danroth27!
вы видели https://www.livesharp.net/?
Он заменяет код во время его работы .

Есть витрина, где он обновляет Blazor на лету (хотя нужно уйти и вернуться к текущему маршруту).
А также витрина, где даже текст консольного вывода в цикле заменяется _ во время его работы_ !

Это очень близко к опыту, которого я бы хотел!

@warappa , это
Однако это работает, спасибо разработчикам. Я также хотел бы получить такой опыт, но желательно без отдельного сервера разработки, я бы предпочел просто нажать кнопку воспроизведения в VS.

@dazinator LiveSharp Server сериализует обновленный код и отправляет его в приложение. Затем приложение десериализует его в дерево выражений и внедряет в обновленные методы. Внутри происходит гораздо больше, но в этом суть.

Кстати, LiveSharp Server нужно запускать только один раз. После этого вы просто запускаете приложение, как обычно.

Вот демонстрация горячей перезагрузки Blazor с отслеживанием состояния с помощью LiveSharp: https://www.youtube.com/watch?v=MCh5-44UBpM

Отказ от ответственности: я автор LiveSharp

@ionoy kudos,

Опыт, который сейчас развивается у Blazor, очень болезненный. Редактировать, перестраивать, обновлять, отлаживать ...
С радостью заплатил бы 9 долларов в месяц, пока это не будет исправлено, повысило бы производительность как минимум в 5 раз.

При разработке учитывайте, что не все из нас используют Visual Studio. благодаря

@wocar LiveSharp уже является кроссплатформенным и не зависит от какой-либо IDE. Так что теоретически вы можете использовать его с notepad.exe

@wocar Если вы не используете VS, также подумайте о dotnet watch : https://docs.microsoft.com/en-us/aspnet/core/tutorials/dotnet-watch

@SteveSandersonMS - dotnet watch убивает государство, как вы, несомненно, знаете. LiveSharp фактически подталкивает изменения без принудительной перезагрузки, что позволяет точно настроить пользовательский интерфейс с мгновенной обратной связью. Я действительно хочу, чтобы вы, ребята, в ближайшее время реализовали что-то эквивалентное, это крайне необходимо.

Да, конечно. Я не предполагал, что это то же самое, что и LiveSharp. Просто убедитесь, что @wocar знает об этой опции.

Благодарю. Уже скачал Livesharp и работает очень хорошо, хотелось бы, чтобы что-то подобное реализовали.

Не поймите меня неправильно, вы, ребята, проделали потрясающую работу, однако, если вам нужна честная обратная связь, отладка Blazor - это боль. Я использовал часы dotnet, и они вроде работают (они медленные), и я не могу отлаживать (по крайней мере, не с помощью Rider), так как я хотел бы использовать Blazor, я не могу из-за продуктивности. Поэтому я решил вместо этого придерживаться бритвенных страниц.

Спасибо.

Спасибо за отзыв, @wocar! Я знаю, что горячая перезагрузка важна. Это то, что мы очень хотим добавить, и ищем способы сделать это в .NET 5 в целом.

Я не могу отлаживать (по крайней мере, с Райдером)

Возможно, вы уже знаете, но на всякий случай можно выполнить отладку независимо от IDE, используя браузер в качестве отладчика .NET: https://docs.microsoft.com/en-us/aspnet/core /blazor/debug?view=aspnetcore-3.1#debug -в-браузере

Возможно, вы уже знаете, но на всякий случай можно выполнить отладку независимо от IDE, используя браузер в качестве отладчика .NET: https://docs.microsoft.com/en-us/aspnet/core /blazor/debug?view=aspnetcore-3.1#debug -в-браузере

Спасибо, что не знали.

Если я использую страницы razor (.cshtml), изменяю HTML и нажимаю F5, по крайней мере, я вижу изменения. Почему это невозможно с компонентами Razor (.razor)

Я также хотел бы получить более быстрый цикл разработки. После того, как мы запустили горячую перезагрузку для Vue, было так приятно внести изменения и увидеть их через 1,0–2,0 секунды в браузере. Теперь я вижу необходимость в чем-то подобном.

dotnet watch run дает нам часть пути - есть ли более простой промежуточный ответ, возможно, какой-то способ ускорить сборку, чтобы она была быстрее, когда ничего, кроме файла .razor, не изменилось? Это не избавило бы от необходимости перезапускать веб-хост и перезагружать страницу, как dbulic сказал выше, но ждать 1 секунду, а не 20 секунд для сборки было бы большим.

Есть ли какие-либо планы решить эту проблему путем создания своего рода «компиляции времени выполнения» для файлов .razor, работающих в браузере, по аналогии с компиляцией времени выполнения файлов .cshtml, доступной на сервере? Например, чтобы сами файлы .razor загружались непосредственно в браузер (вместо предварительно скомпилированных сборок), а затем компилировались там, а затем, если они редактировались на сервере, измененный файл .razor можно было повторно загрузить в браузер и перекомпилировать там? Мне нравятся здесь параллели с cshtml, и я задумался, рассматривается ли вообще этот путь?

Это запланировано на .NET 5, которое запланировано на ноябрь 2020 года. Мы все еще много обсуждаем, какой подход мы хотим здесь использовать.

Привет @ danroth27 , направление сформировалось? Если пока нечем поделиться, возможно, мы что-нибудь увидим на Build 2020?

Привет @mrlife. Мы ожидаем, что в первую очередь мы сосредоточимся на выпуске Blazor WebAssembly на BUILD. Поддержка горячей перезагрузки - это то, что мы ожидаем увидеть в .NET 5. Конкретное направление того, как это будет достигаться, еще не определено.

Я много думаю над этим вопросом. Каждый день я использую Паттерн 1. Паттерн 2 - это на практике смена парадигмы по сравнению с Паттерном 1; это упрощает внедрение по сравнению с непосредственным улучшением схемы 1. Я надеюсь, что Паттерн 3 близок к достижимому. Я чувствую, что Паттерн 4 является только желательным, основываясь на приведенных выше комментариях, однако после того, как я увидел, что возможно в MAUI, Паттерн 6 выглядит действительно хорошо.

Схема 1 (текущая из коробки):

1. Сохраняйте изменения в любом количестве файлов
2. Нажмите кнопку или нажмите команду клавиатуры, чтобы скомпилировать
3. Обновите браузер

Шаблон 2 ( dotnet watch run ):

1. Сохранить изменения в один файл
2. Автоматическая перекомпиляция
3. Сохраните любые другие необходимые файлы и дождитесь дополнительных перекомпиляций
4. Обновите браузер

Схема 3:

1. Сохраняйте изменения в любом количестве файлов
2. Частичная перекомпиляция или не требуется
3. Обновите браузер

Схема 4:

1. Сохраняйте изменения в любое количество файлов
2. Браузер отражает изменения в его текущем состоянии

Шаблон 5 (например, горячая перезагрузка MAUI ):

1. Не сохранять изменения в файл
2. Браузер отражает изменения в его текущем состоянии

Что достижимо?

Мой текущий шаблон с dotnet watch run :

1. Сохраните изменения во всех файлах с помощью Ctrl Shift S
2. Автоматическая перекомпиляция
3. Здесь описано автоматическое обновление браузера.

Эта проблема отслеживает горячую сборку / перезагрузку как для сервера Blazer, так и для веб-сборки, или существует отдельная проблема для веб-сборки?

Каков статус по этому поводу? В настоящее время используется https://github.com/OYIon/LiveSharp

это все очень неудобно. Я также не могу заставить работать обходной путь dotnet watch из проекта .dcproj aka docker-compose.Надеюсь, что в ближайшее время что-то произойдет.

отличная технология также требует отличных инструментов!

вещи постоянно выделяются красным цветом, а intellisense работает очень скромно.

То же самое, мой обходной путь:

• Убить devenv.exe
• удалить .vs \ папку
• Перезапустить проект

Инструменты снова будут работать. Делайте это пару раз в день. С рефакторингом пару раз в час. Попробуйте совместить это с поездкой к кофеварке

вещи постоянно выделяются красным цветом, а intellisense работает очень скромно.

Я знаю, что это сложно, но есть ли у вас какие-либо шаги для этого? Например, у вас есть код проекта, которым вы можете поделиться, который в определенной версии VS или VS Code надежно генерирует неверный intellisense или ошибки? Мы определенно хотим отслеживать и исправлять любые подобные проблемы.

cc @NTaylorMullen - знаете ли вы о каких-либо диагностических шагах, которые можно было бы предпринять здесь, чтобы помочь нам отследить это?

@SteveSandersonMS

Легко:

• Переименовать существующий файл компонента бритвы

(файлы с таким же префиксом также будут переименованы)

• Обновить имя класса в частичном классе

• Обновить / переименовать ссылки в других компонентах (ручное, сильно упущенная функция инструментов)

• Строительные работы

• Инструмент сломан

• После удаления папки .\vs vs восстанавливается

вещи постоянно выделяются красным цветом, а intellisense работает очень скромно.

Я знаю, что это сложно, но есть ли у вас какие-либо шаги для этого? Например, у вас есть код проекта, которым вы можете поделиться, который в определенной версии VS или VS Code надежно генерирует неверный intellisense или ошибки? Мы определенно хотим отслеживать и исправлять любые подобные проблемы.

cc @NTaylorMullen - знаете ли вы о каких-либо диагностических шагах, которые можно было бы предпринять здесь, чтобы помочь нам отследить это?

спасибо за ответ, буду следить за ним. любой вид рефакторинга определенно проблематичен, как уже приводил JvanderStad в качестве примера. в противном случае я пока не видел никакой закономерности.
например, я только что открыл файл с 219 строками и получил 167 ошибок intellisense. правила: CS0121 CS0229 CS1503

Возможно, было бы полезно создать дополнительную проблему с github для сбора проблем с intellisense? или это уже существует? потому что этот выпуск определенно не в том месте.

спасибо за ответ, буду следить за ним. любой вид рефакторинга определенно проблематичен, как уже приводил JvanderStad в качестве примера. в противном случае я пока не видел никакой закономерности.
например, я только что открыл файл с 219 строками и получил 167 ошибок intellisense. правила: CS0121 CS0229 CS1503

Возможно, было бы полезно создать дополнительную проблему с github для сбора проблем с intellisense? или это уже существует? потому что этот выпуск определенно не в том месте.

Это почти, если база данных intellisense повреждена / сбой языковой службы, она сохраняется после перезапуска 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>

Я использую райдер вместо vs и, кажется, работает очень хорошо. Также я использую этот инструмент под названием liveharp, хотя он не так хорош и не настолько надежен, но он выполняет свою работу, и я могу получать обновления пользовательского интерфейса без необходимости перекомпиляции.

@ cubed-it Этот PowerShell убивает Visual Studio, удаляет папку .vs \, перезапускает решение. Требуется меньше поездок за кофе.

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

Для тех, кто хочет придерживаться VS, вы можете использовать это расширение для работы ( https://marketplace.visualstudio.com/items?itemName=pragmatrix.BuildOnSave ), которое автоматически строится при сохранении и может быть включено только для запуска проекта. (в этом случае ваш проект Blazor). Для большего удобства отключите «Обеденный браузер» в VS, чтобы браузер не закрывался автоматически. Но вам придется нажать F5 в браузере :-(

Полностью почувствуйте всю свою боль в отношении инструмента Razor. К счастью, это то, что мы хотим решить во время разработки .NET 5. Если вы хотите попробовать этот инструмент (предупреждаем, что в настоящее время он супер экспериментальный), вы можете загрузить последнюю версию предварительного просмотра VS и установить следующий флажок функции предварительного просмотра (Инструменты -> Параметры -> Среда -> Функции предварительного просмотра):

Очень вероятно, что это решит многие проблемы редактора Razor, упомянутые в этом выпуске. При этом мы знаем, что в новом редакторе есть несколько пробелов и даже несколько плохих ошибок по сравнению с существующим редактором, но нам было бы любопытно услышать ваши отзывы независимо от того, был ли он в целом лучше для ваших нужд.

скачать последнюю предварительную версию VS
https://visualstudio.microsoft.com/vs/preview/

@NTaylorMullen Есть ли проблема, при которой я могу регистрировать ошибки, связанные с инструментарием Razor? Последний превью вообще не работает :(

@JvanderStad Я считаю, что синтаксис должен быть "@(row => ...

@JvanderStad Я считаю, что синтаксис должен быть "@(row => ...

Прекрасно работает в текущей версии

@JvanderStad ах, если вы говорите о цветах, это в настоящее время сломано, как и многие другие вещи

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

Я пропустил запись в блоге Дэниэлса. Теперь я знаю, чего ожидать. Спасибо

@NTaylorMullen Есть ли проблема, при которой я могу регистрировать ошибки, связанные с инструментарием Razor? Последний превью вообще не работает :(

Семантическая раскраска C # - это то, что мы еще не реализовали в новом редакторе 😄

@ danroth27 Если горячая перезагрузка для Blazor wasm сложна из-за архитектуры, как вы думаете, может ли горячая перезагрузка для сервера Blazor помочь? Идея состоит в том, чтобы беспрепятственно рендерить компоненты razor (из проекта blazor wasm) с помощью server-renderer во время разработки, сохраняя все проверки совместимости, которые обеспечивают развертывание blazor wasm, а также выполнение финального этапа тестирования и развертывания в реальной модели wasm.

есть ли обновления для горячей перезагрузки, будут ли они доступны в .net5 или уже включены в предварительную версию?

@ qin-guan Горячая перезагрузка .NET 5 не планируется из-за ограниченного времени, оставшегося в этом выпуске. Мы надеемся выполнить горячую перезагрузку .NET 6.

@ danroth27 аааааааааааааааааа !!

Пожалуйста, простите мое, возможно, предвзятое и, возможно, крайне невежественное мнение, но иногда мне кажется, что повышение производительности отходит на второй план по сравнению с повышением производительности ( в которое было вложено много работы )

Я хотел бы увидеть блог о 250 улучшениях производительности, которые вы внесли в этот выпуск, например, в свой инструментарий.
С моей личной точки зрения, если разработчики не получат нужную производительную цепочку инструментов, они не смогут выпускать программное обеспечение достаточно быстро, чтобы опередить конкурентов на рынке, и в результате их приложения не выживут в рынок, чтобы воспользоваться всеми этими замечательными блестящими улучшениями производительности. Так что с этой точки зрения это немного обидно.

Однако мне нравится внешний вид улучшений производительности ... Я просто очень надеюсь, что .NET 6 не сильно отстает от .NET 5, и мы видим, что производительность в Blazor начинает догонять другие фреймворки!

@ qin-guan Горячая перезагрузка .NET 5 не планируется из-за ограниченного времени, оставшегося в этом выпуске. Мы надеемся выполнить горячую перезагрузку .NET 6.

это так грустно, я ждал эту фичу для .net5 😭😭😭

@dazinator @ buster95 Мы разделяем ваше разочарование! Горячая перезагрузка была в значительной степени в верхней части нашего списка вещей, которые мы хотели сделать в .NET 5, и до сих пор находится в верхней части нашего невыполненного журнала. Первоначально ожидалось, что это будет частью более широких усилий по горячей перезагрузке в .NET, но все это было перенесено в .NET 6. Хорошая горячая перезагрузка - сложная проблема - это означает поиск надежных способов обновления работающего приложения так быстро, как возможно и с высокой точностью. Просто для этого требуется больше времени, чем было в .NET 5.

Для повышения производительности труда разработчиков мы полностью модернизируем редактор Razor, который должен включать целый ряд функций повышения производительности для разработки Blazor (рефакторинг, переход к def / impl, действия кода и т. Д.). Мы сделали новый редактор доступным в качестве дополнительной функции предварительного просмотра в начале этого месяца и планируем сделать его редактором Razor по умолчанию, вероятно, в начале следующего года.

У нас также есть ряд других функций платформы Blazor, входящих в .NET 5, включая изоляцию CSS, отложенную загрузку, установку фокуса пользовательского интерфейса, изменение заголовка HTML, загрузку файлов, защищенное хранилище браузера, виртуализацию и т. Д.

@dazinator @ buster95 Мы разделяем ваше разочарование! Горячая перезагрузка была в значительной степени в верхней части нашего списка вещей, которые мы хотели сделать в .NET 5, и до сих пор находится в верхней части нашего невыполненного журнала. Первоначально ожидалось, что это будет частью более широких усилий по горячей перезагрузке в .NET, но все это было перенесено в .NET 6. Хорошая горячая перезагрузка - сложная проблема - это означает поиск надежных способов обновления работающего приложения так быстро, как возможно и с высокой точностью. Просто для этого требуется больше времени, чем было в .NET 5.

Для повышения производительности труда разработчиков мы полностью модернизируем редактор Razor, который должен включать целый ряд функций повышения производительности для разработки Blazor (рефакторинг, переход к def / impl, действия кода и т. Д.). Мы сделали новый редактор доступным в качестве дополнительной функции предварительного просмотра в начале этого месяца и планируем сделать его редактором Razor по умолчанию, вероятно, в начале следующего года.

У нас также есть ряд других функций платформы Blazor, входящих в .NET 5, включая изоляцию CSS, отложенную загрузку, установку фокуса пользовательского интерфейса, изменение заголовка HTML, загрузку файлов, защищенное хранилище браузера, виртуализацию и т. Д.

Есть ли возможность создать бесплатное расширение вроде https://www.livesharp.net и быть бесплатным для всех?

это расширение легко настроить, но пока я использую 15-дневную пробную версию 😢

У меня вопрос, будет ли работать горячая перезагрузка для MacOS в том виде, в каком она запланирована на данный момент? Потому что редактировать и продолжить сейчас не работает.

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

@wocar Да, какое бы решение мы ни

@ danroth27 можете ли вы предоставить не очень хорошее решение, с которым также легко работать?
Например, наличие промежуточного программного обеспечения разработки с подключением к веб-сокету, которое обновляет страницу после медленной полной перестройки?

@ danroth27 можете ли вы предоставить не очень хорошее решение, с которым также легко работать?
Например, наличие промежуточного программного обеспечения разработки с подключением к веб-сокету, которое обновляет страницу после медленной полной перестройки?

@xrkolovos, если у вас есть VS, вы можете использовать ctrl-shift-b , ctrl-alt-enter (вручную после сборки), если у вас установлен BrowserLink : https://docs.microsoft.com/en- нас / aspnet / ядро ​​/ на стороне клиента / с использованием-browserlink? view = aspnetcore-3.1

Можете ли вы предоставить не очень хорошее решение, с которым также легко работать?
Например, наличие промежуточного программного обеспечения разработки с подключением к веб-сокету, которое обновляет страницу после медленной полной перестройки?

Мы работаем над тем, чтобы сделать именно это с dotnet watch для .NET 5: https://github.com/dotnet/aspnetcore/pull/24574

@dazinator @ buster95 Мы разделяем ваше разочарование! Горячая перезагрузка была в значительной степени в верхней части нашего списка вещей, которые мы хотели сделать в .NET 5, и до сих пор находится в верхней части нашего невыполненного журнала. Первоначально ожидалось, что это будет частью более широких усилий по горячей перезагрузке в .NET, но все это было перенесено в .NET 6. Хорошая горячая перезагрузка - сложная проблема - это означает поиск надежных способов обновления работающего приложения так быстро, как возможно и с высокой точностью. Просто для этого требуется больше времени, чем было в .NET 5.

@ danroth27 Предполагается ли, что "более широкая горячая перезагрузка" для .NET также работает для не-веб-проектов? И есть ли проблема, по которой я мог бы это отследить?

Мы переместили эту проблему в веху Backlog. Это означает, что над этим релизом работать не будет. Мы повторно оценим отставание после выхода текущего выпуска и рассмотрим этот элемент в то время. Чтобы узнать больше о нашем процессе управления проблемами и иметь более четкое представление о различных типах проблем, вы можете прочитать наш

Спасибо что связались с нами.
Мы переносим эту проблему на этап Next sprint planning для будущей оценки / рассмотрения. Мы оценим запрос, когда будем планировать работу на следующем этапе. Чтобы узнать больше о том, чего ожидать дальше и как будет решена эта проблема, вы можете узнать больше о нашем процессе сортировки здесь .

Теперь он доступен на .NET5, как я могу его активировать?

Теперь он доступен на .NET5, как я могу активировать

Чувак, проверьте комментарии выше, это планировалось для .net 6-preview 😢

@ buster95, тогда что, черт возьми, Стив Сандерсон сделал в .NET Conf 2020, день 1 за 2h38mm36ss, чтобы обновить страницу автоматически?
Ссылка на видео: https://www.youtube.com/watch?v=mS6ykjdOVRg

в 2х38мм36сс

@yasserss , в то время Сафия Абдалла говорила о компоненте <Virtualize> . Вы можете отправить соответствующую ссылку на видео в указанное время, нажав кнопку «Поделиться» на YouTube.

@BrunoBlanes, извините, вот оно: https://youtu.be/mS6ykjdOVRg?t=8917

Я почти уверен, что он использует dotnet watch.

Если вы посмотрите видео через 2 часа: 25 минут: 40 секунд, он использует dotnet watch run для запуска приложения, возможно, у нас есть улучшение в dotnet watch run , я помню, что в последний раз, когда я использовал просмотр dotnet, производительность была плохой. не знаю сейчас

Да, в .NET 5 мы работали над улучшением производительности dotnet watch . Например, теперь разумнее не запускать dotnet restore каждый раз, когда вы меняете источник, и теперь это может вызывать перезагрузку в браузере.

Это не самое лучшее видение горячей перезагрузки. Мы по-прежнему планируем реализовать настоящую функцию горячей перезагрузки в .NET 6, но пока что улучшения dotnet watch perf в .NET 5 - это шаг вперед.

Мы также включили поддержку автоматического обновления браузера как в dotnet watch и в VS. Чтобы включить эту функцию в VS, вам необходимо установить эту опцию:

Это отличается от горячей перезагрузки тем, что приложение все еще перезагружается, а приложение перезагружается в браузере. Но это позволяет вам сосредоточиться на редактировании кода, в то время как инструменты перестраивают и обновляют браузер за вас.

@ danroth27 Есть новости об автоматическом обновлении в Visual Studio для Mac?

@mrlife то, что мы планируем добавить в ближайшее время. К вашему сведению @jongalloway

@ danroth27

Мы также включили поддержку автоматического обновления браузера как в dotnet watch и в VS. Чтобы включить эту функцию в VS, вам необходимо установить эту опцию:

Это отличается от горячей перезагрузки тем, что приложение все еще перезагружается, а приложение перезагружается в браузере. Но это позволяет вам сосредоточиться на редактировании кода, в то время как инструменты перестраивают и обновляют браузер за вас.

При включении этого должно быть достаточно для отладки и перезагрузки при сохранении в VS2019? Я имею в виду, что у меня это включено с опцией, о которой вы упомянули, и когда я нажимаю F5, начинаю отладку и вносю изменения в свой код, браузер не перезагружается. Однако это происходит, когда я запускаю dotnet watch из консоли диспетчера пакетов. Как я могу достичь этой функции, просто нажав F5 во время отладки?

Учитывая раздел Автоматическое обновление с помощью dotnet watch примечаний к выпуску ASP.NET Core 5, я не думаю, что автоматическое обновление dotnet watch пока доступно в Visual Studio:

Мы надеемся добавить в Visual Studio функцию автоматического обновления в будущем.

@BrunoBlanes Поддержка автоматического обновления теперь доступна в Visual Studio с обновлением 16.8. Вам просто нужно включить его, используя указанную выше опцию. Я обновлю примечания к выпуску, чтобы удалить этот комментарий.

@porkopek Автоматическое восстановление и автоматическое обновление работают только тогда, когда вы не работаете с отладчиком.

Автоматическое обновление / сборка не работает даже при выборе параметра в Visual Studio 2019 16.8. Иногда я получаю сообщение об исключении нулевой ссылки во всплывающем окне Visual Studio, когда я выбираю автоматическую сборку и обновляю браузер после сохранения изменений. нужно ли что-то еще изменить в Visual Studio 2019 16.8, чтобы он работал. @ danroth27

Я понимаю, что это будет полноценный опыт работы с .NET 6. А как насчет текущей версии .NET 5 и Blazor Webassembly?

Должен ли этот параметр «Автоматическая сборка и обновление» также работать для веб-сборок Blazor? Что мне делать больше (кроме установки этой опции на: «Автоматическая сборка и обновление ...» и перехода к файлу Filename.razor, изменения чего-то и CTRL + S? :) Следует ли перезагрузить браузер?

Как (или это) соотносится со ссылкой в ​​браузере?

@MussaratAziz Информация об этой информации о горячей перезагрузке неполна, и страница msdn недоступна.
В моем случае мне пришлось придерживаться профиля IIS Express и запускать проект без отладчика.
Это привело к горячей перезагрузке или, скорее, горячей перезагрузке, но только для проекта Blazor Server. Я не тестировал версию WASM.

Я действительно надеюсь, что команда разработчиков ASP Core (вы классный !!) включит это, поскольку настройка пользовательского интерфейса без горячей перезагрузки довольно болезненна.

Надеюсь, это поможет :)

ИСПОЛЬЗУЙТЕ LIVESHARP ... не могу поверить, что ребенку в подвале удалось сделать то, чего не может сделать Microsoft.

Изменить: извините, не поймите меня неправильно, Microsoft проделала потрясающую работу ... но эта функция является обязательной ... просто изменить DIV или атрибут, как минимум 45 секунд

Кстати: пока я использую LiveSharp. Да, это может быть дорого для любителей, и я также хотел бы получить официальную поддержку от команды из Редмонда.
Однако продукт отличный, поддержка очень хорошая, и все работает.
https://www.livesharp.net/blazor/

Ура!

@wocar @ChristianWeyer Спасибо за вашу поддержку, ребята! Но, пожалуйста, не преуменьшайте усилия MS. Стороннему лицу почти всегда проще создать совершенно новое решение, потому что я ни перед кем не подотчетен. Это позволяет мне рисковать.

В любом случае, больше сотрудничества, меньше вражды.

Нет, я не преуменьшаю значение - au contraire :-) В конце концов, речь идет о prios.