Sunday, 2 June 2013

Expanding the probing domains of running assembly

We all know about shared assemblies, and usually we want to keep them in the GAC. But is it always the solution for shared assemblies. Let’s take an example if you want to create an application which accepts plugins. So when you install the plugin with the application where you will going to install the assemblies of plugin and so that It can be easily searched by the Application. There are few option that I know:

i) Copying the plugin assemblies to the private bin path of the application.

ii) Putting the plugin assemblies in the GAC. (Not a good idea) as only a single application going to use that so this might not be the best solution.

ii) Expanding the probing domain and creating an external folder as a part of private bin path. Put the plug in assembly there. Now I’ll tell you how you can do it?

Previously, I was only aware about the probing domain searches the required assembly in the Private bin and GAC for e.g. you’re loading them dynamically.

To add any custom folder to the probing domain of the application just add below entry to the configuration file.

<!-- Adding custom folder of the Private bin to default probing domains -->
<runtime>
  <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
    <probing privatePath="c:\plugins;"/>
  </assemblyBinding>
</runtime>

And you’re done. Next time you will be keep the plugin assemblies separate from the core assembly of the application.