- 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
This change adds a test to verify that Razor targets don't show up in
design time builds when RazorCompileOnBuild=true
We don't want to add a significant perf cost to design time builds since
they affect project load.
- 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
Artak Mkrtchyan
Artak Mkrtchyan
Pranav K
Ryan Nowak
ASP.NET CI
N. Taylor Mullen
Nate McMaster
Ajay Bhargav Baaskaran
Ryan Brandenburg
Nate McMaster