Subject: RE: C++ Anyone? - msg#00069

Previous Message by Date: click to view message preview

RE: Best way to register dlls

Yes, and this sucks and when I find teams like this, I dig into them to find better ways of doing what their trying to do.  I'd like to think kicking around the driver team for a while helped make DIFxApp (http://www.microsoft.com/whdc/driver/install/DIFxApp.mspx) happen.   Bill, I haven't had time to run down the DirectShow guys… but they're on my short-list.  <smile/>   From: wix-users-admin@xxxxxxxxxxxxxxxxxxxxx [mailto:wix-users-admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Bill Arnette Sent: Thursday, December 09, 2004 9:56 AM To: wix-users@xxxxxxxxxxxxxxxxxxxxx Subject: RE: [WiX-users] Best way to register dlls   -----Original Message----- From: wix-users-admin@xxxxxxxxxxxxxxxxxxxxx [mailto:wix-users-admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Bob Arnson Sent: Thursday, December 09, 2004 12:40 PM To: robmen@xxxxxxxxxxxxxxxxxxxxx; 'Bob Arnson'; 'Monte Brown'; wix-users@xxxxxxxxxxxxxxxxxxxxx Subject: RE: [WiX-users] Best way to register dlls The only downside I can see is that you'd have to set up the environment so devs could easily debug the installed bits.   The biggest problem is getting people to buy into the idea; inertia is what keeps self-reg alive.    That, and there are some SDKs (read DirectShow) which *require* you to register using their registrar because it does some extra *undocumented* registration in addition to the COM server registration.  If the DirectShow team would document these entries, then DirectShow filter authors could move away from self-registration completely.      

Next Message by Date: click to view message preview

RE: Best way to register dlls

Counter points for each: 1. First, your installation needs to run even when the application is broken. If your installation cannot run then your application will stay broken. Essentially, the more dependencies your installation has the less likely it is to run. Each SelfReg adds more dependencies that are not declared anywhere. Finally, if you plan to use the fact that SelfReg fails to detect that your application will not run on your customer's machine, I'd seriously suggest you look at more friendly ways of letting the user know that their machine does not have the necessary prerequisites. Second, I fundamentally disagree that most of the problems with SelfReg are missing DLL dependencies. At least, in the 3 years I spent supporting the Office 2000 product we saw SelfReg fail in just about every way possible. Fundamentally, you can assume that if your product is successful you will find a customer's machines that will cause each line of code to fail. Assuming anything less means your Product Support people will be very busy. 2. I haven't used ATL or MFC in a very long time (and never really worked with VB) so I'm not familiar with the tools that push you in the direction in SelfReg. However, I am aware that they exist and I'm open to suggestions on how to make it easier to move away from SelfReg. Tallow was a first attempt to make that easier, there is probably more. 3. I'm sorry, arguing that developers can be lazy is not an argument I will accept. You're writing software that will run on your customers' machines. Hosing a customer's machine because a developer didn't want to do a little extra work is not something that I can fathom. I also have to ask, have you truly tried maintaining your registry keys in the WiX format? How much extra work is it, really? Finally, SelfReg philosophically goes against what we have learned is the best way to do installation, namely data driven installation. Data driven allows an engine to calculate the installation/uninstallation script, create a compensating transaction for the script, and then execute the script. Most importantly, the engine can be tested and improved to the point where the script execution and rollback handles all of various failure cases (except the most catastrophic failures, like CPU on fire). SelfReg is block of imperative code in a black box. Anything can be done inside that black box. More importantly, it is not possible to reflect into the operations of that black box and incorporate that code into the script as individual actions. Finally, SelfReg code does not benefit from the stability improvements that the engine will bring over time. Each individual black box has to improve on their own. I know you can mitigate this by sharing code (like using the MFC/ATL mechanisms to write registry keys for you) but you'll keep finding more things that need to be shared... for example, how do you reference count registry written by SelfReg? What you find is that very quickly, you need to have a data driven engine that takes care of these things. Unfortunately, it's something of a paradigm shift and when people refuse to make it, the certain parts of the world doesn't really improve... SelfReg is one of those old concepts that needs to die. All of this is going into a blog entry that I've needed to write forever... called "SelfReg is evil." -----Original Message----- From: wix-users-admin@xxxxxxxxxxxxxxxxxxxxx [mailto:wix-users-admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Stefan Zschocke Sent: Thursday, December 09, 2004 9:53 AM To: wix-users@xxxxxxxxxxxxxxxxxxxxx Subject: RE: [WiX-users] Best way to register dlls Hi, This prbly has been discussed a lot already on this list, but still I want to throw in a few arguments in favor of selfregistration: 1. If a DLL fails to self-register, then most prbly the reason is, that dependencies are missing. Thus it won't run either. If it won't run it is better the setup fails, than afterwards the application. 2. Maintenance of DLL-registration information for DLLs built with the common tools (ATL, MFC and VB) is designed to be automatically included and maintained as resource, ready for self-registration. I think it is errorprone to maintain this registry information manually at yet another place - the wix-source. As long as the mentioned tools don't interop with this concept of having the registry-keys in the wix-source I don't see why I should fiddle around with it. 3. It is much less work. Certainly there might be situations, where it is more suitable to do it the tallow-way, for example when dependencies cause problems with the DLL-loading at setup-time. Also the EXE-Server situation might be different, but why being so strictly against it? I think it is a good thing to have the reg-info and tlb of a component just inside the component (it is the first step in direction of reflection), and if for some reason MSI has certain shortcomes with handling these infos (which I have not yet experienced) then these should be mended in the first place. Stefan -----Ursprüngliche Nachricht----- Von: Rob Mensching [mailto:robmen@xxxxxxxxxxxxxxxxxxxxx] Gesendet: Donnerstag, 9. Dezember 2004 18:13 An: s.zschocke@xxxxxxxxxxx; wix-users@xxxxxxxxxxxxxxxxxxxxx Cc: mbrown@xxxxxxxxxxxxxx Betreff: RE: [WiX-users] Best way to register dlls However, the MSI will not take care of unregistering if the user cancels your install or an error occurs. That plus several other reasons is why the MSI SDK explicitly states that SelfReg should be avoided (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/se tup/selfreg_table.asp). Personally, I've seen SelfReg turn out to be one of the highest causes of failure of installs in the "real world". It might seem to work great in your controlled environment. Send your installation out to your customers and (if you get the feedback) you'll be amazed how much SelfReg fails. My suggestion is to use the Registry table for all of your registration. Full stop. Monte, tallow is not intended to be used in the build system and that's why it does not generate completely friendly output. The intention of tallow is that you'll get your SelfReg code translated into WiX source code once then have the developers maintain the registry keys in the WiX source instead of maintaining code that writes the keys. -----Original Message----- From: wix-users-admin@xxxxxxxxxxxxxxxxxxxxx [mailto:wix-users-admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Stefan Zschocke Sent: Thursday, December 09, 2004 8:20 AM To: wix-users@xxxxxxxxxxxxxxxxxxxxx Subject: AW: [WiX-users] Best way to register dlls Hi, whereas the major players in this league seem to favor using tallow for including the whole registry script, I myself am completely satisfied with the built-in facility of MSI. This is achieved by simply adding the attribute SelfRegCost='0' to the file-tag. In my case this is: <Component Id='jacoZoomAx' Guid='59A98F0B-6720-4822-B162-23B644B328D5'> <File Id='izmjnicomax' LongName='izmjnicomax.dll' Name='izmjnicx.dll' DiskId='1' SelfRegCost='0' src='c:\images\jacoZoom\izmjnicomax.dll' Vital='yes' /> </Component> MSI takes care of unregistering, too. Stefan ------------------------------------------------------- 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/ _______________________________________________ WiX-users mailing list WiX-users@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------- 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/ _______________________________________________ WiX-users mailing list WiX-users@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------- 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/

