Our program needs to consume the COM server which is also made by us. The scenario is the following: the installer will copy both the program files and the COM server files into the same folder on each install.
Currently we use regsvr32 to register the COM server, but this is not very good - if we develop another unrelated program that also consumes the same COM server (likely of another version) we can run into problems - since the CLSIDs are unchanged, the server registered later will be used by both programs and the first program might malfunction.
So we need reg-free COM. We could use manifests, but I've played with them for a while and find them not very convenient for use in the nightly build. We could also rewrite the program so that instead of calling CoCreateInstance() it calls LoadLibraryEx(), then GetProcAddress() to locate DllGetClassObject() and then just retrieves the class factory and uses it.
I immediately see some drawbacks:
- the program will have the dependency on the exact COM server filename
- extra code will have to be written for stuff normally managed by Windows
- the COM server will have to be in-proc and marshalling will never be used
and those drawbacks could be show stoppers generally but don't look bad at all in our specific scenario.
Are there any other drawbacks in using LoadLibraryEx()/DllGetClassObject() compared to CoCreateInstance()?