Common binding redirects mechanism for Razor Views and both SDK types - Closes #58

[CZEMacLeod]

This moved the existing mechanism for doing Binding Redirects into the common folder, and adds the RazorAppConfigFiles item type to the main SDK in case you are using MVC Views in the 'head' project.
The mechanism used to update the RazorAppConfigFiles is now the same as the main $(AppConfig) file rather than the XmlPeek/XmlPoke tasks used previously.

[leusbj]

@CZEMacLeod Hopefully quick questions, and you can help me better understand. I have used RazorGenerator outside of this repo to "share" views without sharing them as content, but haven't spent much time around the RazorLibrary side of this repo, so I'm probably missing something.

The intended output type of a "Razor View Library" will be a dll like a ClassLibrary project, right? And regular class libraries are not really "directly runnable" at least not runnable from the bin directory like an executable or web application. With that in mind

• Can the BindingRedirects mechanism be removed entirely from the RazorLibrary, if the output is a compiled dll that won't be run directly?
• For that matter can the "Microsoft.CodeDom.Providers.DotNetCompilerPlatform" package reference also be removed, since the Razor Views will already be compiled, and not need to be compiled from within ASP.NET runtime (does this impact the "Common Default Version" pull request as well?

[CZEMacLeod]

@leusbj The way the razor generator works is to load the MVC dlls and generate the code using the build in compilation mechanism (as I understand it). This uses the codedom provider for part of the operation. I think without using the Microsoft.CodeDom.Providers.DotNetCompilerPlatform package you cannot use RazorGenerator with later language features such as null propagation and other structures.
As it loads the web application using the web.config to do the compilation, each class library must be considered to be a 'web application' in its own right, and needs both the main web.config file, and the ones in the Views folders, to include binding redirects.
I haven't experimented too much with this, but I do know that I added this function to my own class libraries (using XMLPeek/XMLPoke) to ensure the Views had binding redirects, and used to use the double click to apply binding redirects to the older project style for this to work. Granted, the config file is not needed when it is compiled and brought into a head project, but I do beleive it fails to compile properly otherwise.
If you have testing that proves otherwise - I'm happy to take the design under advisement.
If you are not going to be using the newer language features, you can do without the CodeDom and Roslyn updates - but since you are likely to have them in the head project anyway, I'm not sure it is a major problem.
I guess that it is possible to make Microsoft.CodeDom.Providers.DotNetCompilerPlatform marked as Private so that it does not get transitively included in the final site, since as you say, it may not be required. At compile time it is probably better to use the more up to date compiler though, as it will generally be more performant and provide better features.