[Question] Accessing app.config from a plugin

[ssteiner]

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?

[Hesam Faridmehr]

Have you tried using GetExecutingAssembly?

Assembly.GetExecutingAssembly().Location

[ssteiner]

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.

[Hesam Faridmehr]

I am currently using it and it works for me

[github-actions]

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.

[Nate McMaster]

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.