* 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
- Directives utilize helpers to add to colorization errors, etc. in Razor files. These helpers typically look like `MyType __something = default(MyType)`. The issue with this approach is that `default(MyType)` can be `null` yet `MyType` is a non-nullable type. To workaround this restriction I added nulllability forgiveness operators to the type and member directive tokens (the only two that could possibly generate `null` based output).
- Updated baselines to reflect new forgiveness operator.
aspnet/AspNetCoredotnet/aspnetcore-tooling#10919
aspnet/AspNetCoredotnet/aspnetcore-tooling#11478
\n\nCommit migrated from d0617ed578
- Updated `BuildVariables` to lift the `Microsoft.Net.Compilers.Toolset` package version into C# so we can pass it as a parameter to our testapps when building them.
- Flowed the `MicrosoftNetCompilersToolsetPackageVersion` to transitive testapp projects on restore. This enables `build.cmd` to properly pre-build our `testapp` projects with the latest version of Roslyn.
- Added several conditions to detect if a user is attempting to independently build a `testapp` at which point we fallback to using the SDKs Roslyn compiler toolset version.
aspnet/AspNetCoredotnet/aspnetcore-tooling#12268
\n\nCommit migrated from 57a72ecc46
* Correctly set UpToDateReloadFileTypes
UpToDateReloadFileTypes was incorrectly set in the preview6 DesignTime targets and this was worked
around in the SDK's targets. Unfortunately the updated copy of DesignTime targets (current as of 7/13)
also has a bug.
This fixes the issue and adds some tests to verify we're correct with the past, present & future.
Fixes https://github.com/aspnet/AspNetCore/issues/11873
\n\nCommit migrated from 525d0c1ad3
I noticed this while debugging something else in VS. It looks like the
service hub is using camelCase, which wasn't covered with a diagnostic
in our tests. As a result we would fail to read the data from the OOP
host, and fall back to in-process tag helper discovery.
\n\nCommit migrated from 63b25dbd2d
* Fix weakly-typed component bind
The globalization change regressed this. For weakly typed component bind
we don't want to do any conversions, we need the values to match
exactly.
Note that there's no compiler-generated type checks because its
weakly-typed.
* pr feedback
\n\nCommit migrated from 2d74721815
- This is a temporary workaround until we're able to get on the latest SDK which includes the latest Roslyn bits. Without them we can't properly publish testapps in a standalone fashion without investing in temporary infrastructure.
\n\nCommit migrated from 21fcd9c2f5
- Verified the fix with VS16.2-preview2 + latest CLI with modified `Nullable` entry on disk
- Updated tests.
- Note: This change will not pass the build until we have a new CLI that has an updated Roslyn that understands `Nullable`.
aspnet/AspNetCoredotnet/aspnetcore-tooling#10218
\n\nCommit migrated from fee9c35bee
* Update ref assembly APIs
There are some impactful changes here for the compiler that are part of the API review.
The next few commits will implement all of the required changes.
* React to API review + globalization changes
* Updates to generated baselines
* Add missed file
* Update src/Razor/src/Microsoft.CodeAnalysis.Razor/EventHandlerTagHelperDescriptorProvider.cs
Co-Authored-By: Steve Sanderson <SteveSandersonMS@users.noreply.github.com>
* more baseline updates
\n\nCommit migrated from d955be5013
* Make some tweaks to the default content globs
- Don't publish/copy launchSettings.json
- Make sure static content and configuration work with single file turned on
- Added test
\n\nCommit migrated from 63e8681fff
* Modify tag helper infrastructure to configure case sensitivity
* Cleanup and added more tests
* More cleanup and added necessary diagnostics
* More feedback
* Added more tests
\n\nCommit migrated from 20b8286751
- Updated existing tests to use `public` accessibility for parameters. As part of this also updated baselines.
- We now recommend that `[Parameter]`'s should be `public`. In the future this will be a requirement.
aspnet/AspNetCoredotnet/aspnetcore-tooling#8825
\n\nCommit migrated from 2ceb597f82
- Without this any diagnostics from Analyzers will be doubly reported. One for the declaration compilation and one for the view compilation.
aspnet/AspNetCoredotnet/aspnetcore-tooling#8825
\n\nCommit migrated from 6d115d460b
- Added a feature flag to ensure this functionality does not impact pre-3.0 applications. This change is in fact a breaking change because some less-common scenarios will no longer be valid. For instance, `@Name!.Hello`used to treat the `!.Hello` as markup, now it will be treated as part of the expression.ExpressionChunkGenerator
- Updated parser flags tests
- Updated parser tests
- Updated the C# 8.0 integration tests to include the new nullable forgiveness scenarios.
aspnet/AspNetCoredotnet/aspnetcore-tooling#11188
\n\nCommit migrated from 625c605607
This fixes a regression in the new `@ref` support, where the build will
fail during the declaration pass.
The problem is that the EliminateMethodBodyPass runs really early and
wipes out the usage of `@ref` before we have a chance to see it. The
solution is to make it run really late. This makes sense because we
basically just use this pass to do cleanup.
\n\nCommit migrated from 09b50151ef