* Support pseudoelements in CSS scoping. Fixes#25268
* CR: More test cases
* Another pseudoelement case
* Case insensitivity for single-colon pseudoelements
Not that anybody should ever want to do this
* Avoid an allocation
* Reject @import rules in scoped CSS files
* CR feedback: Use SourceText
* CR feedback: Another test case
* Use same file reading mechanism as "generate" command
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.
- #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.
* Simplify ref/ assembly generation
- followup 1/2 for 5266918ed2
- correct the Razor.Tools project
- `%(Reference.Version)` metadata does not bleed through into `@(PackageReference)` items
- much more work to do so than to add this special case
- remove `$(Razor_NewtonsoftJsonPackageVersion)`
- remove RTMVersions project and use RepoTasks instead
- make it an error if RepoTasks is not restored before anything else builds
- add items and properties for System.Security.AccessControl
nits:
- remove invalid (ignored) metadata in Directory.Build.props and AzureAppServices.SiteExtension project
- improve / extend a couple of comments
- move `@(Reference)` items together in Microsoft.AspNetCore.Razor.Tools
Specifying the RID and PublishDir when publishing the driver app causes all sorts of
build issues. This change moves specifying the RID in to the driver app and ensures PublishDir
does not flow to the referenced RazorSDK project.
* Fix docker build
* Update readme typos
* 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
- Roslyn now default to 8.0 C# so it's no longer specified in a users project file. Because of this restriction we can no longer see the projects `LangVersion` when generating Razor files. Meaning, we can't conditionally generate C# 8.0 aware code because our Razor default is not C# 8.0. Therefore, when we detect that the C# lang version hasn't been provided we don't set a C# version and instead rely on what the default configuration for the Razor project is. In practice this looks like:
- MVC1.X = C# 7.3
- MVC2.X = C# 7.3
- MVC Latest = C# 8.0
- I thought about adding a feature flags variant for `RazorCodeGenerationOptions` but decided not to since C# features are all configurable options that are based on more than just the `RazorLangVersion`.
- Added integration tests to ensure that command line builds with implicit `LangVersion`s result in proper C# nullability handling.
aspnet/AspNetCoredotnet/aspnetcore-tooling#12594
\n\nCommit migrated from f039aa9354
- Obsoleted old `GetItem` API.
- Updated tests to take new API.
- Added a new test to verify the broken scenario.
dotnet/aspnetcore-tooling#8972
\n\nCommit migrated from 2dd34b8dd8
* Better support for _Imports.razor
* Special case component imports when generating code
* Prevent a future VS crash
* Rebased and updated
* update
* Removed unnecessary newline
\n\nCommit migrated from abbfe00bdc
- Expanded the `ProjectWorkspaceStateGenerator` to extract the C# language version when building the `ProjectWorkspaceState`. This approach enables all platforms to get nullability support without any changes (as long as they support `ProjectWorkspaceState`, which they do). Also, Roslyn suggested that we avoid dealing with LangVersion directly because there are several factors that impact its "effective" value on a project when run in tooling.
- Updated the `LinePragma` code generation to include `#nullable restore` and `#nullable disable` lines to allow for project restored nullability state for user code.
- Added a new `RazorProjectEngineBuilderExtensions` class that adds Roslyn specific project engine modifications. In this case it allows us to set the C# language version for a project engine and configure underlying features accordingly.
- Added a `SuppressNullabilityEnforcement` flag that only turns on if C# < 8 is specified.
- Updated LiveShare, VS4Mac and RazorGenerate to understand CSharpLanguageVersion.
- Added a single test output to show the change.
dotnet/aspnetcore-tooling#5092
\n\nCommit migrated from 1df8128b87
We need to be able to wire up these features from outside of the Razor
repo. For layering reasons this can't be done in the main Razor
assembly, so it can't be done by default.
\n\nCommit migrated from 386e2b3797
This change contains the enabling features to use Razor Components in a
class library. Currently we require a few workarounds, see the test
project file. This is good enough to get things unblocked.
One part that was needed was to register the correct component features
in the rzc. This is a good example, of why we don't like to add new
features that get registered conditionally, it's error-prone :)
The other part that was needed was to make some of the MVC-related
features for assembly attributes conditional on the TFM. We need to be
able to use the 3.0 (all inclusive) SDK, but without the MVC-related
features. This isn't the right heuristic, but it gets us unblocked.
\n\nCommit migrated from 8dbf02076b
This change adds all of the code from the Blazor/Components compiler into
the Razor language assembly. Minimal refactoring or integration work has
been done, that is next :)
All of the code compiles and all unit tests pass, except the one I had
to skip until integration work is done.
\n\nCommit migrated from aa5c82ca5e
This is a bit of a rework of how we initially set this up, but with more
forethought to how this will work in the project system. I have not yet
surfaced this through VS.
My immediate next step is to light up the component integration tests
and something like this is on the critical path to get that work since
we need a way to specify in tests that a document should be treated as
a component.
\n\nCommit migrated from 6b81da3f02
Steve Sanderson
Pranav K
Martin Costello
Tanay Parikh
Doug Bunting
Tanay Parikh
Javier Calvarro Nelson
dotnet-maestro[bot]
John Luo
Ryan Brandenburg
Kevin Pilch
N. Taylor Mullen
Ajay Bhargav Baaskaran
Ryan Nowak
Ryan Nowak