The big idea with CompilationGenerator

[mwpowellhtx]

Hello, I'd like to better grasp the big idea with CompilationGenerator. Best I can determine, the generator is doing a couple of things. First, monitoring the source project/files for updated file(s). Second, doing some bookkeeping as to which assemblies, etc, to load during the compilation/code-generation. Where my fork may transform is in what it manages in terms of generated file(s), but getting to that point, I could see the bookkeeping structure refactoring apart from the generator service itself, possibly with serialization comprehension. One major assumption which I think is there was a 1-1 mapping between source file(s) in which the code generation attribute(s) were discovered and the generated modules themselves. Hence potentially benefiting from a first class bookkeeping abstraction.

[mwpowellhtx]

Which partially segues into questions pertaining to, literally, "why a CLI 'Tool'"? Why not just deliver in terms of an actual MSBuild Task? I mean, the tasking hooks are already there in the CGR work space, all that remains is to convey options and so forth, which is straightforward enough to do. I already do something along those lines for my BumpAssemblyVersions package.

[amis92]

The question why not "MSBuild Task" has a simple answer and it is because of shared compiler being in the app domain and stuff around that. This project evolved from being MSBuild Task to cli tool because of these problems.

[amis92]

For the OP I don't really see any question I can answer, so I don't know what do you expect happening next. Should I criticize the idea? Do you have any problem with your fork? How can I help here?

[mwpowellhtx]

@amis92 Well, I have forked, but I am reworking parts of it to accommodate IEnumerable<CompilationUnitSyntax> as contrasted with class, struct, or other based IEnumerable<MemberDeclarationSyntax>. So this is intended as much to test the insight as it is to kick the tires, get better acquainted, if learned, expert, with the approach. I appreciate the insights.

[mwpowellhtx]

@amis92 Question: yes, while responding to an MSBuild event there is an instance of the compiler running in that engine, if memory serves. Wouldn't it be possible, however, to spin up a Roslyn compiler instance in order for the generator to do what it needs to do?

[amis92]

I think that the issue here is that you don't know which compiler is loaded so you can easily mismatch versions of the compiler used by MSBuild vs one used by CG.R. So in that case, a person couldn't use generators targeting higher Roslyn versions than the one used for building generator-consuming project itself. Which for 3rd party generators would essentially mean "keep lowest Roslyn possible".

[mwpowellhtx]

This is a fundamental assumption, I agree. We're using Roslyn here, so even project level helps such as <LangVersion>x.y</LangVersion> do not help the requested language version?

[amis92]

Sorry, I don't understand what do you mean by "project level helps" or "do not help the requested language version".

[mwpowellhtx]

@amis92 The question was whether Roslyn doesn't run a compiler (language) version compatible with the original request, no? Doesn't LangVersion inform that request from either perspective?

[AArnott]

LangVersion does not control the version of the compiler -- only the language spec version that the compiler allows. As @amis92 said, we embed a Roslyn compiler in the package so that generators can use a known version of Roslyn for emitting code, without regard to the version of the compiler in the user's toolset. You might want to pay attention to the LangVersion specified in the source project though for purposes of avoiding emitting C# 8 code that won't compile in a project that uses C# 7.3, for example. I don't think we currently tunnel that LangVersion from the project to the generator though. So far, it hasn't been requested.