Put interop dll into GAC?

5
votes

This might be a bit of stupid question but I need some clarification. I'm somewhat new to .NET and have created a EXE that had to reference an existing COM DLL. In doing so, Visual Studio 2010 automatically created an "Interop" DLL that it needs/uses to work with the legacy COM DLL.

I have deployed my project and included this Interop DLL with it (in the same folder) and everything is working fine. However, I have other applications that will need to use this same legacy COM DLL. Is it okay to reference it they same way in each application and keep deploying the "Interop" DLL with each application? Unfortuantely, all of these small applications go in the same folder and each use the same Interop DLL (so it will already exist there if it's used by another app.) I'm forced to having them in the same folder because these applications are being called as a way of customizing a parent application. As such it only looks in it's local folder when it wants to run a "custom" app. I'm just concerned if one the EXE's is ever removed and they take out the Interop DLL, then the others that still depend on it will fail.

So, I was wondering if it is possible or a good idea to put that Interop DLL in the GAC? I went ahead and installed the Interop DLL into the GAC and then removed the Interop DLL from the folder where my EXE runs and it failed to work. I get an error that says "Could not load file or assembly". I'm stuck on getting this working.

  1. Do I need to reference the Interop DLL in my project differently such that it's now from the GAC? or
  2. Do I need to add something to my .NET code like Assembly.Load to make it work?
  3. Do I need to create that Interop DLL myself using TLBIMP?

Any help would be greatly appreciated!

Best Regards,

Nelson

2
.netvb.netcom-interopgac

2 Answers

1
votes

That's called a PIA, "Primary Interop Assembly". You generate them with the /primary option to Tlbimp.exe, the HowTo is here.

In some cases you have to have a PIA, required when one of your assemblies exposes a type from the import library to another assembly that runs with a separate copy of the interop library loaded. Clearly that's not your case. It is going the way of dodo too, VS2010 supports the "Embed Interop Types" feature, a very desirable feature where important libraries completely disappear.

In your case I would not bother. There's just no advantage to putting it in the GAC, only headaches. Otherwise no idea why you have trouble, use Fuslogvw.exe to troubleshoot assembly resolution problems.

0
votes

You can use ILmerge to make a single .dll file and deploy this into GAC.

PS. If you are using VS.NET 2010 you can use the Embed Interop types project property, look here.