* Add net461 TFM to netstandard2.0 projects
* Fix a couple of errors
* Fix some errors
* Get rid of Sockets reference
* Respond to feedback
* net461 -> property
* Fixup clientSample
* Remove net461 from analyzers/razor
* Remove net461 from test projects
* Feedback
* Add net461 test configs
* Remove some incompatible test configs
* Fix test
- Moved from 3.4.0 Roslyn to 3.6.0-3.20168.4 for tooling builds.
- As part of this change I found that our package versions were starting to get really confusing for which Roslyn packages were runtime vs. which ones were tooling. Therefore, I rebranded each of the versions to be `Tooling_` or `Runtime_` accordingly. Moved all `VSIX_` => `Tooling_`.
- Roslyn's bits depended on a newer `StreamJsonRpc`, `Microsoft.VisualStudio.Threading` and `Microsoft.VisualStudio.LanguageServer.Client` packages so updated those dependencies to not have version conflicts.
- This new update brought in loads of new analyzers. Went through the warnings and either applied the fix or suppressed.
- This is in preparation for consuming new pieces from latest Roslyn packages.
\n\nCommit migrated from df5261e418
- Prior to this we would start tracking LSP documents when an `ITextView` was associated with our `ITextBuffer`. The issue with this is when the `ILanguageClient` infrastructure initializes itself before we do and starts our `LanguageServer` it's we start retrieving requests that require access to our `LSPDocumentManager`. That's an issue because our `LSPDocumentManager` may not have been initialized yet resulting in failure to fulfill requests.
- Changed how we initialize `ITextBuffer`s. Before we were setting up all of the logic to change the content type of a text buffer and populate its properties at the `EditorFactory` layer; however, how we were doing it (waiting for the ITextBuffer to load) resulted in `ITextDocumentListener` events firing prior to our content type changes would occur. This is a problem becasue the `ILanguageaClient` infrastructure will start making its decision to turn on LSP features for your `ITextBuffer` at the point and time. Now we change the `ITextBuffer`s content type (and set properties) during the `ITextDocumentListener` created pipeline.
This resulted in almost all of our logic in our editor factory to be split out into two classes.
1. `LSPEditorFeatureDetector`, we needed to be able to detect the "enabledness" of features in two locations. Once at the `EditorFactory` layer to ensure we know when to disallow other editor factories participation in the `ITextBuffer` creation and a second at the `ITextDocumentListener` layer when we inspect an `ITextDocument` and need to determine if we want to "initialize" it (change its content type etc.).
2. `RazorLSPTextDocumentCreatedListener`, this is our `ITextDocumentListener` i've been referring to. It now houses the logic on how to change the content type and populate the `ITextBuffer`'s properties.
- Changed our `LSPDocumentManager` to no longer depend on `ITextView`s for ref counting documents. Instead we just take an `ITextBuffer` and keep an internal count of how many times we've been asked to track a document. In practice this number never goes past 1 however it doesn't hurt to be defensive.
- Added IVT from CodeAnalysis.Razor to our LanguageServerClient project in order to enable the retrieval of our `FilePathComparison` type.
- Given the new refactoring of our feature detector and the `ITextDocumentListener` pieces I was able to add extensive testing to ensure all things work as expected.
Fixes dotnet/aspnetcoredotnet/aspnetcore-tooling#19160
\n\nCommit migrated from d0a7dfce09
- This is a pre-requisite work item to run our language server in-process in Visual Studio. VS is a .NET framework application so we can't have a language server which targets netcoreapp be loaded. Therefore, in order to account for this I needed to re-target our language server library to netstandard2.0 so it can be referenced via a netcoreapp (rzls.exe) and a .NET framework app.
- Added a new `rzls` project to be the maintainer of our OOP language server
- Had to make adjustments to the existing language server project to be compatible with netstandard2.0.
- Created a new `RazorLanguageServer` type to initiate our Language Server but not start and initialize it. To enable a consumer to initialize the new language server I had to use private reflection to `Initialize` O#'s internal type. This is a temporary measure which I intend to expand the O# lib to make their Initialize method public.
dotnet/aspnetcoredotnet/aspnetcore-tooling#19185
\n\nCommit migrated from 79841b9371
- We now do aggressive detection on the type of C# class that's being edited. In order to not impact C# scenarios we only do work if C# assets are available to us. Meaning, we inspect the old document and if that document has its' semantic model available we spend cycles to determine if it's a component. In the case that we find a C# component class that wasn't previously caught we enqueue an update.
- Added several tests to ensure we enqueue and that we properly detect component classes.
aspnet/AspNetCoredotnet/aspnetcore-tooling#14646
\n\nCommit migrated from d8b62e121f
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
- 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
* 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
* 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
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
* Add TagHelperDescriptorProvider
* Remove bad life-choice
* Add some AddRange love
* Add splatting lowering and codegen
* PR feedback
\n\nCommit migrated from 9c8dd1cae7
- WTE needs a way to detect if a `TagHelperDescriptor` is a component based `TagHelper` in order to turn features like validation, completion etc. on/off.
- Updated tests to add verification points for the new `IsRazorComponentTagHelper` method.
\n\nCommit migrated from 6fcd12e60b
* Directive attributes part 1: Support parameters in bound attributes
* update
* Fix test
* feedback
* Updated design
* Do case sensitive comparison
* more
* Bug fix
\n\nCommit migrated from 9bbf240948
Updates the bindtaghelperdescriptorprovider to use the changed event property type name on the bound attribute instead of the value property type attribute.\n\nCommit migrated from 3009045206
- 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
* Support importing components with @using directives
* Suppress taghelper directive completion in component documents
* feedback
* More feedback
* Update tests
* Update CodeAnalysis.Razor tests
* Flow filekind
* Changes
* More code gen tests
* More tests
* fix
* Added more tests
* Made stuff internal
* Filter out temporary tag helper descriptors
* update
* Do the needful
\n\nCommit migrated from 343f37748e
- Added a `FilePathComparison` object since not all string methods allow a comparer.
- Updated `RazorDirectiveCompletionProvider` to also understand `.razor` files. This is an edge case scenario where users have disabled modern completion and are using Razor components (you need a reg key to disable the modern completion or MS needs to disable it).
- Tested this in VS by referencing the latest Razor SDK (preview 3) from NuGet and then replacing the Razor design time targets in VS to be the ones from the preview 3 package.
- Added workspace project state change detector tests.
dotnet/aspnetcore-tooling#8064
\n\nCommit migrated from 6a83ed13fc
- The `DocumentWriter` case should never be called because you need to override a lot of the internals of the RazorEngine to get to the document writer. Therefore, little harm in removing the method.
- `ProjectChangeEventArgs` used to be uised by the LiveShare extension. We've since taken ownership of those bits and no longer need to maintain those constructors.
- `DefaultTagHelperDescriptorProvider.DesignTime` didn't actually do anything. Removing since the code was truly dead and did nothing functionally.
dotnet/aspnetcore-tooling#7146
\n\nCommit migrated from ba6450a695
* Add new APIs to ComponentShim
* Add new APIs to ComponentsApi
* Add EventCallback metadata
* Add discovery of EventCallback properties
* Errata for Runtime APIs
* Add ability to use EventCallback as parameter
* Add support for bind to component
* Use EventCallback for bind-... to elements
* Use EventCallback<T> for event handlers
\n\nCommit migrated from a0b6bc0e52
Kevin Pilch
Steve Sanderson
William Godbe
John Luo
Tanay Parikh
N. Taylor Mullen
Ajay Bhargav B
Ryan Brandenburg
Ajay Bhargav Baaskaran
Ryan Nowak
Ryan Nowak
Nate McMaster
Javier Calvarro Nelson