- 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
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
N. Taylor Mullen
Ryan Nowak
Pranav K
Ajay Bhargav Baaskaran