Reputation: 23383
In all the examples and documentation I see, source generators are in their own assembly. Is this required? I have a library that currently uses reflection and compiled lambda expressions. I am going to write a generator that will write the classes so this isn't needed during runtime. The generator will need a reference to the library. Is there a reason the generator couldn't or shouldn't be in the library itself?
Upvotes: 1
Views: 636
Reputation: 19021
I would recommend it, because you might run into dependency issues if you're not careful. A source generator must target netstandard2.0, since we have to load the generator into different parts of Visual Studio for Windows, some which use .NET Core and some that use .NET Framework (not to mention things like VS Code or VS for Mac!). However, your library may want to have other targets, either in terms of frameworks or runtime dependencies.
My extreme example here is a library that only works on Linux, but you're doing your development on Windows and then deploying to a Linux device for testing. In this case, your generator is running on the Windows machine, and your library on the Linux machine. You of course could make this work with a single assembly, but having them split makes the development time vs. runtime difference clearer.
Having your generator have a bunch of dependencies can also create gotchas trying to actually get those to load (you have to be careful with packaging) too, when that might just be best avoided.
So short answer: it's not required, but it avoids a bunch of potential not-obvious problems and mistakes.
Upvotes: 3