“source generators you can modify/rewrite existing code” Are you sure? so far all i know is that source generator only can add code. Could you give a example. thank you

It’s an internal generator that automatically generates lots of overloads to my types so that value types are not boxed. You can find the code at https://github.com/NetFabric/NetFabric.Hyperlinq/tree/cb76d29c8d9b91935079fa4d226e393b01b1f03f/NetFabric.Hyperlinq.SourceGenerator

I’m planning to add a public generator to generate binding methods.

For debugging you can simply add :

System.Diagnostics.Debugger.Launch();

and at compile time you will be able to attach your debugger.

T4 templates don’t have access to your programs structure at compile time. even when running from the same assembly. Source generators do have access to that structure and are brought in as a library rather than copy pasting into your source code. since source generators allow for compile time introspection and code generation there are opportunities to do things like IOC containers with zero runtime reflection overhead and I can see things like automapper and ASP.Net being rewritten using this technology to be MUCH faster.

It feels like a dark secret, but I’m actually still using MyGeneration. I use it to generate all our EF classes and repositories based on database meta data and hand coded MyGeneration scripts. I use MyGeneration over T4 as it just seems a whole lot easier and more powerful.

I think Code Generation is great for bridging application domains that are physically separated yet tightly coupled such as the example you’ve given above with a client generating code based on meta data for a web service, or generating EF code based on a database schema, or going the other way and generating SQL scripts base on EF code etc.

Source Generators seem like something you could use to create your own scripting language like Code Smith, MyGeneration or T4… rather than a scripting language in itself. It’ll be interesting to see where Microsoft runs with this, and what it gets used for. Is Microsoft already using this internally for anything?

1. Debugging support is desperately needed. At minimum it would be good to see the details of exceptions that crashes the source generator. But being able to easily attach a debugger would make life a lot easier.

2. Roslyn’s diagnostic system seems to be pretty thorough. But if you are developing a library, sometimes you just want something quick and dirty. It would be good if there was a simple way to output debug logs, warnings, errors, etc.

3. Roslyn’s API is massive. This is somewhat understandable because it is a compiler. But it can be pretty hard to find anything. For example, presumably there code somewhere that creates a mapping between the Accessibility enum and its string representations. But I couldn’t find it.

4. I suspect that for a lot of source generator libraries, the semantic model will be the most useful. So, it is a little strange that it isn’t presented front and center in the source generator interface. I probably wouldn’t have been able to figure out how to access the semantic model without looking at the samples.

All that being said, I think this is a pretty cool feature and I am definitively looking forward to its official release. Keep up the good work!