2

If I host CLR in my C++ executable, is there any way to set base directory of default AppDomain to something other than location of the executable?

Here's why I need it. I have a rather complex application that loads .NET plugins using a plugin loader executable, PluginBox.exe. The plugins are located outside of the main application folder. We run one instance of PluginBox.exe per plugin.

Currently PluginBox.exe is written in C++. I want to convert it to a managed app. PluginBox uses unmanaged CLR hosting (ICLRMetaHost, ICLRRuntimeInfo, etc.), and locates plugin assemblies by implementing IHostAssemblyStore interface. There is only one AppDomain, and its base directory is the application directory. When searching for assemblies, CLR invokes the assembly store before looking at the application base directory. So, if the plugin and the main app contain an assembly with the same name, the assembly store can load the plugin-specific version.

As a first step towards making PluginBox.exe managed, I would like to get rid of the assembly store and replace it with an assembly resolver. The trouble is, unlike assembly store, assembly resolver is called after the application base directory has been considered. So, if the plugin and the main app contain an assembly with the same name, main app's assembly wins. This disrupts plugin execution.

I would like to switch base directory of the hosted CLR to where the plugin is located. So far, I found only two ways to do that, both of them unacceptabe: move PluginBox.exe to the plugin directory, or create a second AppDomain, which is problematic for a variety of internal reasons. This is a huge application with a lot of history, and any drastic moves are bound to cause problems.

Any thoughts and ideas are appreciated.

PS. Current CLR version is 4.0.

Ivan Krivyakov
  • 1,898
  • 1
  • 17
  • 27
  • As a workaround you could move all the assemblies into a separate directory for the main application as well, and use the resolver for those too. – Jester Nov 08 '14 at 00:58
  • "or create a second `AppDomain`, which is problematic variety of internal reasons". Well, the idiomatic way to have a custom AppDomain is to instantiate a custom AppDomain. Could you elaborate on why you can't do this? – Asad Saeeduddin Nov 08 '14 at 00:59
  • @Jester - yes, I thought about that. Not gonna fly - there are other parts of the application that use those assemblies. See "huge application with a lot of history" part. We may not even know who sues what until it breaks :) – Ivan Krivyakov Nov 08 '14 at 01:10
  • If the only problem here is that you're unhappy with the default domain's assembly resolution, you can hook into the `AssemblyResolve` event for more fine grained control. That way you can look into whatever folders you want to find your plugins. – Asad Saeeduddin Nov 08 '14 at 01:13
  • @Asad: some reasons why second app-domain is bad. Plugins use some unmanaged thunk code to communicate with the host. If I create a second app-domain I will immediately run into unmanaged callbacks problem. I could rewrite thunk code in C# as well, but this is a bigger and more dangerous change. I may attempt it at some later point. Second reason - performance. Third reason: I already have hosted CLR: I wish I could control it instead of multiplying dummy entities. – Ivan Krivyakov Nov 08 '14 at 01:17

0 Answers0