Previous Message by Thread: click to view message preview

RE: C++ Anyone?

Is there a some sensitive information that prevents you from sending the information to the wix-devs@xxxxxxxxxxxxxxxxxxxxx list? If not, I'd recommend going there. You might get more input from people. Also, the WiX CustomAction library (wixca.lib) has lots of helper code to do these type of CustomActions correctly. You'll definitely want to think about how the immediate CustomAction communicates with the deferred CustomAction(s) so you can handle rollback correctly. The wixca.lib has code to help there too... -----Original Message----- From: wix-users-admin@xxxxxxxxxxxxxxxxxxxxx [mailto:wix-users-admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Michael Sanford Sent: Thursday, December 09, 2004 8:37 AM To: s.zschocke@xxxxxxxxxxx; wix-users@xxxxxxxxxxxxxxxxxxxxx Subject: RE: [WiX-users] C++ Anyone? Thanks Stefan -- I've emailed you off the list to work out the details! -----Original Message----- From: wix-users-admin@xxxxxxxxxxxxxxxxxxxxx [mailto:wix-users-admin@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Stefan Zschocke Sent: Thursday, December 09, 2004 11:23 AM To: wix-users@xxxxxxxxxxxxxxxxxxxxx Subject: RE: [WiX-users] C++ Anyone? Hi, I have succeeded in writing a C++ custom action and to pass parameters to it via properties. And also I know how to program the Windows API. So, certainly I could help you out.. Stefan ----- Original Message ----- C++ Anyone? Hi, I need to extend the functionality of the WiX custom actions to give a newly created user account the rights needed to install a service. As I understand it, the Lsa* functions in advapi32.dll will do the trick. Here's what I think has to be done: Look up the SID using LsaLookupNames Get a Policy handle by calling LsaOpenPolicy Create an array of LSA_UNICODE_STRING structures with a single element containing SE_TCB_NAME Call LsaAddAccountRights Clean Up The net result should be that the newly created user with this added privilege should be able to be used for a ServiceInstall. I'm looking for a C++ guy to build this custom action for me. I can pay a small amount for your time and effort, and will gladly share the code with the community. If anyone is interested, please let me know right away as timing is very critical! Michael ------------------------------------------------------- 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/

Next Message by Thread: click to view message preview

Best way to register dlls

Hello, I am working on an installer which has several COM dll's that have to be registered. It seems like there are two approaches available to me: - use custom actions to call regsvr32 or a script that calls regsvr32 for each component and regsvr32 -u for uninstall. - write a script that calls tallow -s for each dll that can be added to our build process and a xslt to get the resulting xml into the right form (to avoid having duplicate component0 and file0 from the output of tallow). This would be part of the build to so that when the dlls change the installer doesn’t break. Which method is preferable? Is there a simpler way I'm failing to see? Is the first method just as good or does it lead to problems with the repair functionality or deploying with SMS? Thanks, Monte