Simon, Mmm, you've said it youself---more or less. Rather than just marshal, your wrapper should take care of loading and freeing the library too. So, instead of activating your COM object through the COM API, you could make a LoadLibrary call and attach to an entry point yourself. When you want to replace the component, you could issue a FreeLibrary call and bring the new component in.
Perhaps, there's much more simple approach---but this's the first I can think of... HTH, Stefan >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf >Of Simon Jefford >Sent: Monday, July 07, 2003 10:17 AM >To: '[EMAIL PROTECTED]' >Subject: COM and AppDomains > > >Having sorted out my performance issue with interop (cheers >Richard it was the Apartment model - I just wasn't doing it >right!) I now have another issue, that I think may be >unsolvable, but I'm hoping that one of you knows better! > >What I want to do is to be able to replace the COM components >my app is using while the app is still running. Now, I know >this is possible by using AppDomains + Shadow Copying with >.NET assemblies, and I have got this to work. However, perhaps >unsurprisingly, this doesn't work with COM DLLs. I'm guessing >this is because the unmanaged code is just being attached to >the process rather than being loaded into the AppDomain. I've >investigated using custom wrappers, that' s a complete >non-starter because the wrapper doesn't seem to deal with >loading the DLL, just marshalling types. > >If someone could put me out of my misery by at least >confirming that I'm attempting the impossible then I would be >most grateful! > >Thanks in advance, > >Simon Jefford > > >_______________________________________________________________ >_________ >This email has been scanned for all viruses by the MessageLabs >Email Security System. http://www.messagelabs.com >_______________________________________________________________ >_________ >
