- 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
Adds the code generation support for culture + bind.
Some additonal changes are needed for the compiler support for bind, we
need to pass the culture into the code that unwraps the value as well.
There's no need to eagerly push these changes into the runtime (can wait
for the compiler change to go in) because nothing in our runtime tests
use the new feature.
\n\nCommit migrated from 6aad9748e8
Adds the ability to specify that an `<input type="..." />` for some
specific value of `type` maps to the invariant culture and/or provides
a default format.
The primary examples of usage would be the number field which wants to
use invariant culture, or datetime which wants to use invariant culture
and a format string.
\n\nCommit migrated from 60f2d563a6
Updates our Components shim to use the ref assembly code. This is just
cleanup and will help us keep up-to-date with API review changes since
we can just copy-past the files.
I made two modifications to make this simple.
- Removed our built-in components
- Removed the HTTP stuff
This makes it easier for us to maintain the shim. You can see cases
where I had to update tests because they diverged from what the real
APIs look like (no product bugs).
I'd still like to improve this workflow so suggestions wanted xD
\n\nCommit migrated from 8517be2bac
This change makes @ref define a field for you by default. We didn't do
this originally because we weren't sure if the compiler generating a
field would always be what you want, and more importantly,
we didn't have the expressiveness to add an opt-out.
Now that we have directive attributes, it's easy to create an opt-out
for the field generation. The special thing about it is that where
you opt-out has to be static. For this reason the @bind:suppressField
attribute cannot be used with a value, you either have the flag or not.
Additionally, we don't support automatic field generation for
generics, because usually we can't write the field name. If we
want to in the future could make this work when the generic
type arguments are specified. So in the case of generics,
you have to opt-out, and you will get a diagnostic
that tells you so.\n\nCommit migrated from dadf9faf22
Currently FindAssembliesWithReferencesTo produces a stacktrace when P2P builds fail - for instance
if the referenced project has a compiler error. This changes it to use LogErrorFromException.
In addition, there was a typo in the property that disabled the feature.
Fixes https://github.com/aspnet/AspNetCore/issues/11226\n\nCommit migrated from 87c12a116c
- add feeds that SDK no longer provides automatically when building test apps
- add another allowed build warning in some integration tests\n\nCommit migrated from cfd4698381
* Add TagHelperDescriptorProvider
* Remove bad life-choice
* Add some AddRange love
* Add splatting lowering and codegen
* PR feedback
\n\nCommit migrated from 9c8dd1cae7
* Allow @bind:event override when used with @bind
* Added more tests to cover standalone @bind-value=... case
* fix
\n\nCommit migrated from a399bd072e
- It looks that when we first did VCTH we never put in the effort to reduce our footprint on available parameters for `ViewComponentTagHelper`s. I went ahead and added several underscores to the generated fields/parameters to reduce collisions.
- Updated tests to reflect the new codegen.
aspnet/AspNetCoredotnet/aspnetcore-tooling#8645
\n\nCommit migrated from b545a4de75
Pranav K
Ajay Bhargav Baaskaran
N. Taylor Mullen
Ryan Nowak
Ryan Nowak
David Fowler
Javier Calvarro Nelson
Doug Bunting
Steve Sanderson