Menu
▾
▴
#12 more stable comregister for DLLs and OCXs
I find the com register/unregister API calls to be
unpredictable and easily broken. The best for me is to
simply use regsvr32.exe. The attached comregister task
source file contains an alternate version of
RegisterDllServer, called RegisterDllServer2, which
does things this way.
Logged In: YES
user_id=707851
The <comregister> task is working quite well for me, but if
you can provide examples (repros) of bad behavior ....
Logged In: YES
user_id=709880
I am unable to provide examples, but I'll explain myself
further...
First, my own background on this subject...I wrote an
auto-update program using the API calls, which worked ok,
but sometimes seemed to fail to fully register some types.
Worst of all, in some cases, the program managed to corrupt
the Windows registry beyond repair. Now, even given that my
program may have had bugs (I could not find any), the price
of failure was very steep (operating systems needed to be
re-installed).
Fast forward to the present. Using Nant, part of the build
process unregisters and then re-registers a set of COM dlls.
Only, sometimes, it does not work, and DLLs remain
unregistered, or are not unregistered at all. As an
experiment, without any other changes, I changed the
register/unregister process to use regsrv32.exe. This
resolved my problems completely.
I strongly recommend that you apply the patch. In my
opinion, you risk registry corruption by using the APIs.
Occasional use may be ok, but continued use appears to cause
problems.
Logged In: YES
user_id=321872
ok -- well first of all they are not apis at all but simply
a convention that com dlls export functions named:
DllRegisterServer and DllUnregisterServer. All we do is do a
"GetprocAddress" on those entry points and call them. This
is exactly what regsvr32 does as you can confirm by looking at:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vcsample/html/vcsamregsvrsampleinvokesselfregistrationcode.asp
Now those entry points could conceivably be doing anything -
any changes to the registry that result will be caused by
the code in the com dll itself that does registry
modification - not the calling application.
I don't see how the call to an entry point itself could be
corrupting the registry.
Now if you could produce a sample that demonstrates the
not-registering behaviour that would be great. I'm
disinclined to change the code spawn an external process if
we don't know for sure what the issue is.
note that we did have an issue previously where the com dll
wasn't unloaded cleanly after the DllRegisterDll call and so
it remained locked when another task tried to delete it or
UnRegister it. That seems different to your issue though.
Logged In: YES
user_id=709880
Perhaps this is the same issue as was fixed? Does 0.85 RC1
contain the fix? In any case, I'll make it clear that at no
point has the comregister task corrupted my registry - that
was a separate issue which I offered as a background to my
own general distrust of the API (yes, I'm still calling it
an api).
This is a bug that I am able to reproduce 100% of the time
with 0.85 RC1, and never with my own patched version. The
DLLs being registered are proprietary VB6 COM dlls, with no
special registration logic.
The specific error message is:
[comregister] Error while unregistering
'C:\Projects\bin\xyz.dll'
[comregister] Unable to find an entry point named
DllUnregisterServer in DLL
C:\Projects\bin\xyz.dll.
(error sometimes occurs with the register function too)
I have attached a script, although I am unable to send you
the DLLs that are used by the script. Perhaps substituting
the names of your own set of 10-12 large COM dlls will do
the trick. The script unregisters and re-registers DLLs for
a few minutes before it starts giving errors. When using
the patch, it runs successfully to completion.
Logged In: YES
user_id=321872
yes rc1 does contain that fix but it shouldn't be related to
the error you're are seeing.
I appreciate that you can't send proprietry dlls - however
the self-registration part should be unreleated to the rest
of the code in the dll. Would you be able to:
- find a single dll that consistently reproduces the
registration error
- then strip all the code out of it -- except for a couple
of stub methods maybe and see if it still fails
- attach the stripped down version here
could you also run depends.exe on the failing dll to verify
that it indeed contains a DllUnregisterServer entry point. -
Since its a vb6 dll there is no reason that it shouldn't but
who knows.
oh - does it always fail with the same dll ? or does it vary ?
Logged In: YES
user_id=709880
It does not seem to be related to a single DLL - it is more
a function of repeated registration and unregistration of a
set of DLLs within the same process.
When I reproduced the first time, I reduced the set of DLLs
to the 2 failing DLLs, and tried again to reproduce. It did
not happen. I then put all the DLLs back, and reproduced
again; this time a separate subset of the DLLs gave the problem.
While I do not believe the problem is related to the
specific set of DLLs, I cannot rule that out. Perhaps the
best course of action would be to wait for someone else to
report a similar issue. If that happens, then it should be
easier to find the common thread.
Logged In: YES
user_id=709880
Closing this, because current version of comregister appears
to be working better. Probably, improved releasing of
objects has fixed the problem.