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