This change updates the snapshot of components APIs used in compiler
tests and updates the tests to react tot hose changes.
\n\nCommit migrated from c8cc588bca
* Give "builder" a less discoverable name
Fixes https://github.com/aspnet/AspNetCore/issues/12991
* Fixup tests
* [Blazor][Fixesdotnet/aspnetcore-tooling#12933] Remove the need for a custom property when resolving static web assets from referenced projects
* Removes the need for a custom property when resolving static web assets from referenced projects
* Rolls in several improvements suggested by the MSBuild folks to improve performance.
\n\nCommit migrated from 112f72da6b
* Removes the need for a custom property when resolving static web assets from referenced projects
* Rolls in several improvements suggested by the MSBuild folks to improve performance.\n\nCommit migrated from 5335245b08
The code-generated TypeInference type resides in a custom namespace.
Any types that it refers to in user code must be qualified using the "global::" prefix
to avoid type \ namespace conflicts.
Fixes https://github.com/aspnet/AspNetCore/issues/12116\n\nCommit migrated from f0e09e4a97
- The core issue is that the Razor parser splits attribute values based on whitespace. Therefore, when it encounters `@onclick="() => Foo()"` it breaks it into three different tokens based on the spaces involved. This separation results in multiple adjacent classified spans for C# which is currently unsupported by WTE due to multiple seams overlapping. All that being said we have the opportunity to be smarter when generating attribute values that we feel can be simplified or collapsed; because of this in this PR I changed the `TagHelperBlockRewriter` phase to understand "simple" collapsible blocks and to then collapse them. In the future a goal would be to take a collapsing approach to all potential attributes and then to re-inspect each token individually at higher layers in order to decouple our TagHelper phases from what the parser initially parses.
- Added an integration and parser test to validate the new functionality. Most of the testing is from the fact that no other tests had to change because of this (it doesn't break anything).
- Added a new SyntaxNode method `GetTokens` that flattens a node into only its token representation.
aspnet/AspNetCoredotnet/aspnetcore-tooling#11826
\n\nCommit migrated from 80f1bc76a4
Don't even try to review this xD
This change moves RenderTreeBuilder to the .Rendering namespace and then
updates literally every component baseline.
\n\nCommit migrated from aa8624f46e
- 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
- We would default to improper C# language versions when given non-numeric `LangVersion`s. For instance when given `CSharpLanguageVersion.Latest` we'd default to 7.3 which was inconsistent with how the rest of the C# world functioned.
- Added a test.
aspnet/AspNetCoredotnet/aspnetcore-tooling#11139
\n\nCommit migrated from a08d0b0673
- Updated instances of our code to no longer use reference type checks on `ISymbol`s. This was a new restriction added by Roslyn [here](https://github.com/dotnet/roslyn-analyzers/issues/2084). We also have a follow up AspNetCore issue [here](https://github.com/aspnet/AspNetCore/issues/12747) to bring these level of changes to AspNetCore.
- Had to pin `Microsoft.CodeAnalysis.Analyzers` in our VSIX projects in order to workaround version conflicts of `Microsoft.CodeAnalysis.Analyzers`. The version conflict is introduced from our dependency on `Microsoft.VisualStudio.ProjectSystem.Managed.VS`. It transitively depends on `Microsoft.CodeAnalysis.Analyzers` `2.6.3` where as our latest Roslyn bits transitively depend on `Microsoft.CodeAnlalysis.Analyzers` `2.9.4`. Tried updating to the latest, private, `Microsoft.VisualStudio.ProjectSystem.Managed.VS` but it also had the version conflict.
- Pinned our runtime bits to the latest public Roslyn NuGet package and pinned our tooling bits to the latest private NuGet package (both are compatible flavors of 3.3.0).
\n\nCommit migrated from 83d5e2c36f
- Prior to this a user could have private, protected or public parameters. We now require public and plan to update analyzers to enforce good usage of public component parameters.
- Removed private `ComponentTagHelperDescriptorProvider` workaround. meta data workaround since we no longer operate on private parameters.
- Updated existing tests to not have private parameter setters. I missed these in my last pass.
- Added two new tests to validate parameters which are private or have private setters are ignored.
aspnet/AspNetCoredotnet/aspnetcore-tooling#12291
\n\nCommit migrated from bb543aa166
John Luo
Doug Bunting
dotnet-maestro[bot]
Ajay Bhargav Baaskaran
N. Taylor Mullen
William Godbe
Pranav K
Kevin Pilch
Ryan Nowak
Nick Guerrera
dotnet-maestro-bot
Javier Calvarro Nelson
Ryan Nowak