- The `ForegroundDispatcher` needed to be accessible by services without requiring a workspace; given that it doesn't have any ties to the `Workspace` other than being a service of one I was able to move it into a MEF service.
- Updated all workspace inclusions of the dispatcher to use importing constructors instead.
- Updated the Mac + Windows implementations to be exported as MEF pieces.
#1979
- Make `RazorProjectEngine` call paths for all feature registrations.
- Add `DefaultMvcImportFeature` for latest and 1.X MVC.
- Ported `AddTargetExtension` and `AddDirective` to `RazorProjectEngineBuilderExtensions`.
- Added tests and a test file system project type.
- Moved obsolete `IRazorEngineBuilder` methods to the bottom of each file. Will actually obsolete the methods once `RazorProjectEngine` is working end-to-end.
#1828
- 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
- 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
We're seeing some test failures on the CI where the build has no output.
Sure enough, using Process.Exited is trap. It doesn't guarantee that all
of the output has been written when it's trigger.
This is a different approach that shouldn't suffer from the same
problem.
N. Taylor Mullen
Ajay Bhargav Baaskaran
Pranav K
Ryan Brandenburg
Ryan Nowak
Nate McMaster
ASP.NET CI