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® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
