Aspnetcore: Develop without recompile?

[joshmouch]

Hi, I'm experimenting with the new Razor Component features, and I'm super excited about the feature.

However, the very biggest flaw I found is that each and every HTML change requires a recompile before you can view it. This means closing your browser and your state in the app, then getting to a new browser window and navigating back to the page and state you are working on). I can see this adding a lot of time to development and possibly outweighing the benefit of not having to use javascript. This is in contrast to traditional Asp.net that only requires a recompile if the code-behind changes, but html changes appear right away.

Are there any plans to not require a recompile for simple things like a CSS class change? Are there different ways to develop that would remove this need (e.g. using a code behind rather than in-line functions)? Are there certain types of changes that require a recompile (e.g. HTML inside a for-loop) vs changes that don't?

One thought I had is that early on in ASP.Net Core development, there was some setting I had on that auto-compiled the project after every change. I'm not sure what it was, but I think it just monitored the folder for changes. You couldn't debug this way, but you could keep IIS Express open and a single browser window and see the changes you made right away.

As a side question, will there be support for the Visual Studio "Browser Link" feature in the future?

[robertjak]

Hi,
that is the same feature I miss after my testing of the new technology. Web development has become very complex (actually it always was), one really needs to play and try very often, it is impossible to program everything in advance and then run the build. Of course much can be done in Chrome, but then we need to manually copy paste the changed code to the Visual Studio, save, rebuild...

Otherwise I am very excited about the real return of C# to the web UI!

[joshmouch]

Does the development team have any feedback on this? Our team is evaluating what we will be doing our next POC project in, and this is going to be a strong factor.

[SteveSandersonMS]

every HTML change requires a recompile before you can view it.

That's true, because what we're sending to the browser isn't HTML text, but rather are efficiently binary-serialized instructions that perform minimal updates on the DOM by diffing successive UI states. It is more optimized around production runtime than development time at this point.

Longer term we aim to restore the "auto recompile" feature we used to have, whereby each time you press "reload" in the browser, it automatically performs any necessary recompilation in the background. We hope to get this cycle time down to about 1 second for typical changes on typical dev machines.

This means closing your browser

You don't have to close your browser. I'd strongly recommend launching from VS using Ctrl+F5 to launch without debugging. This is faster, plus then your same browser window can remain open for as long as you want. Just reload that window after compiling any change.

Are there any plans to not require a recompile for simple things like a CSS class change?

When you edit .css files or other static assets, you can directly reload in the browser without needing any compile step.

If you mean editing a .razor file to change a CSS class reference, we will still need the same compilation pipeline in order to update the code that generates these UI update instructions. As above, our goal is to make this compilation process more convenient and faster.

One thought I had is that early on in ASP.Net Core development, there was some setting I had on that auto-compiled the project after every change. I'm not sure what it was, but I think it just monitored the folder for changes.

That's dotnet watch. You can do that with Razor Components today, but the build cycle time isn't near the standards we're aiming for. It typically takes 5-10 seconds to recompile even a small project. We aim to do much better than that with the autorebuild work.

As a side question, will there be support for the Visual Studio "Browser Link" feature in the future?

That's not something we're specifically planning for at the moment. If there are scenarios with this that are important to you, please let us know exactly what functionality you're feeling the loss of, because maybe we either might look at Browser Link in the future, or we might recreate similar capabilities in ways that better match up with our newer technology.

cc @danroth27 for any follow-up.

[guidevnet]

Longer term we aim to restore the "auto recompile" feature we used to have, whereby each time you press "reload" in the browser, it automatically performs any necessary recompilation in the background.

@SteveSandersonMS What exactly did you mean by "Longer term"? A future preview, the final release or after? Is there any tracking/roadmap for this feature?

[danroth27]

What exactly did you mean by "Longer term"? A future preview, the final release or after? There is any tracking/roadmap for this feature?

@guidevnet We expect to get auto recompile back for .NET Core 3.0. It requires a tooling update though, so it will probably be a couple of months before this is available again.

/cc: @shirhatti @andrew-msft

[AndrewBrianHall]

Also, per some of the questions around syncing css and js and Browser Link support. ASP.NET Core supports Browser Link in Visual Studio, but it's no longer on by default in the ASP.NET Core templates as we strive to make them work for all platforms since Browser Link is specific to Visual Studio. You can enable Browser Link by following the instructions at https://docs.microsoft.com/en-us/aspnet/core/client-side/using-browserlink?view=aspnetcore-2.2

/cc: @metoly