Roslyn weaver

gistfile1.md

Roslyn Weaver

deployed

As a nuget package the same as Fody

Injection into the pipeline

Optionally replace/add cs files to the build pipeline in a similar wat to GFV

https://github.com/Particular/GitFlowVersion/blob/master/GitFlowVersionTask/UpdateAssemblyInfo.cs#L25 https://github.com/Particular/GitFlowVersion/blob/master/GitFlowVersionTask/NugetAssets/GitFlowVersionTask.targets#L26

So at build time all the cs can be loaded into a roslyn model and passed to the addins for manipulation

Extended

Nuget packages with a naming convention the same as fody

Each addin gets access to roslyn model for the current project and can choose to manipulate it

Debugging

Possible write new cs file to build temp in the same way that Costura does??

This is definitely possible, and even the Roslyn team have said they'll support code injection, just possibly not for the first release.

About the only issue is this only applies to code the CS compiler can produce. I'm not sure how it works for doing weirder stuff like injecting code into the ModuleInit.

Another thing I've been thinking about is having an easier way to inject code. I've been looking at AspectJ and how it does aspect injection. We could borrow concepts from there (join points, pointcuts) and use Roslyn to take C# code from the weaver, turn that into an AST and insert it into the right spot of the main codes AST. This would make weaver writing much easier as you wouldn't need to know IL.

Ok, I've been looking at this a bit more.

It might be worth starting work on this now, even with the Roslyn bits lacking. Currently I can see 2 options.

1. We create a program that takes source, runs it through Roslyn syntax rewriting, and outputs a modified source file. That file is then compiled with the current compiler to produce the assembly. Problems are we are patching the build steps to insert this step, and debugging would debug the generated file, not the original file, so comments etc would be lost.
2. We patch into the Roslyn pipeline, and do the syntax rewriting there. Problem with this is currently there is no Roslyn pipeline.

Either way we'll still need a syntax rewriter, and that would be the complex bit anyway. So it would be worth starting work on a syntax rewriter and use 1 to test it until 2 comes out.

I've created a proof of concept for syntax rewriting.

https://github.com/distantcam/RoslynSandbox

It works pretty well, and there's no IL code writing anywhere in sight.