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
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.
Updating RazorCoreCompile to be based on a much newer
version of the Core.CSharp.targets.
This adds support for some things we're missing like determinism and
analzyers.
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.
I think our .nuspec is ending up with paths like:
tools//Microsoft.CodeAnalysis.CSharp.dll
Note the double-slash. This is an attempt to avoid double-slashing.
- 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.
- 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 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
- 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
Ryan Nowak
Nate McMaster
Rustam Agametov
Ajay Bhargav Baaskaran
Pranav K
N. Taylor Mullen