- Tied into VS4Macs ProjectExtensions in order to bootstrap our Razor world.
- We currently watch all DotNet projects with the expectation that they're the only ones that can potentially turn into Razor compatible projects.
- Added a fallback Razor project host which is used for pre-Razor SDK Razor versions (< 2.1).
- Added a default Razor project host which consumes all MSBuild data from the users packages and sets up the Razor world accordingly.
- Had to modify some existing contracts to work better with new expectations. one of these was the VS4Mac specific Workspace accessor; essentially we needed to be able to lookup a workspace from a solution.
- Some of our previous expectations about addins were wrong (not being able to directly reference your libraries). To avoid using reflection to bootstrap our types I tried out directly referencing our libraries and all worked fine.
- Refactored the DefaultRazorProjectHost in windows (since we had to in Mac) for testing purposes.
#2081
- For older version of Razor the HTML comments will be complained about by TahHelperRewriter
- RazorParserFeatureFlags tests now ensure that AllowHtmlCommentsInTagHelpers is true in 2.1 version and false in older versions
- Added extra test for IsHtmlCommentAhead to make sure Razor code transition is allowed in comment tag
- Moved the unallowed html comment ending to a static array.
* Add support for generating attributes on Razor assembly
* Generate ProvideApplicationPartFactoryAttribute on Razor assembly
* Generate RelatedAssemblyAttribute on application assembly
Since the default tag helper provider is used by MVC then MVC should
include it. Now that Blazor is in the mix we shouldn't include it for
all configurations.
* Update path calculation for BuiltProjectOutputGroupOutput to include full path. This matches
the behavior of Microsoft.Common.targets.
* Add Razor symbols to DebugSymbolsProjectOutputGroupOutput
Fixes#2116
- Existent imports are imports that have content that contribute to the processing of a Razor document. Prior to this we had a legacy expectation that code documents had empty markers in them for all of their import locations. This proved troublesome when cross-referencing files that had file paths and were supposed to be existent but weren't in metadata. Now that we have a project engine with a de-coupled import feature we can rely on the import feature for finding all locations of important files and then strip out any non-existent items.
- Strings here was important because any import added to the system dynamically needs to eventually make its way back to being a project item. With strings we can state that they do exist (have content) but do not have any file paths associated.
- Updated all call sites to use the new AddDefaultImports string based api.
#2080
Pranav K
N. Taylor Mullen
Ajay Bhargav Baaskaran
Artak
Artak Mkrtchyan
Ryan Nowak