* 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.
Ryan Nowak
Pranav K
ASP.NET CI
Ajay Bhargav Baaskaran
Nate McMaster
N. Taylor Mullen