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