This is failing on the CI due to an issue with a newer build of the SDK.
I opened https://github.com/dotnet/sdk/issues/1854 to track the SDK bug.
- update korebuild
- upgrade deps
- remove System.Diagnostics.DiagnosticSource from test projects
I noticed we were really undertesting all of the things that handle
paths and file names. I gave this some love and a little clean up where
we weren't doing the right thing in RazorSourceDocument.
Also changed the template engine tests to use the
FileSystemRazorProject. These tests are already using the files on disk
as inputs. I turned off checksums for these since they now have the full
file path, and that would not be portable.
Using the MVC view engine convention for identifiers seems to make the
most sense, and we already use that convention for RazorProject so I
guess we're stuck with it.
Adding this via a properties object that encompasses all of the optional
properties. This way if we need to add more items that are optional we
can continue to do so without overload explosion.
* Add metadata to Razor
This PR introduces standard metadata to Razor. This change begins to
formalize the contract between generated code produced by Razor and
runtimes that want to load and interact with this code.
This is a step on making MVC a 'plugin' to Razor rather than the only
possible implementation. Since we're doing MSBuild work - this is the
right time to designate the current interaction between Razor and MVC as
'legacy' and move forward.
Additionally, we need the source thumbprinting to make re-compilation of
Razor a thing.
-----
Also I noticed that our source document doesn't expose the hash
algorithm by name. We really should have this, so I added it and
hardened the code that deals with checksums in c# generation.
- Already had a good variety of integration tests so refactored the service to properly unit test each piece.
- Found several pieces of unneeded code (wasn't being used) so removed it.
- Removed the `LocateOwner` logic that was embedded in the service. We already have an equivalent locate owner on our `SyntaxTreeNode` items.
#1698
- Changed `DefaultRazorDiagnostic` to expose a little more information for tests. This info is only available when casted to the `DefaultRazorDiagnostic` type and only available internally.
- Changed parameter order of a `DefaultTagHelperTargetExtension` diagnostic.
- Updated baselines of files in `Razor.Language.Test`.
- Added a new convenience constructor on `SourceSpan`. The ctor is equivalent to calling the class with a SourceLocation.
#1827
Microsoft.AspNetCore.Razor becomes the home for TagHelper-related types
that you use in your code.
Microsoft.AspNetCore.Razor.Runtime becomes the home type types you need
to build a view engine. User code should not need this package anymore.
None of these are breaking changes due to typeforwards.
- Added a Mac specific implementation of the project build change trigger. It applies to all types of project builds so we need to do a little extra filtering to ensure that we're not operating on a non-ASP.NET Core project.
- Added tests to validate that the project build event fires correctly.
#1851
This PR adds two new tools as well as a tasks project. None of these
projects produce a package and they ship as part of
Microsoft.AspNetCore.Razor.Design. For now this is a 'fat' package that
contains all of the dependencies, but we plan to strip them out in the
future.
The support for compilation at build-time will start as **off** by
default. The immediate goal here is to get this to flow through the
build so that we can test it as part of the inner loop effort. We will
enable this feature by default once we've done more thorough testing.
Since this is mostly a code dump, I plan to address blocking and minor
feedback only. If there are design issues that are non-critical, I will
open follow up items.
The next step will be to start adding more detailed tests.
- 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
This is the first step in adding support for Razor compilation at build
time. Additional steps will complete this by adding tag helper
discovery, code generation and finally a call to CsC.
I want to get this in now to get the package into the build system and
to lay down the general infrastructure for testing.
---
The strategy for testing here is to use checked in projects that have
everything Razor needs to compile code. We already have shims for the
APIs Razor uses by default in this repo and I'm using them in the
project.
The test infrastructure creates a temporary directory, copies the
project, and fixes up a few small things to cooperate with outputs we've
already built so that the test can use the new versions of Razor bits
built from this repo.
We can then call various MSBuild targets and verify the files on disk. I
envision tests that verify incrementalism as well as the basic E2E.
We will test the E2E in general in other places, since it's part of the
new default experience. This repo will test things at a higher level of
detail, but in slightly artifical scenarios.
- Added a LanguageServices Mac test project.
- Added a few tests for the new `DefaultFileChangeTracker`. There's currently an issue with the MonoDevelop.Core binaries we're compiling against which doesn't allow me to unit test other pieces of the class (they depend on instantiating mono develop objects).
- Added IVT from product projects to new mac testing project.
#1789
- 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
- This test was flaky due to the nature of what it was testing and had negative value due to the testing complexities. In the integration test pieces (running VS) this is already tested thoroughly.
- Prior to this change the code document provider took in many sub-providers to allow for understanding of the old RazorEditorParser AND VisualStudioRazorParser. Now that RazorEditorParser is gone we can also change the code doc provider.
- Prior to this the old code document provider would utilize the editor factory service which would incorrectly create a parser for older Razor documents. This was wrong on many levels.
- Updated tests to react to new expectations.
- Moved service poco types: `AttributeCompletionContext`, `AttributeCompletionResult`, `ElementCompletionContext` and `ElementCompletionResult`.
- Exported DefaultTagHelperCompletionService.
#1762
- Created a `TagHelperFactsServiceInternal` and export its public counterpart in `Microsoft.VisualStudio.Editor.Razor`.
- Updated tests to react to new naming.
#1762
- Made `RazorTemplateEngineFactoryService`, `TagHelperResolver`, `RazorDiagnosticJsonConverter` and `RazorLanguageServiceException` internal.
- Deleted all items in the Legacy folder in VisualStudio.LanguageServices.Razor and `RazorLanguageServiceException`.
#1762
- Removed indentation service extensions and made `GetDesiredIndentation` understand `ITextSnapshot`s and `ITextLineSnapshot`.
- Updated our test `StringTextSnapshot` implementation to have the required features our indentation tests require.
- Updated indentation service tests to use new API.
#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
- 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`.
- 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
* RazorPageGenerator: extracted creating RazorEngine into a method to simplify reusing logic in custom generators
RazorPageGenerator: added optional cli argument with base directory (previously current dir always was used)
- 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.
- 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
Pranav K
Ryan Nowak
N. Taylor Mullen
Ajay Bhargav Baaskaran
Nate McMaster
Sergei Dorogin