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.
- 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
Create new instances of List<T> with an appropriate capacity for the items that will be added.
Use Array.Empty<T>() where appropriate, rather than create an empty list and then return it.
* Use BlazorWebAssemblySDK
* Update projects to use the BlazorSDK
* Remove tasks and targets from RazorSDK
* Remove workarounds from BlazorSDK
* Fixup
* Fixup
* 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
* Remove LinkerWorkaround.xml
The workaround file is no longer needed, now that the underlying bugs are fixed in the dotnet/runtime libraries.
Fix#23262
* Also remove LinkerWorkaround from Components/WebAssembly
- #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.
* 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.
* Default new runtime feature switches
These new feature switches have been added to the runtime to make applications smaller. Setting reasonable defaults to Blazor wasm projects.
Fix#23716
* PR feedback
* Default new runtime feature switches
These new feature switches have been added to the runtime to make applications smaller. Setting reasonable defaults to Blazor wasm projects.
Fix#23716
* PR feedback
* 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>
* The underlying Json issue is fixed.
* The X509 issue is not an issue when TrimMode is set to link (which is it now by default).
Contributes to #23262
* 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
* Ensure BlazorWebAssembly.js is present
* Unquaratine blazor template tests
* The failure issue https://github.com/dotnet/aspnetcore/issues/20479 was resolved, but the assembly level quarantine was
missed being removed.
* Use shorter project file names to avoid long path issues.
* Update blazorwasm template tests to react to net5 updates
* Update src/ProjectTemplates/Shared/ProjectFactoryFixture.cs
Pranav K
Brennan
Javier Calvarro Nelson
Doug Bunting
Artak
Chris Sienkiewicz
Martin Costello
Pranav Krishnamoorthy
Eric Erhardt
dotnet-maestro[bot]
Safia Abdalla
Tanay Parikh
Steve Sanderson
Stephen Halter