- Tied into VS4Macs ProjectExtensions in order to bootstrap our Razor world.
- We currently watch all DotNet projects with the expectation that they're the only ones that can potentially turn into Razor compatible projects.
- Added a fallback Razor project host which is used for pre-Razor SDK Razor versions (< 2.1).
- Added a default Razor project host which consumes all MSBuild data from the users packages and sets up the Razor world accordingly.
- Had to modify some existing contracts to work better with new expectations. one of these was the VS4Mac specific Workspace accessor; essentially we needed to be able to lookup a workspace from a solution.
- Some of our previous expectations about addins were wrong (not being able to directly reference your libraries). To avoid using reflection to bootstrap our types I tried out directly referencing our libraries and all worked fine.
- Refactored the DefaultRazorProjectHost in windows (since we had to in Mac) for testing purposes.
#2081
Step 1: Add HostProject
This is a somewhat complex addition to the ProjectSnapshotManager. Now
that we accept updates from the underlying IDE project system we need to
coordinate those with the Workspace.
This means that ProjectSnapshot itself now also has a version concept.
Step 2: Introduce a new project system based on CPS
We use project capabilities defined by the Razor SDK to determine
whether to rely on MSBuild evaluation to detect the configuration or
whether to fallback to assembly-based detection.
Step 3: Flow RazorConfiguration everywhere
We use now expose the RazorConfiguration to the language service and
editor. This means that we no longer need to detect the project's
configuration asynchronously, it happens much faster now.
- Updated the a `VisualStudioWorkspaceAccessor` API in windows to enable the factory to retrieve a workspace given a text buffer.
- Added a way to add test services to `AdhocWorkspace` so we can test against services being retrieved from a `Workspace`. This will be much more common once we rely on services coming from `TextBuffer`s in our other tooling pieces.
- Added tests for the default workspace provider.
#1989
- The `ForegroundDispatcher` needed to be accessible by services without requiring a workspace; given that it doesn't have any ties to the `Workspace` other than being a service of one I was able to move it into a MEF service.
- Updated all workspace inclusions of the dispatcher to use importing constructors instead.
- Updated the Mac + Windows implementations to be exported as MEF pieces.
#1979
- Prior to this we weren't overriding the `GetTagHelpersAsync` method resulting in our TagHelper discovery being executed in-process.
- Removed legacy `ITagHelperResolver` legacy types.
- Added a `FileChangeTracker`, `FileChangeTrackerFactory` and corresponding implementations. These types now enable us to implement Windows and Mac file change tracking instead of replacing the entire import manager.
- Changed the import manager to be a Roslyn based service.
- Moved import manager implementation to the editor.razor assembly now since it no longer depends on windows.
- Updated import manager unit tests.
- Added import manager integration test
- Added file change tracking tests.
#1804
- 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
- Moved the `BraceSmartIndenterFactory` into the `Microsoft.VisualStudio.Editor.Razor` assembly so it can be used on Windows and Mac.
- Changed how the factory is exported since its only used internally. It now uses Roslyn services in the context of a Razor language service to be consistent with how the rest of Razor works.
#1789
- Made `RazorTemplateEngineFactoryService`, `TagHelperResolver`, `RazorDiagnosticJsonConverter` and `RazorLanguageServiceException` internal.
- Deleted all items in the Legacy folder in VisualStudio.LanguageServices.Razor and `RazorLanguageServiceException`.
#1762
- Internalized the core implementation of `EditorSettingsManagerInternal`.
- Added a `VisualStudioWorkspaceAccessor` to enable the `Microsoft.VisualStudio.Editor.Razor` project to have access to the current workspace. Only added the Windows specific implementation of this type since the VS for mac implementation will require infrastructural work to make happen.
#1762
- 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`.
- Built a design where there's a singleton `EditorSettingsManager` that handles the "current" settings state in the world. When it detects that settings have changed via an update method being called it dispatches a `Changed` event.
- Exposed editor settings on the document tracker. When the editor settings change the document tracker dispatches to any listeners that its context has changed.
- Added tests to validate all the various settings management.
#1718
- 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
- Added a standalone brace smart indenter that listens to `ITextBuffer` changed events to determine when a brace completion event needs to be handled.
- Added methods to deal with getting document trackers from `ITextBuffer`s.
- Added a `BraceSmartIndenterTest` and `BraceSmartIndenterIntegrationTest` to verify all parts of the smart indenter.
- Moved private test infrastructure classes into their own files and expanded on their functionality to enable the brace completion smart indent scenarios.
#1538
- 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.
The CompletionProvider will be called in cases where the document
doesn't have a FilePath - such as the C# interactive window. This is
causing a null ref.
- Added APIs to retrieve an `ITextBuffer` from a `Document` and to retrieve a `RazorCodeDocument` from an `ITextBuffer`.
- The `RazorCodeDocument` from `ITextBuffer` API supports both the new and old Razor parsers so we can transition seamlessly between the two.
- Added logic in the `RazorDirectiveCompletionProvider` to consume descriptions from `DirectiveDescriptor`s. This is then surfaced via tooltips.
- Retrieved currently active `RazorCodeDocument` given a Roslyn buffer and harvested all directives to display in the completion list.
- Added unit tests to validate each new services functionality.
#291
N. Taylor Mullen
Ajay Bhargav Baaskaran
Ryan Nowak
Nate McMaster