"Olivier" <toon@toonworld.com> wrote in message
news:eccf2cSeIHA.1824@TK2MSFTNGP02.phx.gbl...
"Willy Denoyette [MVP]" <willy.denoyette@telenet.be> a ?crit dans le
message de news: %23FBzLnJeIHA.3756@TK2MSFTNGP06.phx.gbl...
"Olivier" <toon@toonworld.com> wrote in message
news:u5Vard7dIHA.3400@TK2MSFTNGP03.phx.gbl...
Two additionals infos:
The two dlls don't have the same name but are stored at the same
location
For instance:
C:\Support\Server32.dll
C:\Support\Server64.dll
and the tlb are stored in both dlls.
Olivier.
"Olivier" <toon@toonworld.com> a ?crit dans le message de news:
erzirY7dIHA.3400@TK2MSFTNGP03.phx.gbl...
Hello,
(I apologize, if this is not the correct forum for my question, but I
did not find another one.)
Here is my question:
We have developed ? COM dll server.
This latter is compiled in 32 bits AND 64 bits (without any changes).
On Windows 64 bits, the two versions may be ran at the same time by a
32 bits and a 64 bits process client
I can't figure out if we need to change the CLSID of our COM objects
for each "bit model". I would prefer not changing them, otherwise
that would mean a lot of changes in our clients.
I tried to search these CLSID in the registry and found that they are
existing in both the 64 bits and 32 bits section (under Wow6432Node).
I know that Windows copies some registry keys from one section to the
other, but I'm not sure in which direction (maybe only when the
server is 64 bits, and so on...)
I wonder also if the registration order is important (i.e. do we need
to register the 64 bits version before or after le 32 bits one?). It
seems that it may change the way registration informations are stored
in the registry. Also, sometimes, we get the "Class is not
registered" error. If we register again our server, the error
disappears.
So, what is the best practice to resolve this issue?
Any help in this area will be appreciated.
Best regards,
Olivier.
All you need to take care of is that you register your COM server DLL's
using the right version of regsvr32.exe.
The 32-bit DLL must be registered with the 32-bit version of regsvr32
(%windir%\syswow64), while the 64-bit version must be registered with
the 64-bit version (%windir%\sytem32).
Willy.
Hello Willy,
Thank you for your comment, but I'm not sure of this.
I tried to register the 32 bits version of our dll, using the
regsvr32.exe located in C:\Windows\System32, and it worked without any
problem.
I tried also to regsister the 64 bits version, using the regsvr32.exe
located in C:\Windows\SysWow64, and it worked also without problem.
In fact, both versions of regsvr32 seems to work with both versions of
our dll.
I don't know how this works, but it works!
Here are informations about regsvr32.exe found on our 64 bits test
machine:
C:\Windows\System32\RegSvr32.exe: 15 872 bytes, version 5.2.3790.1830
(srv03_sp1_rtm.050324-1447)
C:\Windows\SysWOW64\RegSvr32.exe: 12 800 bytes, version 5.2.3790.1830
(srv03_sp1_rtm.050324-1447)
Best regards,
Olivier.
Don't know what you mean by "but it works!", do you mean you can register
whatever version of a dll with whatever version of regsvr32? Or do you
mean that it works at run-time?.
Anyways, you always need to use the 64-bit version of regsvr32 to
register a 64-bit DLL, and the 32-bit version to register the 32-bit
version. The same applies to other tools like regedit.exe, there exists a
32-bit version and a 64-bit version, the 64-bit version gives you the
"real view " of the registry, while the 32-bit version gives you a
"virtualized" view. Please search MSDN for "Registry Virtualization" for
more details.
Willy.
able to run the correct version of itself to register correctly the dll. I