Roslyn Code Generator about c3d.msbuild.tools.ef6.generateviews HOT 1 CLOSED

I'm not entirely sure the advantage of this in this case.

We don't (generally) need to modify or inject any code into existing classes etc. It just adds code to be compiled based on the EDMX. It also doesn't need to do it on every build - just if the EDMX changes. The current method of creating the source files to inject allows for short circuiting of the generation from MSBuild etc.

I guess the only thing that could be useful for, is to find the namespace for the DbContext class. The Edmx file only has the class name, not the namespace, and the DbMappingViewCacheTypeAttribute requires the fully qualified name. However, there could be cases where multiple contexts exist in different namespaces etc. and the single entry in the proj file doesn't seem like a big issue.

What would be better, would be to use the System.CodeDom.Compiler.CodeDomProvider classes to output the source file, and not have to have separate C# and VB.Net generators used.

I have a MSBuild task which does this for ResX resources (from EmbeddedResource items) to generate the strongly typed accessor classes instead of using SingleFileGenerators.
This means I can override any setting for the Class using metadata on the EmbeddedResource.

Most of the code for this project was based on the existing code in the Entity Framework 6 Power Tools Community Edition so I didn't really work on how the output was generated, but certainly the CSharpViewGenerator and VBViewGenerator need some love and care.

Looking at the Source Generators cookbook - this scenario doesn't seem to fit, but if you can explain why/how it would work better, please let me know.

from c3d.msbuild.tools.ef6.generateviews.