Sorry for my previous empty post. Must've got sent by accident. Thanks, Peter, for your ideas. I’ll consider them.
>>Cant you just upgrade the older installer with the fixes to A, keeping B as it was at release, and make that available to old users for download? The old installer (pre-2010) did not include B. Yes, I could make two separate upgrade installers, but it would get confusing for users to know which one they were supposed to use. >>Then make a later version of that installer with the new version of B and make that available for new users on CD. Upgrading people by sending them another CD would work but is kind of tough. It requires them to call up to ask for it, and would be a cost to us. I guess it depends how many of those users are out there, which I don’t know. I may have misunderstood your suggestion, though. >>If you don't want to make an upgrade installer you could make the upgrade available as a patch (.msp) for older users. The patch would only contain the changes to component A and couldn't be used without the older installer. A patch is harder to write than a major upgrade but, if you haven't violated component rules, it might work for you. Yes that’s one possibility and I thought of that, too. I’m not so familiar with patches so I’ll have to look into it. If it happens that we want to update the driver part of it I’m not sure a driver can be patched. We use DIFxApp for that. I had another thought along the lines of the workaround I mentioned earlier. I’m going to see if I can make an upgrade that can include a dummy component B and then use a condition for it that which is always false so B doesn't get installed. If that doesn’t work because it still removes existing, installed component Bs (which I don’t want), then I’ll try to set the condition dynamically at runtime depending on whether I find component B already on hard disk. I’m not sure if that’s possible or if it will work so I’ll need to experiment. Thanks! Jim -----Original Message----- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: Thursday, June 09, 2011 1:37 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Upgrade without providing or removing some previouscomponent. Cant you just upgrade the older installer with the fixes to A, keeping B as it was at release, and make that available to old users for download ? Then make a later version of that installer with the new version of B and make that available for new users on CD. If you don't want to make an upgrade installer you could make the upgrade available as a patch (.msp) for older users. The patch would only contain the changes to component A and couldn't be used without the older installer. A patch is harder to write than a major upgrade but, if you haven't violated component rules, it might work for you. -----Original Message----- From: Jim Hewes [mailto:jimhe...@gmail.com] Sent: 09 June 2011 01:03 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Upgrade without providing or removing some previous component. Due to my lack of expertise in installers, I think I got into a bad situation with the wrong installer arrangement and I'm wondering what the best way out of it is. I'm using WiX 3.0, but this is a more general install problem so let me know if it's not appropriate to ask here. I have an installer that installs two components A and B both within the same feature. Component A is a device driver and some associated software. Component B is a third-party library comprised of two DLLs and is used by the driver/software. This third-party library requires a per-unit license. We distribute this on CD with the device and so by counting the CDs we can keep track of the licenses. We began including the library on the CD last year. But there are older owners of the device who would want to download the new version. We cannot put this installer on the web for download because we can't count or track those licenses. So the problem is, we want to upgrade Component A with bug fixes and make it available for web download. But we can't include component B for license reasons---because older users shouldn't get it for free. But if I leave component B out of the upgrade, I believe the upgrade process will remove B from the hard disk of legitimate owners of it. (I know if I had at least made component B as a separate feature, I could specify that it not be removed and do a major upgrade. But it's too late at this point.) My best workaround idea so far is for the upgrade to include dummy DLLs for component B that have a lower version number than the real ones. So when an upgrade happens, the real DLLs already on hard disk will be left alone. And for older users who don't have the license to the library, they will just get the dummy DLLs installed. It's messy, and I hate to think I have to do this for the life of the product. Is there a better way? I think for the future I will put component B completely in its own installer and put that only on the CD. But that doesn't help the current problem. Thanks for any help, Jim ------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
