I have the \"Main\" program which loads my own \"plugin.dll\" file dynamically using reflection. The \"plugin.dll\" file references to the third party \"device.dll\" by using vi
Check the AppDomain.AssemblyResolve event. It's the ideal point where you may peform a custom action to load an assembly in a non-default location.
I add here a quote of linked MSDN article:
It is the responsibility of the ResolveEventHandler for this event to return the assembly that is specified by the ResolveEventArgs.Name property, or to return null if the assembly is not recognized. The assembly must be loaded into an execution context; if it is loaded into the reflection-only context, the load that caused this event to be raised fails.
At the end of the day, this means that your application or service will enter into the AssemblyResolve
event case when an assembly couldn't be loaded using default assembly discovery approach (AppDomain.BaseDirectory
, Global Assembly Cache...).
Once the so-called event is raised, you need to return an instance of Assembly
and it's your job deciding how to load the assembly (from file, stream, bytes...). That is, if you're placing your plugin assemblies in some sub-directory or who knows where, you can call Assembly.Load
with the right full assembly path to load them and avoid your assembly loading issues.