Mike, Is it the assemblies using COM interop I need to put in the GAC, or the assemblies calling remoting? Basically, my addin has a reference to my UI layer (which is also the COM control library), which references the BusinessServices, which references the DataAccess layer, and the DataAccess layer uses a class factory approach to create instances of itself and it's components remotely - so it's basically just the DataAccess layer that is the problem as far as I can see. Does that mean if I put the DataAccess assembly and all it's sub-components into the GAC, I might have some success?
Dino -----Original Message----- From: Discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Mike Woodring Sent: Tuesday, 17 October 2006 03:06 To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM Subject: Re: [ADVANCED-DOTNET] Get an AppDomain you didn't create The path below looks like the temporary download cache location for the current user. If your assembly isn't in the GAC, you might try that. It certainly appears that you're running into issues due to the assembly being loaded from 2 different codebases, which means you can get exceptions along the lines of 'cannot cast from type X to type X'. Putting the assembly that defines type X into the GAC will solve that problem. If you have more than one assembly, beware of only installing the 'top level' assembly in the GAC. If assembly A is the one that implements the COM interfaces being used by Office, and assembly A depends on assembly B, then only installing A into the GAC will just push the problem back one level - you'll start getting conflicts for assembly B. You'll need to make sure that all assemblies (hopefully only 1 or 2) being used directly or indirectly via COM interop are in the GAC. The problem isn't with remoting - there's no issue trying to call the same remoting server from 2 different appdomains in the same process. -Mike Bear Canyon Consulting LLC http://www.bearcanyon.com http://www.pluralsight.com/mike > I've been searching on this exception, and one thing they suggest is > that if the same assembly is loaded from 2 different locations, that > can cause grief - and indeed it is. > > When Outlook opens, it seems to load the addin from C:\Documents and > Settings\deanc\Local Settings\Application > Data\assembly\dl3\KDBRMV9Y.9BV\X4AEVA3M.YJY\53b145d6\294be7c3_ > 1ee8c601\, > but the COM control loads from a different location. > > Anyone know the reason for the load from Local Settings? Is that a > VSTO design time trick, or is it going to do that on clients anyway > (which probably means I will never be able to remote from the > Addin/COM control combination). > > Dino =================================== This list is hosted by DevelopMentor(r) 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
