Patches item #1060610, was opened at 2004-11-04 17:37 Message generated for change (Comment added) made by dukeytoo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=474853&aid=1060610&group_id=54790
Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Steven Campbell (dukeytoo) Assigned to: Nobody/Anonymous (nobody) Summary: more stable comregister for DLLs and OCXs Initial Comment: 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. ---------------------------------------------------------------------- >Comment By: Steven Campbell (dukeytoo) Date: 2004-12-19 11:45 Message: 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. ---------------------------------------------------------------------- Comment By: Ian MacLean (ianm74) Date: 2004-12-17 23:46 Message: 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 ? ---------------------------------------------------------------------- Comment By: Steven Campbell (dukeytoo) Date: 2004-12-17 14:43 Message: 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. ---------------------------------------------------------------------- Comment By: Ian MacLean (ianm74) Date: 2004-12-17 01:11 Message: 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. ---------------------------------------------------------------------- Comment By: Steven Campbell (dukeytoo) Date: 2004-12-16 15:33 Message: 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. ---------------------------------------------------------------------- Comment By: Gert Driesen (drieseng) Date: 2004-12-14 00:08 Message: 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 .... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=474853&aid=1060610&group_id=54790 ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ NAntContrib-Developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nantcontrib-developer
