I have seen this done in C#, such as here although, I cannot seem to figure out how to do this in VB.NET. For some background, I have created a custom ComboBox control as a .dll, and I need to implement it in another .dll(ArcMap Component).
Unfortunately, ArcMap does not allow for "third-party" DLL's to be loaded along with the component, because there is no option to reference any third-party assemblies for your add-in.
If someone could point me in the right direction, it would be more than appreciated.
We use this technique in VB.NET in Visual Studio 2008...
First, the project needs to know to include the "other" dll as an Embedded Resource. In the Solution Explorer, add the dll as a file to your project (not as a Reference). Then, open the Properties for the file and set the Build Action to "Embedded Resource." It is recommended that you create a local copy of the dll file in the structure of your project rather than linking to some other location. Once the project includes the dll file, you can then add the reference to that copy of the dll so that you can use its contents at design-time.
That ensures that the "other" dll is included in your compiled dll, but it doesn't make it automatically load when needed. That's where the following code comes in:
Place this Module somewhere in your project and be sure to call the
EnsureInitialized
method to attach theAssemblyResolve
handler before calling any other code in your dll.NOTE: You'll need to replace [CONTAINER ASSEMBLY] with the name of your dll.
Also note that the above code is a stripped-down version of what we actually use because ours includes log4net logging messages at strategic places. The logging messages aren't necessary for the true functionality, so I removed them for brevity and clarity.
The major caveat to this approach is that the
AssemblyResolve
handler has to be attached manually. Even if you can't set things up so thatEnsureInitialized
is called only once during the initialization of the consuming code, you can callEnsureInitialized
within any of your own modules that require the "other" dll for execution. This makes the code a little more delicate because you have to remember to make that initialization call, but it does allow you to sleep at night knowing that the dll will be available when you need it.In my experience, some "other" dlls don't play well when they are provided as embedded resources, so you might need to play around a bit to get things working.
Final Note: I've never used ArcMap Component, so Your Mileage May Vary!
I took a little bit of a different approach. I wanted something that would pretty much auto-initialize and dynamically load embedded assemblies as they were being used. I also wanted to avoid loading multiple instances of an assembly that already existed in the current AppDomain. The code below accomplishes all of those for me.
The
EmbeddedAssemblyResolverClass
is used to create the actual AssemblyResolve event handler. I added a few bells and whistles by adding IDisposable support and events for Initialized and Uninitialized, but you can trim those off if not desired.I created the rest of the code in the
EmbeddedAssemblyResolverModule
so that they would be global to my assembly and also because the LoadEmbeddedAssembly method is an Extension method, of which can only be created in Modules.Now the only thing left to do is to create and instantiate the
EmbeddedAssemblyResolverClass
in any other class in your application that uses an assembly that is embedded into its resources.Once you call a method from an embedded resource it will first look to see if the assembly is already loaded in the current AppDomain, if it is then the assembly is returned. If the embedded assembly has not been loaded then it will be loaded dynamically from the embedded resources if it exists.
One thing that is nice about this code is that it works on assemblies that don't have an EntryPoint, like class libraries. Also I have had success in loading embedded assemblies with embedded assemblies which also used this code.