referencing and using an assembly in different folder than App

bitbonk

Is there a way to that an application could make use of assemblies that are not located in the same folder or in a subfolder of the main executing assembly Can I direct the probing for a referenced assembly to that different folder somehow Or could I load and use the the assembly using reflection

Galin Iliev

you can load assembly using reflection but then all referenced classed should be used in your code with reflection which is not very comfortable.

As far as I understood you want to store all shared assemblies in shared folder (not in GAC) and to point applications to search there

Locating the Assembly through Codebases Codebase information can be provided by using a <codeBase> element in a configuration file. This codebase is always checked before the runtime attempts to probe for the referenced assembly. If a publisher policy file containing the final version redirect also contains a codebase, that codebase is the one that is used. For example, if your application configuration file specifies a codebase, and a publisher policy file that is overriding the application information also specifies a codebase, the codebase in the publisher policy file is used. If no match is found at the location specified by the <codeBase> element, the bind request fails and no further steps are taken. If the runtime determines that an assembly matches the calling assembly's criteria, it uses that assembly. When the file at the given codebase is loaded, the runtime checks to make sure that the name, version, culture, and public key match the calling assembly's reference. Note Referenced assemblies outside the application's root directory must have strong names and must either be installed in the global assembly cache or specified using the <codebase> element.

this is quote from here http://msdn.microsoft.com/library/default.asp url=/library/en-us/cpguide/html/cpconstep4locatingassemblythroughcodebasesorprobing.asp

click on above link for more info

HTH

bitbonk

So the assemblies have to have a strong name, wich is in our case not really suitable. We have a pluginarchitecture where different applications can load the same plugin-assemblies and they all should live in the same folder. Since we use xcopy-deployment we would not want to install anything (into the GAC).

So one option to solve this issue is make each application upon startup copy all assemblies found in the shareddll-folder to a local subdirectory. Do you see any problems / pitfalls with this approach

Galin Iliev

in order to do this you mush have application started module which does:

1. copy all needed assemblies from shred folder
2. start actual application because before app is started is probes for all reference assemblies

If you are OK with this then this seems suitable for you

Note: In this case you lose option to increase performance with ngen too

The best approach (according me :) ) for plugable architecture is to create base Interfaces which can be used by plugin

then within main application you can use reflection to open all assemblies in certain folder, search for class that implements IPlugIn (for instance), create instance and save it to list of active plugins and initialize it by passing main application class.

There is nice article Pluggable architecture(http://weblogs.asp.net/ngur/archive/2004/08/02/205789.aspx)

HTH