The project snapshot now maintains a RazorProjectEngine as well as set
of Tag Helpers that are known for that snapshot.
Pivoted some more services to be snapshot-centric.
Also added the ability to track .cshtml documents to the project system.
For now most components just ignore document changes.
- Strings here was important because any import added to the system dynamically needs to eventually make its way back to being a project item. With strings we can state that they do exist (have content) but do not have any file paths associated.
- Updated all call sites to use the new AddDefaultImports string based api.
#2080
- Updated all implementations of `IImportProjectFeature`; for MVC I went ahead and made a single project item that's always returned for MVC scenarios. That project item is smart about returning its content in a light-weight stream fashion.
- Had to add a `RazorProjectItem` => `RazorSourceDocument` conversion mechanic into `DefaultRazorProjectEngine`.
- Added tests for `DefaultRazorProjectItem.ConvertToSourceDocument`.
- Removed the `ProjectEngine` API from `VisualStudioRazorParser`. This was unrelated but was missed feedback.
#2068
- Instead of using Razor/Mvc TemplateEngine use `RazorProjectEngine`. This involved changing several locations (each of which used `RazorTemplateEngine` in an entirely different way) to use the RazorProjectEngine's two Process methods.
- Changed an unused public API `VisualStudioRazorParser.TemplateEngine` to `VisualStudioRazorParser.RazorProjectEngine`.
- Ported the remainder of `RazorEngineBuilder`'s extension methods over to `RazorProjectEngineBuilder`. These were used in tests and our `RazorGenerate` tool.
- Added a few test helper methods/classes to enable simple testing of the `RazorProjectEngine`.
- Resolved several test hacks that were working around little discrepancies each of the `RazorTemplateEngine` APIs.
- Changed the template engine factory service to be a project engine factory service.
- Changed all existing APIs to utilize `RazorProjectFileSystem`. This was possible because `RazorProjectFileSystem` inherits from RazorProject.
- Renamed `FileSystemRazorProject` to `DefaultRazorProjectFileSystem`.
- Renamed FileSystemRazorProjectItem` to `DefaultRazorProjectItem`.
- Obsoleted `RazorProject.Create`
#1828
- Prior to this when the partial parser would successfully parse a change we'd mutate the returned syntax tree so any data inquired about the tree would then be wrong. We now isolate mutations to copied versions of the syntax tree.
- Added copy tests to ensure that we were appropriately copying all the various syntax node types.
#1793
- Removed the `Microsoft.VisualStudio.Language.IntelliSense` dependency from `Microsoft.VisualStudio.Editor.Razor` because it isn't supported in VS for mac.
- Replaced `ICompletionBroker` usage in the VS agnostic dll with a new abstract type `VisualStudioCompletionBroker`. This also enables us to implement completion
- Added Mac implementation of new `VisualStudioCompletionBroker`.
#1789
- Had to add extra logic to track document structure changes so listeners could know if an event was on its way or not.
- Added and fixed some tests.
#1748
- Changed `ReparseAsync` to be `QueueReparse`. It's now async void to not give the misconception that it blocks until a reparse has been completed.
- Removed `IContextChangedListener`. People can get the same effect of the interface by retrieving the document tracker interface via the `RazorEditorFactoryService` and then when its context changes getting the parser.
- Exposed `TryGetParser` to aid in replacing `IContextChangedListener`.
- Updated tests to not rely on `IContextChangedListener`.
- 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
Ryan Nowak
N. Taylor Mullen