This uses a feature of KoreBuild which will select PackageReference
versions based on a lineup file. This helps unify versions between repos
and helps us ensure we are consistent across multiple components.
I've stripped out some of the dead code and complexity from the document
tracker in an attempt to simplify it. I will bring this back as part of
the multi-targeting work.
- Added `ILanguageServiceFactory` types for all serviceable contracts.
- Maintained binary compatibility by copy/pasting existing services into a Legacy folder.
- Added a Workspaces.Test project since their implementations moved.
- Updated binary incompatible version of `RazorSyntaxFactsService` to not depend on VisualStudio. Added an extension type to the VS.LanguageServices.Razor project to enable easy-access from VisualStudio.
Below on refers to the binary incompatible copies.
Core services that were **entirely** moved from VisualStudio.Razor => Razor.Workspaces are as follows:
- `RazorSyntaxFactsService`, this included mutating the API to not depend on VisualStudio and moving some primitive types such as `AcceptedCharacters`.
- `TagHelperCompletionService`
- `TagHelperFactsService`
These all have a `ServiceLayer` of `Editor`.
Bits that were partially moved:
- `RazorTemplateEngineFactoryService`. The Default implementation and its corresponding factory still live in VisualStudio.Razor. This way Razor.Workspaces can get by without a reference to Mvc.Razor.Extensions.
- `ITagHelperResolver` used to exist in VisualStudio.Razor. Removed the type and replaced its usage with the already-existing `TagHelperResolver` type in Razor.Workspaces. Both contracts were nearly identical.
These all have a `ServiceLayer` of `Default`.
#1260
- Re-enabled api check for `Microsoft.AspNetCore.Razor` and `Microsoft.AspNetCore.Razor.Runtime`. This resulted in me adding known breaking changes for the packages.
- Added empty baseline files for `Microsoft.AspNetCore.Razor.Language`, `Microsoft.AspNetCore.Mvc.Razor.Extensions` and `Microsoft.CodeAnalysis.Razor`.
- Disabled ApiCheck for `Microsoft.CodeAnalysis.Razor.Workspaces`, `Microsoft.CodeAnalysis.Remote.Razor`, `RazorPageGenerator` and `Microsoft.VisualStudio.LanguageServices.Razor` to prevent ApiCheck warnings about missing baselines.
#1107
This change adds an API for Tag Helper discovery.
I also got rid of the 'design time' flag for the provider as an
experimental change. We need to think through the consequences of this
before committing to it. Right now I've left those tests failing until we
can make a decision.
This change decouples VCTH discovery a bit more, but we're still not ready
to move that into a the MVC extensions assembly. For that we need the
ability to discover the MVC extensibility.
This is a MEF service that can actively or passively track open ITextViews
and give us information about the Razor initialization state and eventing
when it changes.
The purpose of this is to act as a bridge between the VS mef world and the
roslyn world.
For now this doesn't do any passive tracking of Razor documents, it's only
on demand. That means it will only be initialized and used right now when
you are using the Razor developer tools. This is just to reduce our risk,
it's not ideal to ship code in VS that's doing something without anyone
looking at the result.
- Removed all design time descriptors and put their API surface into their corresponding descriptor. Part of removing the design time API surface was removing the tracking of `<Remarks>`, it wasn't used so there's on need to track it until we need it.
- Removed the Type requirement from `TagHelperDescriptor`. With this separation we'll be able to have abstract `TagHelper`s that aren't based on a class implementation.
- Removed Prefix from the `TagHelperDescriptor` API surface. It was a legacy requirement based on how the Razor parser was put together. We can work around this now.
- Stripped correlation information from the immediate `TagHelperDescriptor` API surface. Instead this information is now tracked in `TagMatchingRule`s. This change means that you will not have multiple `TagHelperDescriptor`s per `TagHelper`; instead it's all tracked in a single descriptor. A side effect of this change was the transformation of `IsIndexer` => 3 new properties.
- Renamed many descriptor types and property names.
- Added builder APIs to construct TagHelpers since they're inherently immutable in their API surface.
- Added `ITagHelperDescriptorBuilder` to represent `TagHelper`s that are built from an `ITagHelper` implementing class. It re-introduces the `TypeName` association of a `TagHelper`.
- Added `ITagHelperBoundAttributeDescriptorBuilder` to represent that an attribute was associated with a property.
- Added validation methods to the descriptor builders to enable consumers to validate the current state of the builder and add diagnostics as necessary.
- Moved descriptors away from RazorError.
- Updated the various comparers to understand the descriptors new API.
- Added a new `RazorDiagnosticFactory` abstraction to handle `RazorDiagnostic`s and their corresponding errors/ids etc. This new API should allow for easy addition of new `RazorDiagnostic` errors.
- Updated the `DefaultTagHelperDescriptorFactory` to construct `TagHelperDescriptor`s using the new builder APIs and in the new descriptor format (1 descriptor per type).
- Updated `ViewComponentTagHelperDescriptorFactory` to construct `TagHelperDescriptor`s with the builder API.
- With both factory implementations code was duplicated because the ViewComponent work will be moving outside of Razor once we have the proper hooks.
- Updated `TagHelper` binding bits to capture a binding result in order to query which rules appy to a given tag name.
Addressed feedback
- Update tests to react to new `TagHelperDescriptor` API.
- Remove case sensitive comparers and some cleanup
- Added TagHelperDescriptorJsonConverter, RazorDiagnosticJsonConverter and added serialization tests
The issue here is that the OOP host doesn't yet have support for
documentation, it will just return null. Fixing this code to look for the
documentation after we get the descriptors back into VS.
I tested this and confirmed that it works with TagHelpers in dlls + xml
file documenation as well as TagHelpers compiled in the project itself.
- Decided to not expose the resolutions errors in the Razor extension. If we feel that it's good debug information we can add it later.
- Added a `TagHelperResolutionResult` type to Razor.Workspaces so it can be used in the language and remote service.
#1014
We're close to hooking up new Razor to MVC. This is a set of enabling
'quick fix' changes to resolve some blockers to using Razor.Evolution in
the product.
Main issues:
- Types not public enough - anything in the .Legacy namespace is still
slated from 'improvement'
- Wrong references. We don't want .Workspaces in MVC, so moving the heavy
lifting of TagHelper discovery to CodeAnalysis.Razor.
- Hardcoded `ViewComponent` discovery.
- Hardcoded `ViewComponentTagHelperDescriptor` creation.
- Added test to validate that ViewComponents are discovered and transitioned into TagHelpers properly.
- Avoided adding a reference to MVC to prevent circular references. This resulted in custom marker attributes to represent `ViewComponent`s. Also made a lot of use of `ViewComponent` conventions (ending in "ViewComponent").
#932
- Ported the existing descriptor factory tests and fixed issues with the current implementation.
- Ported documentation tests with the exception of the localization variants.
- Updated the DefaultTagHelperResolver to filter TagHelper types based on accessibility.
- Added DefaultTagHelperResolver tests.
#851
Ajay Bhargav Baaskaran
Nate McMaster
Ryan Nowak
Nate McMaster
N. Taylor Mullen
Ryan Brandenburg
Kiran Challa
Mike Harder
Pranav K