Loading multiple versions of a task assembly result results in MSBuild on .NET Core to fail.
Addressing this by moving the tasks in to the Sdk and renaming it. This should avoid
immediate issues for a 2.1 and 2.2 project co-existing and future proofs 2.2 and later.
Fixes https://github.com/aspnet/Razor/issues/2553
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 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.
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
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.
This is failing on the CI due to an issue with a newer build of the SDK.
I opened https://github.com/dotnet/sdk/issues/1854 to track the SDK bug.
- update korebuild
- upgrade deps
- remove System.Diagnostics.DiagnosticSource from test projects
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.
Pranav K
Ajay Bhargav Baaskaran
Ryan Brandenburg
Ryan Nowak