-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Source Generators: Allow loading referenced assemblies #45060
Comments
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
I have the same scenario. I have to run fluent-like configurations and based on that produce some code. The full file paths of the referenced assemblies can be found under |
@fiseni Nice approach. I can confirm that this workaround breaks VS as I did give this a try and it breaks everything from VS to the compiler process running in the background as you have mentioned in the comments of your source. I even tried to use reflection only context as this would be sufficient for my case but to no avail, things get even messier there. |
Oh, that was just an experimental project. That approach shouldn't be used in any case. Refer to this comment here. |
Background
I'm investigating whether Source Generators can be used to make Entity Framework Core AOT-compatible. Currently EF needs to use reflection to create its model and then compiles lambda expressions to manipulate user-provided types efficiently. We could do this at design time and generate a model that would be compiled along with the user's code instead.
Problem
Users configure the model by overriding the
OnModelCreating
method onDbContext
. To be able to generate a compilable model we first need to run that code, looking at the source code is not enough.Currently there is no way to get the full file paths of the assemblies referenced from the code being analyzed to be able to load them and run the configuration code.
Proposal
To limit the impact and prevent a leaky abstraction exposing the assembly file paths can be avoided. We only need to be able to run the source generator in an AppDomain that has all the referenced assemblies loaded. So the details can be hidden away behind a method or by implementing an interface.
The text was updated successfully, but these errors were encountered: