com dll problem
-
I am using two third party com dll . I am facing the problem that their clsids are same ,so i can use only one dll. but my project requirement is to use both the dll . Is their any way to change the clsid of the com dll . any binay tool etc. any another trick.
Rajesh
-
I am using two third party com dll . I am facing the problem that their clsids are same ,so i can use only one dll. but my project requirement is to use both the dll . Is their any way to change the clsid of the com dll . any binay tool etc. any another trick.
Rajesh
rajeshgupta1253 wrote:
clsids are same
Is it the name that's the same or the GUIDs(it can't be)? ATL COM DLLs come with namespaces if you have the tlb file associated with them, namespaces does help avoid such cases. Then there is a
renameattribute that can be used with a tlb file while using#import. From MSDN: Therenameattribute is used to work around name collision problems. If this attribute is specified, the compiler replaces all occurrences ofOldNamein a type library with the user-suppliedNewNamein the resulting header files.Nibu babu thomas Microsoft MVP for VC++ Code must be written to be read, not by the compiler, but by another human being. Programming Blog: http://nibuthomas.wordpress.com
-
rajeshgupta1253 wrote:
clsids are same
Is it the name that's the same or the GUIDs(it can't be)? ATL COM DLLs come with namespaces if you have the tlb file associated with them, namespaces does help avoid such cases. Then there is a
renameattribute that can be used with a tlb file while using#import. From MSDN: Therenameattribute is used to work around name collision problems. If this attribute is specified, the compiler replaces all occurrences ofOldNamein a type library with the user-suppliedNewNamein the resulting header files.Nibu babu thomas Microsoft MVP for VC++ Code must be written to be read, not by the compiler, but by another human being. Programming Blog: http://nibuthomas.wordpress.com
-
I am using two third party com dll . I am facing the problem that their clsids are same ,so i can use only one dll. but my project requirement is to use both the dll . Is their any way to change the clsid of the com dll . any binay tool etc. any another trick.
Rajesh
:confused: This is supposed to be a no-no.... If the two servers have the same class id, then it is the same server, by definition and by COM spec. It may be that the later server is an updated version, but it is still the same server. If the supplier of the two servers claims that those are two different servers, they have broken some of the fundamental rules of COM and there are no guarantees for this to work when distributed even if you might get it to work on your machine. The human readable ProgID may be updated with a new version from e.g. <Company>.<Server>.1 to <Company>.<Server>.2, then they also have to give the server a new class id. If the supplier of the two servers confirms that this is the same server, then your project requirements are wrong or misinterpreted since this is not how the COM architecture works. It may give a hint if you compare the ProgIDs.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown -
I am using two third party com dll . I am facing the problem that their clsids are same ,so i can use only one dll. but my project requirement is to use both the dll . Is their any way to change the clsid of the com dll . any binay tool etc. any another trick.
Rajesh
Different CLSID for different modules is a primary role for COM. The CLSID should be changed if there is no compatibility in the interface!!!! :doh: You better explain the creators of the dlls that the same CLSID are crappy. I bet that they came from the same person who hasnt enough experience to deal with COM. X|
Greetings from Germany
-
:confused: This is supposed to be a no-no.... If the two servers have the same class id, then it is the same server, by definition and by COM spec. It may be that the later server is an updated version, but it is still the same server. If the supplier of the two servers claims that those are two different servers, they have broken some of the fundamental rules of COM and there are no guarantees for this to work when distributed even if you might get it to work on your machine. The human readable ProgID may be updated with a new version from e.g. <Company>.<Server>.1 to <Company>.<Server>.2, then they also have to give the server a new class id. If the supplier of the two servers confirms that this is the same server, then your project requirements are wrong or misinterpreted since this is not how the COM architecture works. It may give a hint if you compare the ProgIDs.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown