The browser refresh mechansim used by dotnet-watch and VS modifies HTML content. The modified content includes
a script block that has a WebSocket url that changes for each new execution of dotnet watch run (not rebuilds, but watch itself).
HTML content can come from views or static html files on disk. For the latter, ASP.NET Core participates in browser caching by sending (and invalidating) etag headers.
One way to fix this problem is remove or modify the etag headers. The risk here is that might cause differences in behavior in development users may come to rely on that are unavailable in production. This change instead modifies the HTML content so the output is always consistent and consequently safe to cache. The dynamic content is served separately by the injected middleware.
This change fixes the issue of multiple instances of dotnet-watch. While this issue may crop up if you alternate between dotnet run and dotnet watch run but we haven't seen this being an issue as yet.
Fixes#27548
Summary
Running dotnet watch run multiple times in Blazor WASM apps (or any app that serves static html files) can produce console errors and prevent the browser refresh feature from working. Given that we've been telling our users to use dotnet watch run as their primary way to work outside of VS, it's likely more users would run in this.
Customer impact
A hard browser refresh (Ctrl + R) is needed to get the refresh behavior to work.
Regression
No. This has existed since the feature was introduced we did not get reports of it
Risk
Low. The fix is isolated to dotnet-watch and VS's browser refresh mechanism which is in preview. The change was tested locally, but if there's a regression or if the change interferes with user's workflow, users have the ability to disable this feature.
* Fix client validation for record types
Server validation for record types uses metadata from parameters
when validating record type properties. However client validation
does not use the parameter to harvest client validation attributes.
In the absence of this change, validation on parameters would require server
round trips which is unexcepted and not at parity with validation applied
to properties on regular classes or record types.
Validation experience with record types is subpar and requires server
round trips.
No. This feature is new to 5.0.
Low. The change is isolated to record types and does not affect other code paths. We have
unit and functional test coverage to verify this change.
* Correctly dispose app after use
* Converge implementations of AwaitableProcess and ProcessEx
* dotnet-watch tests are running in to the same issue as GRPC tests (https://github.com/dotnet/aspnetcore/pull/20341/files).
This change carries over some of the patterns from the other type to remedy this issue.
* Revive dotnet-watch tests on OSX
* Remove build artifacts that were accidentally commited to source.
dotnet-watch redirects standard out to detect when the app is launched and
prints these redirected messages to the console. Unfortunately once the app
is launched, redirected messages are no longer printed. This wasn't caught earlier
since ASP.NET Core is very quiet by default.
ASP.NET Core apps launched via dotnet watch do not print output to the console.
Yes. This was introduced as part of changes to dotnet-watch to launch a browser in 5.0-preview8.
Low.
- dotnet-watch builds against runtime in the SDK
- other projects build after runtime project due to Ref.csproj reference
- but, when the targeting packs aren't building, there's no reason to use Ref.csproj
- followup on 76fbd1a283 and 84962660a3, reducing parallelism in build
* Add option to specify hostName for refresh server
* Update env variable name per suggestion
Co-authored-by: Pranav K <prkrishn@hotmail.com>
Co-authored-by: Pranav K <prkrishn@hotmail.com>
- always use `$([MSBuild]::VersionXYZ(...))` for version checks
- use `$(NETCoreAppFrameworkIdentifier)` where it's available
- move `$(KnownAppHostPackOrFrameworkReferenceTfm)` setting to Directory.Build.props
- use it to correct `@(KnownFrameworkReference)` updates
- metadata of those items still uses `netcoreapp5.0`
- see also https://github.com/dotnet/efcore/pull/22279#discussion_r478674176
nits:
- do not assume `$(TargetFrameworkVersion)` starts with a 'v'; valid w/o it
- add `$(_IsMicrosoftNETCoreApp20OrOlder)` property in OpenAPI targets file
- evaluate the `Condition` once instead of three times
dotnet-watch expects full paths to files to watch in all added items. For files in the current project, this
happens to work. However this does not work very well for files in referenced projects. Using the FullPath metadata
does not work during global evaluation, but we're able to do this in a target.
This change adds extensibility to the dotnet-watch tool that allows calling a target as part of "watch" evaluation.
Fixes https://github.com/dotnet/aspnetcore/issues/22219
* Do not include the shared framework in the packages
DevServer and dotnet-watch include binaries from the ASP.NET Core shared framework
as part of the package. This change compiles these projects against the most recently built
version of the shared framework which ensures build and publish work as normals. Individual
projects from the runtime can be referenced to pick up new runtime features when necessary
* More hacks!
* Ensure shared runtime is built before running tests
* Delete dotnet-watch.nuspec
* Add a middleware for browser refresh.
* Introduce a middleware that can connect to the dotnet-watch change server
* dotnet-watch: Inject the middleware in 3.1 or apps using start hooks \ hosting startup
https://github.com/dotnet/aspnetcore/issues/23412
* Update src/Tools/dotnet-watch/BrowserRefresh/src/StartupHook.cs
* Changes per PR comments
* Add a test for reading the script
* Changes per PR comments
* Updates docs
* Fixup test
* Add project ref
* Tweaks to make dotnet-watch run faster
* Previously dotnet-watch calculated the watch file list on every run by invoking MSBuild. This
changes the tool to only calculate it if an MSBuild file (.targets, .props, .csproj etc) file changed
* For dotnet watch run and dotnet watch test command, use --no-restore if changed file is not an MSBuild file.
* Add opt-out switch
* Update src/Tools/dotnet-watch/README.md
* Fixup typo
* Update src/Tools/dotnet-watch/README.md
* Build time changes
A few changes for build time
- Don't build tests with SkipTestBuild=true and use that for official
build legs. This cuts 40%-50% off the msbuild invocations for build.
The longest build leg drops by about 30 mins.
- Skip logging of some task parameters and their metadata.
This reduces overall binlog size, which is a major contributor to
build time.
Unfortunately, this does not mean we can yet turn binlogs back on. This
change can actually increase the overall binlog size due to logging of
more project started arguments. There is another optimization for this
in progress.
Co-authored-by: Doug Bunting <6431421+dougbu@users.noreply.github.com>
* Remove extra `[SkipOnHelix]` attribute
- only need the one compiled into Microsoft.AspNetCore.Testing
- update the documentation to reflect this
- nit: address Markdown warnings that VS Code showed
* Add `SuccessfulTests` to ensure something runs in every non-Helix runs
- #22241
- cleans up hundreds of warnings but leaves a couple for the Blazor tests assembly
- see comments about xUnit runner command line in the new class
* Update dependencies from https://github.com/dotnet/arcade build 20200511.9
- Microsoft.DotNet.Arcade.Sdk: 5.0.0-beta.20228.4 => 5.0.0-beta.20261.9
- Microsoft.DotNet.GenAPI: 5.0.0-beta.20228.4 => 5.0.0-beta.20261.9
- Microsoft.DotNet.Helix.Sdk: 5.0.0-beta.20228.4 => 5.0.0-beta.20261.9
* Update dependencies from https://github.com/dotnet/aspnetcore-tooling build 20200514.6
Microsoft.AspNetCore.Mvc.Razor.Extensions , Microsoft.AspNetCore.Razor.Language , Microsoft.CodeAnalysis.Razor , Microsoft.NET.Sdk.Razor
From Version 5.0.0-preview.5.20261.4 -> To Version 5.0.0-preview.6.20264.6
* Pre-emptively take -nobl change
* Disable binlogs in CI
* Fix build.sh to know about -nobl
* Align build.ps1|sh with latest Arcade parameters
- do not enable binary logs by default in CI builds
- leave `-binaryLog` and `-excludeCIBinaryLog` handling to eng/common/tools.ps1|sh
- was unnecessary since `-bl /bl:{some name}` worked fine, ignoring OOMs
nit: document `-excludeCIBinarylog` a bit more
* Do not pass unknown options into CodeCheck.ps1
* Pass `-ci -nobl` into remaining CI build jobs
* Switch default TFM to `net5.0`
* Update missing project templates tfms
* Add more `-ci -nobl`
- needed because _all_ builds in the pipeline are implicitly CI builds
- default-build.yml adds `-ci` when script wasn't explicit
* Default templates to net5.0
* PR feedback
* Update TFMs in explicit .nuspec files
* Update TFMs in test projects
* Update TFMs in test C# code
* Update TFMs in infrastructure files
* Future-proof a check for `net5.0` or later
- avoid comparisons involving `$(TargetFramework)` in .targets files
- fine to compare it with `''` or `$(DefaultNetCoreTargetFramework)`
* !fixup! Undo a couple of earlier fixes
- remove a duplicate `$()` setting
- correct the one remaining versioned `#if` define
- did not make it `#if NETCOREAPP` because benchmarks test numerous .NET Core TFMs
* Disable binary logs in CodeCheck.ps1
* Specify `-ci -nobl` just once when using `parameters.buildArgs`
* Restore `$binaryLog` default logic
Co-authored-by: Doug Bunting <6431421+dougbu@users.noreply.github.com>
Co-authored-by: Will Godbe <wigodbe@microsoft.com>
Co-authored-by: Viktor Hofer <viktor.hofer@microsoft.com>
- Multi-target ObjectPool
- Move Embedded.Manifest.Task.Internal.Entry to the public namespace
- Remove ref assemblies from AspNetCore.Testing
- Skip TestPathUtilitiesTest since it's a pattern we want to migrate away from
- Fix FileProviders.Abstractions version in Embedded.*.nuspec
- Add workarounds for project references to FileProviders.Embedded