Mike, That's the DataAccess layer creating an instance of the "Instance" class in itself - the so it's that DataAccess layer that needs to be in the GAC.
Currently all files reside in the one directory, but clearly VSTO creates its AppDomain with the Shadow Copy option, and Outlook doesn't for the COM controls, so the VSTO Addin is finding it's DataAccess in the Shadow Cache, and the COM controls are finding the "right" ones. As I have no control over either of these, my best option is to put the DataAccess (and associated files?) in the GAC. I don't think there are any assembly resolution failures - the DataAccess layer creates remote instances of itself and returns small data packets that are defined within that assembly too, so if it was failing to resolve nothing would work. The assembly is resolving and loading. The only other assemblies that the DataAccess relies on are custom Configuration assemblies etc, but none of those classes or interfaces are ever exposed via remoting. Dino -----Original Message----- From: Discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Mike Woodring Sent: Tuesday, 17 October 2006 09:25 To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM Subject: Re: [ADVANCED-DOTNET] Get an AppDomain you didn't create > 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 It's difficult to say for certain having only seen your emails, but the starting point for your investigation would be the return type of the following method shown in the stack trace you sent: Xception.Midas.DataAccess.Generated.ClassFactory.NewInstance What assembly is that return type defined in, where is said assembly deployed, and why can it be loaded successfully in one app domain but not the other. If that assembly is deployed to more than one location, it would be a candidate for installation in the GAC. Similarly, if the name of the assembly that's being transmitted in the marshaled objref that the remoting layer is sending from server to client is not strongly named, then at unmarshal time (the exception you're getting), you're going to get a failure if the APPBASE for the appdomain that's failing isn't set to the directory where that assembly resides. Along those lines it would probably help if you used fuslogvw to capture assembly resolution failures. That will probably tell us what type/assembly the CLR is looking for in the failing scenario. Run 'fuslogvw' from a .net 2.0 command shell, enable logging of *both* failures and successes, clear the log, then run outlook/office/whatever that's going to load your assembly, reproduce the failure, refresh the log display, then have a look at each of the entries in the log. Identify the log entry that shows the assembly containing that type being loaded successfully, then compare that to the entry showing a failure to load that assembly. That should come pretty close to pinpointing the root cause of the failure. In particular, in both the success & failure scenarios note (1) the appbase where the assembly resolver does its probing and (2) the 'display name' of the library that the resolver is going to attempt to hunt down & load. -Mike Bear Canyon Consulting LLC http://www.bearcanyon.com http://www.pluralsight.com/mike =================================== 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
