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-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
