Reputation: 345
I have a project where I've implemented INotifyPropertyChanged as a source generator that I'd like to be able to use in my various MVVM-centric projects.
This project uses the approach of applying attributes to fields in a partial class and it will generate the Properties for those fields.
My current project however is based on Monogame and the UI framework doesn't natively support binding, so I thought I'd knock up a solution that avoids reflection using another source generator.
Unfortunately, it seems that the properties that are generated in my INotifyPropertyChanged source generator are not visible in my MLEM.Ui.Binding Source generator. I only get the properties that were in my original source code.
Is there a way that I can have the INotifyPropertyChanged source generator run first, and then use it's generated source code in my second binding source generator?
Things I've tried:
EmitCompilerGeneratedFiles
and CompilerGeneratedFilesOutputPath
to a directory (I struggled to exclude the files in obj/Debug/generated so I ended up with duplicate classes)Upvotes: 5
Views: 2536
Reputation: 345
The answer to the question, as explained by Marc Gravell is No.
Having said that, I have managed to successfully work around the issue, however not by chaining multiple source generators in a single compilation unit.
I'm fortunate that I was generating my bindings as a set of extension methods, which meant that I could move my ViewModels and their INPC source generator into it's own project, and then have my binding source generator run on the original project.
This means that the output of the ViewModel assembly is already stable with the assembled INPC code already in place when the binding source generator examines it.
This may not work for everyone, but maybe it opens a possibility.
Upvotes: 4