Source generators can't respect DDD

With the current implementation of source generators, there is no way for generated code to respect a domain driven design.

For example, I have the following projects, both referencing the generator project: Domain and Application

Domain contains a model with the Feature attribute (causes CRUD source to be generated for the given feature):

[Feature]
public class Product
{
    public int Id { get; set; }
    public string Code { get; set; }

To follow proper DDD given only 2 projects for brevity, a lot of the output source should not be available to Domain, but should be available to Application.

Because the generator will run for each project, Domain will get all of the source because it uses the Feature attribute but Application will get nothing.

I think there needs to be some way to have a persisted syntax receiver which would allow the correct projects to get the desired source.

If there’s another way to do this I’ve not found it, because as it stands, you can’t even just serialize the state into the generator output directory because one run gets AppData\Local\Temp\VBCSCompiler\AnalyzerAssemblyLoader\92fd63172da84323a0ba94e97aa9857a\6 and the other gets Generators\bin\Debug\netstandard2.0

I get that I could just let the types be in Domain and they would filter through by referencing but they should really be generated into Application

[CyrusNajmabadi]

To follow proper DDD given only 2 projects for brevity, a lot of the output source should not be available to Domain, but should be available to Application.

Why is Domain asking for code to be generated in it then? Why not only have Application run the generator? I’m not really understanding why things are configured in this fashion.

–

For context, we just do what you tell us to do. If you have a generator in Domain and it generates code, then teh code will be generated in Domain. Likewise, if you don’t have a generator in Application, then you won’t get generated code in it. So it sounds like we’re doing exactly what you set things up to do.

[CyrusNajmabadi]

Closing out as working as intended. The right approach is to just example ISymbols in downstream compilations. It is very much by-design that when compiling one compilation there is zero knowledge that any symbols being references even came from C# (and thus could even have their trees be examined). We very much want to keep the separation here and only have ‘syntax’ be a thing that one has access to from within the compilation being compiled.