This change includes several improvements to CSS isolation that we have gathered from validation and usage feedback.
We have switched from producing a single scoped CSS bundle file for the entire application with all the scoped css files from the current project, referenced projects and package projects to producing one bundle per referenced project/package and to include those bundles into an "application" bundle throught CSS @import statements.
We have cleaned up the bundle names to make them more unique by including the project name on them and we have also cleaned up the bundle extensions.
We have decided to put the individual bundles generated for the project scoped css assets into the static web assets base path of the project, so that when developers reference assets from their scoped css files (like using the CSS url function) the path they use matches what they have inside their library wwwroot folder.
We have decided to put the application bundle on the root path of the application provided that the developer has not overriden the default StaticWebAssetsBasePath.
This is so that the bundle location is consistent across templates, and can be found at ProjectName.styles.css independent of whether the app is a blazor webassembly app or a server side blazor app.
For cases where the default StaticWebAssetBasePath has been overriden, the value is respected and the bundle is placed at $(StaticWebAssetBasePath)/ProjectName.styles.css.
Packaged razor class libraries with scoped css files now package a "project" bundle instead of the individual files.
* Use BlazorWebAssemblySDK
* Update projects to use the BlazorSDK
* Remove tasks and targets from RazorSDK
* Remove workarounds from BlazorSDK
* Fixup
* Fixup
- #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
The output of the declaration file for Razor components are unaffected by all inputs other than the input .razor file.
Consequently we can avoid regenerating these files if the output is newer than the input. This is the same heuristic we apply to Blazor WebAsssembly's
compression artifacts.
This PR combines these two improvements for a ~90ms (10%) improvement in the inner loop.
```
17 ms GenerateBlazorWebAssemblyBootJson 1 calls
22 ms Copy 8 calls
39 ms ProcessFrameworkReferences 1 calls
40 ms RazorTagHelper 1 calls
51 ms ResolveAssemblyReference 1 calls
70 ms GetFileHash 1 calls
80 ms RazorGenerate 2 calls
111 ms Csc 2 calls
Time Elapsed 00:00:00.95
```
```
17 ms GenerateBlazorWebAssemblyBootJson 1 calls
21 ms Copy 8 calls
37 ms ProcessFrameworkReferences 1 calls
51 ms ResolveAssemblyReference 1 calls
70 ms Csc 1 calls
72 ms GetFileHash 1 calls
79 ms RazorGenerate 2 calls
Time Elapsed 00:00:00.86
```
In after: Csc calls reduced to one, RazorTagHelper call removed.
* Wires up CSS isolation on the build.
* Transforms the css files during build.
* Bundles all scopes css into a single file and exposes it on _framework/scoped.styles.cs
* Packs pre-processed files as static web assets.
* Add framework support for lazy-loading assemblies on route change
* Configure lazy-loaded assemblies in WebAssemblyLazyLoadDefinition
* Move tests to WebAssembly-only scenarios
* Refactor RouteTableFactory and add WebAssemblyDynamicResourceLoader
* Address feedback from peer review
* Rename 'dynamicAssembly' to 'lazyAssembly' and address peer review
* Add sample with loading state
* Update Router API and assembly loading tests
* Support and test cancellation and pre-rendering
* Apply suggestions from code review
Co-authored-by: Steve Sanderson <SteveSandersonMS@users.noreply.github.com>
* Spurce up API and add tests for pre-rendering scenario
* Use CT instead of CTS in NavigationContext
* Address feedback from peer review
* Remove extra test file and update Router
Co-authored-by: Steve Sanderson <SteveSandersonMS@users.noreply.github.com>
* Add support for gzip compression during build and publish
3.2 shipped with gzip compression during build and publish. During the port to 5.0, the build and publish
pipeline was different and ended up only during brotli compression during publish. However, during build
the app size is now up to 20MB. Statically compressing runtime assets during build reduces the payload size
to about 8.5 MB. This should help with faster initial boot ups and perception.
* Quarantine test
* More quarantine
* Use linker extensibility to enable better trimming
* Configure TrimmerDefaults=link if unspecified
* Allow Microsoft.AspNetCore.* and Microsoft.Extensions.* packages to be trimmed.
* Make producing the trimmer root descriptor more incremental
* Razor SDK build ordering issues
* Build the SDK completely regardless of the MSBuild runtime type
* Split SDK integration tests into a separate project. Clean up project file
* Add project to sln
* Update Microsoft.NET.Sdk.Razor.csproj
* Fixup tests
* Avoid rebuilding dependencies if they appear up to date. Fixup tests
* Fixup
* Update CSharp.Common.props
* Cleanup the build
Pranav K
Javier Calvarro Nelson
Brennan
dotnet-maestro[bot]
Doug Bunting
Safia Abdalla
Stephen Halter
Chris Ross