[Question] Accessing app.config from a plugin
ssteiner opened this issue · comments
I'm returning to your plugin package for my plugins because I want to implement plugin reloading.
All my plugins have a config file, an ap.config that gets build with the plugin and that contains settings. Every plugin has an Initialize
method, which inside the plugin performs this code to fetch the right app.config:
string configFile = $"{type.Assembly.Location}.config";
if (!File.Exists(configFile))
throw new FileNotFoundException($"Could not find config file {configFile}");
.... //load config and extract variables here
I've been using the native plugin loading mechanism of .NET Core 3.1+ before (and similar approach for the old .NET framework) where this works fine. However, if I make plugins unloadable, this.GetType().Assembly.Location
for each plugin is null. this.GetType().Assembly.CodeBase
is does have a value, but it is: file:///C:/Program Files (x86)/dotnet/shared/Microsoft.NETCore.App/6.0.6/System.Private.CoreLib.dll.
Is there any way to get the Location
property filled for the plugin assembly?
Have you tried using GetExecutingAssembly?
Assembly.GetExecutingAssembly().Location
No, because Assembly.GetExecutingAssembly().Location()
generally returns the location of the executing assembly (so e.g. the .exe file), and that would then be the program that loads and uses the plugin, and not the location of the plugin itself.
I ended up storing the path of the dll in my plugin discovery mechanism.
I am currently using it and it works for me
This issue has been automatically marked as stale because it has no recent activity. It will be closed if no further activity occurs. Please comment if you believe this should remain open, otherwise it will be closed in 14 days. Thank you for your contributions to this project.
I'm not aware of any mechanism we can use to set the Location
value when loading assemblies.
The base class we use in .NET to extend assembly loading is https://learn.microsoft.com/en-us/dotnet/api/system.runtime.loader.assemblyloadcontext. If there is something we have missed in how its implement that would help here, let me know. Otherwise, I don't know if there is anything we can change in our library to fix this for you.