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.
- Renamed `RazorEditorParser` => `VisualStudioRazorParser` (maintained a copy of the original in Legacy)
- Tried to make as little changes as possible to the `BackgroundParser` due to its complexity; mostly just removed the TreeStructureChanged logic since this is re-done on the Razor editor side of things.
- Split the `RazorEditorParserTest`s into two separate tests. Partial parser tests and the VS parsing tests.
- Updated `StringTextSnapshot` to support changes in order to test the VS parser.
#1536
- Added 1_X src project for multitargeting
- Added 1_X test project for multitargeting
- Added 1_X test MvcShim for multitargeting
- Make section directive generate the correct code the appropriate version
- Added another sln
- 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
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.
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.
- Added C# 7 test to validate questionable features work end-to-end.
- Had to add several explicit package references to let our VS specific packages work as expected.
#1046
This is a new API for tooling to call to get a RazorTemplateEngine that's
initialized correctly. For now this is hardcoded to use MVC's conventions.
This is also a very temporary design to get us past the next wave of
changes.
We'll eventually want to change this to an ILanguageService, but this will
require some new plumbing in the editor, so let's defer that for another
day.
(cherry picked from commit a73b5f58a8713076433d24668b99705388b6d6b3)
- 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.
This will log to the VS activity log any time we fail to discovery
taghelpers due to an exception. There's no real user experience around
this... if someone is having an issue we can ask them to send us the log
or post the relevant portion.