- No longer mark declaration files as single file generators. Prior to this we relied on SingleFileGenerators to dynamically update the declaration files when .razor files changed. However, to make partial classes work we can no longer depend on declaration files being available because their existence causes us to have to mangle class names for opened documents; otherwise you get two files with same name and result in ambiguous definition errors.
- Stopped including declaration files as part of the users compilation. This was intended to make the design time experience operate more similar to how Blazor apps function at runtime (directly access each component instead of their declarations). We now rely on the background code generation effort built from the find all references work to supply users with strongly typed component names.
- Stop mangling class names for Visual Studio. Razor.VSCode has its own set of configurations which i'm not addressing as part of this changeset.
- Start generating components with the partial modifier to their class name to enable partial class support.
- Updated existing tests to expect partial modifier.
aspnet/AspNetCoredotnet/aspnetcore-tooling#5487\n\nCommit migrated from 73858cdd37
- Added the `.vscode-test` to `.gitignore` because that's the VSCode folder that gets created when dynamically downloading VSCode for CI purposes.
- Migrated functional tests to use the non-deprecated VSCode functional testing APIs. This involved creating a runTest file to control downloading VSCode and passing in appropriate parameters as well as creating an index that discovers tests that should be run.
- Changed functional tests to operate on the existing Razor testapps (instead of the old ones).
- Updated the "default" completion tests to be latest Razor/Blazor.
- Added VSCode launch configurations to enable easy debugging via F5.
aspnet/AspNetCoredotnet/aspnetcore-tooling#13494
\n\nCommit migrated from 66e4e8a169
- Added tests for both the language server and the common language server projects.
- Updated publish MSBuild bits to publish to `artifacts/LanguageServer/$(Configuration)/TFM`
- Updated the language server to be netcoreapp3.0
aspnet/AspNetCoredotnet/aspnetcore-tooling#13494
\n\nCommit migrated from 984c638b37
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
* 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
wtgodbe
Ajay Bhargav Baaskaran
N. Taylor Mullen
Ryan Brandenburg
Javier Calvarro Nelson
John Luo
Doug Bunting
dotnet-maestro[bot]
Kevin Pilch
Ryan Nowak
Nick Guerrera
Pranav K
Ryan Nowak