Gives our generated a files an extension that isn't used for any other
purpose (that we know of). This is handy for tooling to be able to
quickly know if a file is 'ours'. This comes up in places like
IVsSymbolicNavigationNotify (go to definition).
* Add support for generating attributes on Razor assembly
* Generate ProvideApplicationPartFactoryAttribute on Razor assembly
* Generate RelatedAssemblyAttribute on application assembly
* Update path calculation for BuiltProjectOutputGroupOutput to include full path. This matches
the behavior of Microsoft.Common.targets.
* Add Razor symbols to DebugSymbolsProjectOutputGroupOutput
Fixes#2116
* WebSdk transitions
* Add a reference to Microsoft.Net.Sdk if it wasn't previously referenced
* Move PreserveCompilationContext in to our target
* Remove use of transition property
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 a reference to Microsoft.Net.Sdk if it wasn't previously referenced
* Move PreserveCompilationContext in to our target
* Remove use of transition property
This change adds a test to verify that Razor targets don't show up in
design time builds when RazorCompileOnBuild=true
We don't want to add a significant perf cost to design time builds since
they affect project load.
* 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.
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
* 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
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.
Pranav K
Ryan Nowak
Ajay Bhargav Baaskaran
Ryan Nowak