Gives our generated a files an extension that isn't used for any other
purpose (that we know of). This is handy for tooling to be able to
quickly know if a file is 'ours'. This comes up in places like
IVsSymbolicNavigationNotify (go to definition).
* 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.
- 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
Razor AddIn generation of C# projection content inside .cshtml depends on code completion being visible hence it needs to know state.
Since we are using Roslyn code completion API which doesn't have method to check if code completion is visible and also it's internal, only other way would be to make some public static field inside CSharpBinding which indicates visibility of code completion, hence it's better to just store this value inside textView.Properties. We should be able to remove this in 15.8 when we switch to new VSEditor code completion API.
- 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.
* Add support for generating attributes on Razor assembly
* Generate ProvideApplicationPartFactoryAttribute on Razor assembly
* Generate RelatedAssemblyAttribute on application assembly
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.
* Update path calculation for BuiltProjectOutputGroupOutput to include full path. This matches
the behavior of Microsoft.Common.targets.
* Add Razor symbols to DebugSymbolsProjectOutputGroupOutput
Fixes#2116
- 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.
* WebSdk transitions
* Add a reference to Microsoft.Net.Sdk if it wasn't previously referenced
* Move PreserveCompilationContext in to our target
* Remove use of transition property
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.
* Add a reference to Microsoft.Net.Sdk if it wasn't previously referenced
* Move PreserveCompilationContext in to our target
* Remove use of transition property
- 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.
- Updated the `DefaultRazorDocumentManager` to also not be a workspace service. It didn't end up having any workspace specific logic so it made sense to have the lifetime of the IDE.
#2010
- Removed `TagHelperFactsServiceInternal` since we had no way of retrieving the internal Workspace service given the exposed public API. Not to mention I think the `TagHelperFactsService` made more sense as a MEF service anyhow.
- Moved `TagHelperFactsServiceInternal` tests to `Microsoft.VisualStudio.Editor.Razor.Test` project and changed them to utilize the non-"internal" version.
- Updated completion service API to rely on non-`TagHelperFactsServiceInternal` pieces.
#2004
- Changed the `RazorCodeDocumentProvider` and its `TextBufferCodeDocumentProvider` dependency to be MEF services. This changes their lifetimes from per-workspace to per-IDE.
- Updated `RazorDirectiveCompletionProvider` to get the code document provider via MEF instead of the old primary workspace".
- Removed language service factory types.
#2007
- The Mac implementation does not have fallback logic like the windows variant because Workspaces in VS mac world are spun up / torn down regularly. We don't want to be tracking down bugs that involve us adding services or Razor logic to Workspaces that have nothing to do with Razor.
- Added a test for the `DefaultVisualStudioWorkspaceAccessor`. Could not add other tests due to limitations of MonoDevelop's abstractions.
#1989
- 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 fix for this for preview1 is to ignore any files with an absolute path. MvcPrecompilation
ignores files outside the project root, and we're aiming for parity.
This will have a proper fix in preview2
- Lifted `DefaultEditorSettingsManagerInternal`s state / event handling functionality into its `DefaultEditorSettingsManager`.
- Re-purposed `EditorSettingsManagerInternal` into a less-API heavy middleman `WorkspaceEditorSettings` for any workspace services concerned with editor settings to consume.
- Moved `DefaultEditorSettingsManagerInternal` into the Editor.Razor assembly and renamed it to `DefaultWorkspaceEditorSettings` since it needed the `EditorSettingsManager` API to function properly. The contract still exists at the `CodeAnalysis.Razor.Workspace` level.
#1982
- 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
- 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
- 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
* Add support for MvcPrecompilation settings
Adds support to the Razor SDK for various legacy features of the MVC
Precompilation tool.
- MvcRazorCompileOnPublish
- MvcRazorExcludeViewFilesFromPublish
- MvcRazorExcludeRefAssembliesFromPublish
- MvcRazorOutputPath
- MvcRazorEmbedViewSources
- MvcRazorFilesToCompile
The Web SDK is going to set a new msbuild property to tell us that the
Razor SDK should be active. This hasn't been integrated into our build
system yet, so I'm temporarily hacking it until we get that change. At
that time I'll remove the special cases in these projects.
We can't rely on property evaluation to attach targets to the build
lifecycle, as we rely on the web sdk to set these properties and they
run after us.
* Split up Razor SDK logic
Splitting the fragile parts of code generation into its own file. We're
possibly separating the Razor SDK into a part that ships in the dotnet
SDK and part that ships in a nupkg with the compiler.
This means defining more of a fixed lifecycle in the main file, and
treating our actual work as more like extensibility.
- 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
Ajay Bhargav Baaskaran
Ryan Nowak
Ryan Nowak
Pranav K
Ryan Brandenburg
Artak
N. Taylor Mullen
David Karlaš
Artak Mkrtchyan
Nate McMaster
Rustam Agametov