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
- mostly duplicates #25217
- update `BaselineGenerator` to produce baselines useful in 6.0 (too)
- update Baseline.Designer.props using new generator (matching 3.1.7 release)
- always suppress references expressed only in `*.nuspec` files
- needed even in servicing builds
- restore warning and errors about removed references (new for 5.0)
- adjust exclusions to handle `@(_ProjectReferenceByAssemblyName)` removal
nit: do not generate empty `<ItemGroup />` elements
* Correct `@(SuppressBaselineReference)` items
- remove out-of-date `@(SuppressBaselineReference)` items
- either 3.1.7 baselines we're using don't include reference or still using package
- fix some comments and `Condition` attributes to make remainder easy to find
- add missing `@(SuppressBaselineReference)` items
* Add net461 TFM to netstandard2.0 projects
* Fix a couple of errors
* Fix some errors
* Get rid of Sockets reference
* Respond to feedback
* net461 -> property
* Fixup clientSample
* Remove net461 from analyzers/razor
* Remove net461 from test projects
* Feedback
* Add net461 test configs
* Remove some incompatible test configs
* Fix test
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 support for the trust option on Linux on the command-line tool and print a message when it's used pointing to docs.
* Bump the certificate version to 2 to ensure that the certificate gets updated for 5.0 on Mac OS.
* Ensure we always select the certificate with the highest available version to ensure that when we change the certificate in the future older runtimes pick up the new certificate.
* Support exporting the certificate without key on PEM format.
- target project is a test project; need to undo `$(SkipTestBuild)` impact in these jobs
nit: remove a comment from DeveloperCertificates project that's irrelevant now
* Remove Internal.AspNetCore.Analyzers
This resolves build flakiness caused by referencing the analyzer:
```
2020-08-07T21:22:39.1149296Z ##[error].dotnet\sdk\5.0.100-rc.1.20379.10\Microsoft.Common.CurrentVersion.targets(4188,5): error MSB3026: (NETCORE_ENGINEERING_TELEMETRY=Build)
Could not copy "F:\workspace\_work\1\s\artifacts\obj\Internal.AspNetCore.Analyzers\Release\netstandard1.3\Internal.AspNetCore.Analyzers.dll"
to "F:\workspace\_work\1\s\artifacts\bin\Internal.AspNetCore.Analyzers\Release\netstandard1.3\Internal.AspNetCore.Analyzers.dll". Beginning retry 1 in 1000ms.
The process cannot access the file 'F:\workspace\_work\1\s\artifacts\bin\Internal.AspNetCore.Analyzers\Release\netstandard1.3\Internal.AspNetCore.Analyzers.dll' because it is being used by another process.
```
The analyzer checks if pubternal types are being exposed in public APIs. We no longer author pubternal types, so this is no longer a concern.
* Remove DisablePubternalApiCheck
* 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
- #20818, fix e.g. references to Microsoft.Web.Xdt.Extensions in our packages
- make `@(Reference)` items much more broadly applicable
- emit an error when `@(ProjectReference)` is used instead of `@(Reference)`
- then get rid of the errors (!!)
- rename a couple of projects to match their assembly names
- then regenerate the `@(ProjectReferenceProvider)` items
- switch intersection approach from Exclude / Exclude to Copy / Update / Copy
Projects of particular interest:
- src/DefaultBuilder/src/Microsoft.AspNetCore.csproj
- honouring metadata left e.g. Microsoft.AspNetCore.Components.WebAssembly.DevServer package unchanged
- removed redundant metadata after that confirmation
- src/Razor/tools/Microsoft.AspNetCore.Razor.Internal.Transport/
- content of this package unchanged but metadata avoids extra work
- add a comment about the extra work
- src/SiteExtensions/LoggingAggregate/src/Microsoft.AspNetCore.AzureAppServices.SiteExtension/
- success! removes Microsoft.Web.Xdt.Extensions dependency from the package
- src/SiteExtensions/Runtime/Microsoft.AspNetCore.Runtime.SiteExtension.pkgproj
- add a `Condition` to avoid an ordering issue I hit here
- src/Tools/Extensions.ApiDescription.Server/src/
- avoid errors the new build ordering and timing caused
Separately, up the timeout in the `<DownloadFile />` task
- hit repeated timeouts downloading dotnet-runtime-5.0.0-rc.1.20370.4-win-x64.zip
nits:
- remove dupe `@(Reference)` item in Microsoft.AspNetCore.Components.WebAssembly.DevServer.csproj
- remove useless `%(ProjectReference.IsImplicitlyDefined)` metadata as well as its misspellings
- remove extra spaces from ProjectReferences.props
- clean up a few comments in ResolveReferences.targets
* !fixup! Correct other references to renamed projects
* 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
* nit: Remove useless `$(HasReferenceAssembly)` settings
- set in /Directory.Build.targets
- `true` only in `$(IsAspNetCoreApp)` projects
* nit: Remove useless `$(CompileUsingReferenceAssemblies)` settings
- no current versioning differences between ref/ and src/ assemblies when targeting default TFM
* Add more `$(GenerateDocumentationFile)` settings
- increases the number of generated doc files, mostly without problems
- !fixup! correct typo in `DebugProxyHost` doc comments
- was not generating a doc file before
- remove previous (ineffective) src/Components/Directory.Build.targets setting
- nit: remove a duplicate `$(GenerateDocumentationFile)` setting
* nit: Remove useless `$(IsPackable)` settings
- only analyzers and implementation projects are packable by default
- main use case for explicit setting is projects shipping only in shared framework
- conditional setting in src/Mvc/Directory.Build.props just subset logic in /Directory.Build.targets
* nit: Remove useless `$(IsProjectReferenceProvider)` settings
- only implementation projects are providers by default
* nit: Remove useless `$(IsTestAssetProject)` settings
- set in src/Mvc/test/WebSites/Directory.Build.props
* !fixup! Looks like `InProcessNewShimWebSite` must compile w/o ref/ assemblies
- restore `$(CompileUsingReferenceAssemblies)` in this one project
* 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
Pranav K
Doug Bunting
Kevin Pilch
Martin Costello
Zachary Becknell
Artak
William Godbe
Javier Calvarro Nelson
Brennan
Chris Ross
Levi Broderick
Tanay Parikh
Stephen Halter
Justin Kotalik
Safia Abdalla
John Luo
Matt Mitchell