- Exposed `VisualStudioRazorParser`, `DocumentStructureChangedEventArgs` and `ICanHasContextChangedListener` as ways to consume the new parser for a Razor document.
- Split the `VisualStudioRazorParser` into an abstract base and an implementation to avoid internal constructors.
- Changed the parser and corresponding smart indenter to take in document trackers, template engine factories and parser context change listeners. Of these additions the parser context change listeners will be deprecated once we own the TagHelper discovery mechanisms.
- Changed how the parser manages its internal parsing life cycle. It now creates template engines when the document tracker tells it to. So when project changes happen or new documents are opened the parser will re-instantiate its internal parser to ensure that it is parsing against the correct configurations.
- Removed all accessor services in favor of a singular RazorEditorFactoryService. This service is responsible for retrieving/creating various Razor components.
- Changed the code document provider to now use the parser provider in order to locate code documents associated with buffers. Prior to this that logic was hard coded.
- Removed old template engine reconstruction logic in the document tracker now that the parser owns that piece.
- Updated tracker to notify listeners when it's unsubscribing. This is how listeners can know when to tear bits down.
- Refactored/added pieces to the `DefaultVisualStudioRazorParser` in order to improve its unit/integration testing ability.
- Updated existing tests to react to new signatures.
- Added new visual studio razor parser tests, uncommented existing ones, and re-enforced ones that were previously flakey.
- Added various tests for the new services added, i.e. text buffer factory service tests.
#1630
- As part of this work I also added `Microsoft.VisualStudio.Mac.LanguageServices.Razor` to be the Visual Studio for Mac specific Razor code.
- Added MSBuild infrastructure to automate creation of MonoDevelop addins (MPacks). This work enables us to not have a dependency on a specific version of monodevelop and does not require us to have tool-prerequisites on the box. Every build outputs the mpacks into the artifacts/build directory.
- Built in build-level metadata pieces to workaround how addins are typically developed. They are usually authored C# first and then config files are generated after the fact; with this changeset we auto-generate the addin.info and its corresponding assembly attributes. Both of these take information directly from the build system.
#1696
- Created a new `Microsoft.VisualStudio.Editor.Razor` assembly to contain Visual Studio platform agnostic info.
- Added a new `Microsoft.VisualStudio.Editor.Razor.Test.Common` project to be the centerfold for all VisualStudio agnostic test pieces.
- Added a `Microsoft.VisualStudio.Editor.Razor.Test` project and pulled in LanguageService test files into the the Editor.Razor.Test project to correspond to their movement in the src project.
#1690
This change adds an actual background worker for listening to project
change notifications and starts sending updates when the project's razor
dependencies change.
I had to do a litle surgery to get things working. There were plenty of
small bug fixes.
Additionally I got rid of the WeakReferences for tracking listeners. I
was seeing TextBuffers hanging around in VS longer than I expected and
the WeakReferences weren't getting cleaned up. I think it's better that
we just track the lifetime.
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.
This enables the tracking of events that change the 'razor' state of a
document that's open in the editor.
Also fixed a crash that can occur when creating a new project with the
Razor Info window open.
- 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
Also did some spring cleaning on redundent references in the language
services package.
Note that the 'immutable' packages are now totally redundant with
Shell.15.0. You're supposed to use one or the other. Since our minimum VS
is 15, I just went with shell 15.0.
Now the VSIX project doesn't have many references in it.
- Replaced the magic strings with extension methods that produce the same behavior as the string keys did.
- Added tests to validate new extension methods.
#1307
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
VS has gone RTM so, updating to the RTM versions of those dependencies.
Roslyn does not publish our shim packages on NuGet.org, so updating those
to a non-ancient version for projects that use 2.0.0. The projects that
use 1.3.x are staying put for now.
The code change is dealing with something that was obsoleted.
Nate McMaster
N. Taylor Mullen
Ryan Nowak
Ajay Bhargav Baaskaran
Nate McMaster
Ryan Brandenburg
Mike Harder
Pranav K