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.
Description
HTML <a> elements within shadow roots are invisible to the link click interception code. So when an end user clicks on a link that's inside the shadow root of a custom element, it triggers a full page load instead of a client-side navigation.
Customer Impact
Reported by a customer at #27070. There's no reasonable workaround (besides not using custom elements and shadow DOM).
The impact is that if you're using a library of custom HTML elements, which typically use ShadowDOM to render, then if you use them to produce any links, then those links will seem broken to the end user (as in, they trigger a full-page reload, destroying any app state in WebAssembly memory or discarding the Blazor Server circuit).
Regression?
No, this has always been the case. However, the use of custom elements and ShadowDOM is a growing area, especially as we try to guide customers to use custom elements like the FAST components.
The fact that this use case is growing in importance makes it relevant to consider patching rather than waiting a full year for 6.0.
We don't have to ship this in 5.0.1, but we should be prepared to ship it in a patch reasonably soon.
Risk
This changes the logic for processing clicks on all links, not just the ones in shadow roots. Although I'm not aware of any cases where the new logic might fail, and all our E2E tests pass, maybe I missed some case. It's unfortunate we don't have any opportunity to put this in front of customers any any preview form.
Description
Fixes#27494
A community PR introduced new overloads to ControllerBase for SignIn. The new overload throws due to an existing check which blocks when the scheme is null. The fix is to remove this unnecessary check. Note SignOutResult already had test coverage for this usage and is unaffected
Customer Impact
The bug was reported by a customer trying to use the new overload. The fix enables the method to be used.
Regression?
No
Risk
Low as this is a new API, and the api was unuseable in its current form.
Description
This PR updates the version of the caniuse-lite dependency to the latest version on our React and React/Redux SPA templates. The caniuse-lite dependency provides a database of browser features and their support across different browsers (as seen in caniuse.com). We were getting a warning because the dependency was out-of-date which meant that it was reporting compatibility info that was no longer accurate.
This PR also updates the version of node-sass to the latest version which no longer depends on the no-longer-supported Python 2.
Customer Impact
This bug was discovered during CTI validation.
This bug has a low severity because the user application can still run although JavaScript-based build tooling might report that the developer is leveraging browser features that aren't supported by the browser when they actually are.
Users can workaround this by running npx browserslist@latest --update-db inside their ClientApp directory. Users can also manually upgrade node-sass to v5 by editing their package.json file.
Regression?
No.
Risk
Low risk, because:
Change was validated manual
This fix applies the changes recommended by the browserlist library
* Move all PublicAPI.Unshipped.txt files to PublicAPI.Shipped.txt
- we have now shipped this API surface
* Add eng/PublicAPI.empty.txt file
- make it easier to add new implementation projects
* Add missing public API baseline files
- #26784 part 1/2
- a few unexpected files turned up missing beyond the #26784 list…
* Reference Microsoft.CodeAnalysis.PublicApiAnalyzers more often
- #27484 part 2/2
- emit errors when API baseline files are missing
- update categorization of some projects
- specification tests are not implementation projects
- but _were_ project reference providers (keep that)
- correct `$(IsTestAssetProject)` setting for Razor shims et cetera
- correct `$(IsSampleProject)` setting for casing of some Sample directories
- Microsoft.AspNetCore.Analyzer.Testing should be treated as test asset
- add `$(AddPublicApiAnalyzers)` property to support overrides
- e.g. for `msbuild` task projects and tools
nit:
- remove useless `$(IsTestProject)` setting in a specification test project
- wrap some long `Condition`s
* Do not run public API analyzer in `RazorCoreCompile` target
* Remove old `$(EnableApiCheck)` settings
- property does nothing
- also remove a dangling ApiCheck comment
* Ensure AppLocalResolver handles package with multiple libs
This was failing to pass references to a package which contains more
than one lib.
* Use `AppBaseCompilationAssemblyResolver` in `DiagnosticProject`
* Fix, then reduce use of `TestPathUtilities.GetSolutionRootDirectory(...)` (#27404)
- do not traverse up past the `$(RepoRoot)` when running tests locally
- if `$(RepoRoot)` is reached, search down for named `*.slnf` file
- find `*.slnf` file when `$(OutputPath)` is under artifacts/bin/
- analyzer test projects publish needed files anyhow
- remove `GetProjectDirectory()` helpers
Co-authored-by: Doug Bunting <6431421+dougbu@users.noreply.github.com>
* Move to 5.0.1 versions
* Move to GA .NET SDK
- required for some tests to pass
* Remove feeds that won't be needed after 5.0.0 is GA
* Cherry-pick `$(CrossgenOutput)` and Directory.Build.*.in changes from master
- [master] Update dependencies from dotnet/runtime dotnet/efcore (#26788)
- 219ecd688012
- when project template tests run test assets, need latest shared Fx bits
- hit `BadImageFormatException`s otherwise
- test projects build against uploaded packages
- those packages reference the 5.0.1 shared framework
- the ASP.NET parts of the 5.0.1 shared Fx are `crossgen`ed to target Windows
- Use runtime and ref/ assemblies matching repo in Helix testing
- add Directory.Build.*.in files based on project template test infrastructure
- use files as import boundary where the project doesn't create its own Directory.Build.* files
- ensure `dotnet-watch` tests also use the latest runtime and ref/ assemblies
- Extend Helix Directory.Build.* workarounds
- generate Directory.Build.* files when restoring any projects
- include generated files in Helix runs needing the latest runtime
- copy generated files when testing `dotnet-watch` locally
- include generated content in Microsoft.NET.Sdk.BlazorWebAssembly.IntegrationTests test assets
- remove duplicate settings from existing Directory.Build.* files
- ensure shared framework and targeting packs are laid out under .dotnet/ before test assets restore
- Disable `crossgen` when building for Helix runs
- make `$(CrossgenOutput)` property override-able
- use override in CI jobs that submit to other platforms
- for now, leave the ARM64 Helix jobs alone (build on Ubuntu, run in Debian)
* Correct an `$(IsTestAssetProject)` setting
- affected projects are all test assets or provide test support
- without this, a number of the projects are incorrectly marked as shipping
* Baseline released 5.0.0 packages
- this is a complete rewrite of eng/Baseline.xml
- based on the 5.0.0 MergedManifest.xml file
* Add 5.0.0 PackageOverrides.txt and PlatformManifest.txt files
- need consistent versions when servicing targeting packs
Co-authored-by: dotnet-maestro[bot] <42748379+dotnet-maestro[bot]@users.noreply.github.com>
- run aspnetcore-helix-matrix at 09:00 UTC
- the first run of master starts at noon UTC
- looks highly unlikely new run would take 3 hours
- add rolling builds of aspnetcore-quarantined-pr
nit: make target branches for PR builds explicit
- we don't support Helix testing of 3.1 or older
Description
We had support for the UpToDateCheck in Visual Studio with CSS isolation but the target was not being run at design time. This change introduces a new target that runs at design time and makes sure the UpToDateCheckInput and UpToDateCheckBuilt ItemGroups are populated.
Customer Impact
When using CSS isolation from within Visual Studio, a change in a scoped CSS file is not picked up and the project is not rebuilt as a result.
Regression?
No. This feature was introduced in 5.0.
Risk
Low. The new target we added only runs as part of Visual Studio builds.
Fixes
#26843
* Add docs for remaining security items
* Google / Facebook / Microsoft Account auth
* Authorization, Authorization.Policy
Contributes to https://github.com/dotnet/aspnetcore/issues/26397
* Apply suggestions from code review
Co-authored-by: Chris Ross <Tratcher@Outlook.com>
* Update src/Security/Authorization/Policy/src/AuthorizationMiddleware.cs
Co-authored-by: Chris Ross <Tratcher@Outlook.com>
* Fix some post-build signing issues
This fixes some post-build signing issues that are present in the aspnetcore repo
1. Add the .msi extension to be signed by Microsoft400 - Msis must be signed. With in-build signing these get handled explicitly by the wixproj infrastructure. When we do post build signing, we must sign these files.
2. Remove the strong name exclusions. These exclusions are incorrect when applied in post-build and unnecessary for in-build signing. Most importantly, the aspnetcore PKT would not end up re-strong named (it doesn't need to be strong name signed by ESRP since it's strong named in-build) because the PKT doesn't match any of the StrongNameSignInfo specified in arcade. The rest of the entries seem to be mostly about optimization. I could not find any performance difference between these entries being present and not. I am not sure whether they actually even apply to any assets. Moreover, when doing post-build signing, they would conflict with the entries in runtime and other places.
Verification - I have a tool that I wrote which unpacks every file between two directories and compares the strong name, nuget, and authenticode certs between equivalent files. This is the same tool being used to verify post-build signing. This tool shows no difference in any aspnetcore produced asset.
Baseline: https://dev.azure.com/dnceng/internal/_build/results?buildId=836183&view=results
Diff: https://dev.azure.com/dnceng/internal/_build/results?buildId=837176&view=results
* Do not push VS packages for installers when PostBuildSign == true
* Output wix command packages to the installers output path
* Don't import microbuild signing targets from wix when PostBuildSign=true
* Tweaks:
- Don't sign wixpacks when not in post-build signing
- Generate a wixpack for both the original msi name (which the wixproj generates) AND the name we use in the final outputs. This is because while these files are the same, signing differentiates the certificate based on the file name, and wixpack lookup is also based on the file names. Aspnetcore and other repos have uses the final outputs (e.g. dotnet-aspnetcore-runtime-123.5..) as well as the internal names (e.g. AspNetCoreSharedFramework_x64.msi).
- Don't sign msi's when not post-build signing.
* Avoid generating sha512 files for wixpack zips
* Don't run xplat code sign jobs if PostBuildSign == true
* Change original target names
* Conditionalize codesign operations
* Add publishing flag for linux x64 and add deb sha512 generation
* Do not push the x64 linux runtime archive more than once
* !!! Correct condition controlling `public` API analysis !!!
- #26785 demonstrated analyzers were inoperable
* Remove unused `public` API files
* Update `public` API files
- three Components files were missing `#nullable enable`
- `nullable` annotations missing or out-of-date elsewhere
* Ignore `public` API files completely during source build
- do not warn about unused files
* Update more `public` API files
John Luo
Pranav K
Steve Sanderson
Hao Kung
Safia Abdalla
dotnet-maestro[bot]
Doug Bunting
Eric StJohn
William Godbe
Matt Mitchell
Stephen Halter
Javier Calvarro Nelson
Phil Henning