if possible, you can put the downstream-assemblies in the same folder as your com-visible-assembly. this way, they will be found and used altough fuslogvw will show you an error (which is a bug i think)
from msdn: "Assembly location can also be determined using the current binding context. This most often occurs when the Assembly.LoadFrom method is used and in COM interop scenarios." hth franz -----Ursprüngliche Nachricht----- Von: Russ Alan [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 26. Jänner 2006 22:22 An: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM Betreff: [ADVANCED-DOTNET] COM Interop and assembly loading The basic COM interop functionality is trivial and works, but it seems that either I am missing something, or there are serious limitations for real world use where there are dependencies on down stream assemblies. My problem is dealing with assembly resolution when exposing DotNet classes to COM clients. I have my DotNet assembly built and registered with regasm using codebase and tlb switches. If the COM server assembly is self contained, everything works fine. The problem comes with down stream assembly resolution. If an arbitrary COM object client uses a COM object exposed from a DotNet assembly, then getting assemblies loaded is a problem. Obviously, you can throw everything in the GAC, but that's just not reasonable for this project. I thought that a codebase would work since all the assemblies are strong named. Since there is no <app>.config, I put it in machine.config. But fuslogvw reports that it is ignoring those because they are outside the AppBase. Shouldn't the machine.config codebase work given that the assemblies are strong named? If someone can confirm a definitive "yes", then I'll look for what I may have screwed up. I also see a blurb in msdn that says, "For the runtime to use the <codeBase> setting in a machine configuration file or publisher policy file, the file must also redirect the assembly version." And since I'm not doing a version redirect, I guess that is what is causing trouble. I tried the obvious hack of redirecting 1.0.0.0 to 1.0.0.0 but that didn't change a thing. FuslogVw still reports the same error about being outside the appbase. I also see a hack on the web where multiple versions are created just to get around that limitation. Yuck... I guess I could handle AppDomain.AssemblyResolve, but that seems like using a bazooka to swat a fly. But better than multiple versions just to get the codebase to work. Am I missing something? If not, time to haul out the bazooka... Russ =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
