* Merging changes (from dev branch; doing manually to squash them really)of HTML Parser to be aware of HTML Comments so TagHelpers don't complain about comments as content.
- For older version of Razor the HTML comments will be complained about by TahHelperRewriter
- RazorParserFeatureFlags tests now ensure that AllowHtmlCommentsInTagHelpers is true in 2.1 version and false in older versions
- Added extra test for IsHtmlCommentAhead to make sure Razor code transition is allowed in comment tag
- Moved the unallowed html comment ending to a static array.
Since the default tag helper provider is used by MVC then MVC should
include it. Now that Blazor is in the mix we shouldn't include it for
all configurations.
- Existent imports are imports that have content that contribute to the processing of a Razor document. Prior to this we had a legacy expectation that code documents had empty markers in them for all of their import locations. This proved troublesome when cross-referencing files that had file paths and were supposed to be existent but weren't in metadata. Now that we have a project engine with a de-coupled import feature we can rely on the import feature for finding all locations of important files and then strip out any non-existent items.
- 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
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.
Adds a loader (with shadow copying in server mode) based on the Roslyn
Analyzer loader design.
Adds some targets to the Razor SDK that we can use to compute the
configuration and extensions.
Passes all of the metadata through to the command line tools so they can
deal with extensions.
- 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.
This change makes it so that we no longer create 'design time' engines.
The choice of design time or runtime is made when we initiate a code
generation operation.
Options instances are now created as part of the CodeDocument
initialization. Our existing code can still be created using a
RazorEngine so our passes that initialize the options still support the
old code path.
- Removed the `Process(string)` overload to make it extra clear that you must operate on project items. This way we also don't need to worry about the various formats of paths that can flow through the system.
- Updated tests to use the new project item format.
- Did a few formatting fixes on unrealted files.
#2049
- 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
* Move path munging in to Razor SDK
* Use AssignTargetPath to determine the target path for outputs and embedded resources
Fixes#1829Fixes#1847Fixes#1999
* Add prelimianry support for extensions to Razor
This PR adds MSBuild insfrastructure to the SDK that can understand
concepts we need to expose to the project, code generator and runtime
like:
- Language version
- Configuration
- Extensions (plugins)
As an example of how this works, I've done the wireup for MVC. This will
now generate assembly attributes in your application that can act as a
source-of-truth for what should be included in runtime compilation, and
it's all based on the project-file. This means that it can be delivered
and configured by packages.
The next step here is to implement a loader for RazorProjectEngine based
on these primitives, and then use it in our CLI tools and MVC.
The next step after that is to expose it in VS and VS4Mac through the
project system.
(cherry picked from commit 5b28c06d64)
* Add prelimianry support for extensions to Razor
This PR adds MSBuild insfrastructure to the SDK that can understand
concepts we need to expose to the project, code generator and runtime
like:
- Language version
- Configuration
- Extensions (plugins)
As an example of how this works, I've done the wireup for MVC. This will
now generate assembly attributes in your application that can act as a
source-of-truth for what should be included in runtime compilation, and
it's all based on the project-file. This means that it can be delivered
and configured by packages.
The next step here is to implement a loader for RazorProjectEngine based
on these primitives, and then use it in our CLI tools and MVC.
The next step after that is to expose it in VS and VS4Mac through the
project system.
- In this PR we do away with `CreateDesignTime` on the `RazorProjectEngine`. Instead we now have an overload that takes in a configuration and does the right thing.
- Updated `RazorProjectEngineBuilder` to have a configuration.
- Updated `RazorConfiguration` to only have a `Default`. Setting up a razor configuration for design time now requires calling code to construct the configuration manually.
- Restructured RazorLanguageVersion to be a sealed concrete type to enable things like `RazorLanguageVersion.Latest`; it also allows us to make broader changes in the future. Also, in the future if we want to add support for overriding operators to enable greater than comparisons we can as well.
- Removed version validity checks because we restrict who can construct a `RazorLanguageVersion` now. This way we don't have to check for valid versions all throughout our code.
- Added a simple `ProjectExtensibilityConfiguration` => `RazorLanguageVersion` method in the `DefaultProjectExtensibilityConfigurationFactory` to temporarily enable letting the system operate on the `RazorLanguageVersion`. Eventually that entire class will change.
#1961
- Make `RazorProjectEngine` call paths for all feature registrations.
- Add `DefaultMvcImportFeature` for latest and 1.X MVC.
- Ported `AddTargetExtension` and `AddDirective` to `RazorProjectEngineBuilderExtensions`.
- Added tests and a test file system project type.
- Moved obsolete `IRazorEngineBuilder` methods to the bottom of each file. Will actually obsolete the methods once `RazorProjectEngine` is working end-to-end.
#1828
- Restructured RazorLanguageVersion to be a sealed concrete type to enable things like `RazorLanguageVersion.Latest`; it also allows us to make broader changes in the future. Also, in the future if we want to add support for overriding operators to enable greater than comparisons we can as well.
- Removed version validity checks because we restrict who can construct a `RazorLanguageVersion` now. This way we don't have to check for valid versions all throughout our code.
- Added a simple `ProjectExtensibilityConfiguration` => `RazorLanguageVersion` method in the `DefaultProjectExtensibilityConfigurationFactory` to temporarily enable letting the system operate on the `RazorLanguageVersion`. Eventually that entire class will change.
#1961
- These contracts introduce a new `RazorProjectEngine` concept which allows for users to configure 1 entity that's responsible for the RazorEngine and project.
- The `RazorProjectEngineBuilder` has a collection of features that are dispersed on the created `RazorEngine` and the `RazorProjectEngine`.
- Included a complete implementation of `RazorProjectEngine` it introduces the extension points for the project engine. The primary one includes the `IRazorImportFeature`, the default behavior is to return 0 imports.
- Included a complete project engine builder implementation.
#1828
- Part of caching length required the `Span`'s `ReplaceWith` method to propagate its changes to its parent so that it can propogate the change to invalidate all parent length caches.
- Added Span and Block tests to validate the interaction of caching.
#1927
- Part of caching length required the `Span`'s `ReplaceWith` method to propagate its changes to its parent so that it can propogate the change to invalidate all parent length caches.
- Added Span and Block tests to validate the interaction of caching.
#1927
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.
- 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
- 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
- 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
- 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
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.
Ajay Bhargav Baaskaran
Ryan Nowak
Pranav K
Ryan Brandenburg
Artak
Artak Mkrtchyan
N. Taylor Mullen
Nate McMaster
Rustam Agametov
Javier Calvarro Nelson