Re: [WiX-users] Adding a new dependent file to shared component without breaking component rules
Hi Dave, Yeah, I agree that's a good solution. However, one of the constraints of the shared component is that we can only have one COM registered (it integrates into a thirdparty application). So reversion/relocate and re-guid is not available as a solution. (We did workshop a development solution that would resolve the problem and allow us to re-guid for correct deployment, but the face the Engineering Manager pulled told the story :) .) The idea of a separate msi isn't too bad - I guess I'd be able to do something so that when all products that depend upon the shared component are uninstalled then it would also be uninstalled. I'm a very recent upgrader from WiX 2 to WiX 3, so not sure if Burn, etc would help me do this. However, again, dollars will win over technical correctness - the likelihood of this problem affecting a client is quite low and the fix is relatively simple for our support team to resolve, so I don't think I'll get much support for doing the work. Everyone's advice has definitely helped though - at least we understand the problem that we're creating for ourselves, which is much better than doing it by accident. Once again, thanks to all for the input, I appreciate it. Cheers, Michael -Original Message- From: David Watson [mailto:dwat...@sdl.com] Sent: Wednesday, 14 August 2013 7:36 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Adding a new dependent file to shared component without breaking component rules When we release side by side versions of products we have to reversion/relocate(re-guid if com) all our shared components. e.g. All file major versions are increased and we install into different locations. All com components have version dependent naming and are reworked to not clash with previous versions. This may not be an option if it is a third party com component though, but there is the potential to use registry free com but this does have limitations. %commonfiles%\my company\product1shared %commonfiles%\my company\product2shared %programfiles%\my company\product\product1 % programfiles %\my company\product\product2 If you are not dealing with com you can load your dependencies dynamically from the new common folder in the later version of the software. Beyond that you are getting into bad practices. Could you install the dependent dll (or shared components) in a separate msi that doesn't get uninstalled automatically on product2 removal. Or some horrendous custom action that puts the dependent dll back if you are removing it and will break product1. Dave -Original Message- From: Michael Partridge [mailto:michael.partri...@petrosys.com.au] Sent: 14 August 2013 03:39 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Adding a new dependent file to shared component without breaking component rules Thanks to all for the feedback. I do agree with the consensus that Product1 is broken and should be fixed with an upgrade or patch. However, in the real world, that isn't going to happen in this case. As I said, Product1 and Product2 are side-by-side installs of the same application, where there is separate Product for each major version shipped. So, in my example Product1 is really a placeholder representing 12 different Products (which then all have their own minor version history). I know I'll never get the resources to make the fix for all these versions, unfortunate situation where money wins over perfection. At least I understand (correctly!) the compromise we're making. (And yeah, we do have a service plan for all our earlier versions for, say, security issues, but this issue won't be high enough up the list to trigger one of those. I will keep a record and put in the fix if we do create a new version of one of the existing "Product1"'s.) Thanks again for the useful input. Cheers, Michael Ps. I have pushed back to the developer to see if we can remove this additional dependency, but unsure if that will be possible. -Original Message- From: Phil Wilson [mailto:phil.wil...@mvps.org] Sent: Wednesday, 14 August 2013 8:08 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Adding a new dependent file to shared component without breaking component rules I agree. A common shared component has been updated and it needs fixing in all the products because it can no longer be shared properly. Phil -Original Message- From: David Watson [mailto:dwat...@sdl.com] Sent: Tuesday, August 13, 2013 10:14 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Adding a new dependent fileger to shared component without breaking component rules This is now a bug in product1. It needs fixing at a priority that your product owner decides. You must have an update strategy for
Re: [WiX-users] Adding a new dependent file to shared component without breaking component rules
When we release side by side versions of products we have to reversion/relocate(re-guid if com) all our shared components. e.g. All file major versions are increased and we install into different locations. All com components have version dependent naming and are reworked to not clash with previous versions. This may not be an option if it is a third party com component though, but there is the potential to use registry free com but this does have limitations. %commonfiles%\my company\product1shared %commonfiles%\my company\product2shared %programfiles%\my company\product\product1 % programfiles %\my company\product\product2 If you are not dealing with com you can load your dependencies dynamically from the new common folder in the later version of the software. Beyond that you are getting into bad practices. Could you install the dependent dll (or shared components) in a separate msi that doesn't get uninstalled automatically on product2 removal. Or some horrendous custom action that puts the dependent dll back if you are removing it and will break product1. Dave -Original Message- From: Michael Partridge [mailto:michael.partri...@petrosys.com.au] Sent: 14 August 2013 03:39 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Adding a new dependent file to shared component without breaking component rules Thanks to all for the feedback. I do agree with the consensus that Product1 is broken and should be fixed with an upgrade or patch. However, in the real world, that isn't going to happen in this case. As I said, Product1 and Product2 are side-by-side installs of the same application, where there is separate Product for each major version shipped. So, in my example Product1 is really a placeholder representing 12 different Products (which then all have their own minor version history). I know I'll never get the resources to make the fix for all these versions, unfortunate situation where money wins over perfection. At least I understand (correctly!) the compromise we're making. (And yeah, we do have a service plan for all our earlier versions for, say, security issues, but this issue won't be high enough up the list to trigger one of those. I will keep a record and put in the fix if we do create a new version of one of the existing "Product1"'s.) Thanks again for the useful input. Cheers, Michael Ps. I have pushed back to the developer to see if we can remove this additional dependency, but unsure if that will be possible. -Original Message- From: Phil Wilson [mailto:phil.wil...@mvps.org] Sent: Wednesday, 14 August 2013 8:08 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Adding a new dependent file to shared component without breaking component rules I agree. A common shared component has been updated and it needs fixing in all the products because it can no longer be shared properly. Phil -Original Message- From: David Watson [mailto:dwat...@sdl.com] Sent: Tuesday, August 13, 2013 10:14 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Adding a new dependent fileger to shared component without breaking component rules This is now a bug in product1. It needs fixing at a priority that your product owner decides. You must have an update strategy for that product, what if it has a critical security issue/flaw? You could release product2 as a burn bundle and include a fix in it for product1 by adding a major upgrade msi or msp to it along with your product2 msi. Dave -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 13 August 2013 15:16 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Adding a new dependent file to shared component without breaking component rules No, don't force features to not be uninstalled when uninstalling. Crazy things will happen. In general, don't mess with feature selection lightly. Michael, I misread the word "dependency". I think you have analyzed the math on this correctly. This is one of the scenarios where the Component Rules are fundamentally broken. Windows Installer expected you to not add dependencies like this... but devs will be devs and it'd be nice if they actually handled it correctly. On Tue, Aug 13, 2013 at 2:55 AM, Blair Murri wrote: > You could put D2.dll into its own feature, and force that feature to > not be removed on product removal if product 1 is still installed. You > get the same "effect" of D2.dll getting orphaned but at least you > don't perpetrate the problems of sharing binaries in the same > component in all other scenarios. > > > From: michael.partri...@petrosys.com.au > > To: wix-users@lists.sourceforge.net > > Date: Tue, 13 Aug 2013 04:07:56 + > > Subject: Re: [WiX-users] Adding
Re: [WiX-users] Adding a new dependent file to shared component without breaking component rules
Thanks to all for the feedback. I do agree with the consensus that Product1 is broken and should be fixed with an upgrade or patch. However, in the real world, that isn't going to happen in this case. As I said, Product1 and Product2 are side-by-side installs of the same application, where there is separate Product for each major version shipped. So, in my example Product1 is really a placeholder representing 12 different Products (which then all have their own minor version history). I know I'll never get the resources to make the fix for all these versions, unfortunate situation where money wins over perfection. At least I understand (correctly!) the compromise we're making. (And yeah, we do have a service plan for all our earlier versions for, say, security issues, but this issue won't be high enough up the list to trigger one of those. I will keep a record and put in the fix if we do create a new version of one of the existing "Product1"'s.) Thanks again for the useful input. Cheers, Michael Ps. I have pushed back to the developer to see if we can remove this additional dependency, but unsure if that will be possible. -Original Message- From: Phil Wilson [mailto:phil.wil...@mvps.org] Sent: Wednesday, 14 August 2013 8:08 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Adding a new dependent file to shared component without breaking component rules I agree. A common shared component has been updated and it needs fixing in all the products because it can no longer be shared properly. Phil -Original Message- From: David Watson [mailto:dwat...@sdl.com] Sent: Tuesday, August 13, 2013 10:14 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Adding a new dependent fileger to shared component without breaking component rules This is now a bug in product1. It needs fixing at a priority that your product owner decides. You must have an update strategy for that product, what if it has a critical security issue/flaw? You could release product2 as a burn bundle and include a fix in it for product1 by adding a major upgrade msi or msp to it along with your product2 msi. Dave -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 13 August 2013 15:16 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Adding a new dependent file to shared component without breaking component rules No, don't force features to not be uninstalled when uninstalling. Crazy things will happen. In general, don't mess with feature selection lightly. Michael, I misread the word "dependency". I think you have analyzed the math on this correctly. This is one of the scenarios where the Component Rules are fundamentally broken. Windows Installer expected you to not add dependencies like this... but devs will be devs and it'd be nice if they actually handled it correctly. On Tue, Aug 13, 2013 at 2:55 AM, Blair Murri wrote: > You could put D2.dll into its own feature, and force that feature to > not be removed on product removal if product 1 is still installed. You > get the same "effect" of D2.dll getting orphaned but at least you > don't perpetrate the problems of sharing binaries in the same > component in all other scenarios. > > > From: michael.partri...@petrosys.com.au > > To: wix-users@lists.sourceforge.net > > Date: Tue, 13 Aug 2013 04:07:56 + > > Subject: Re: [WiX-users] Adding a new dependent file to shared > > component > without breaking component rules > > > > If I put D2.dll in its own component, then, assuming Product1 and > Product2 installed, when Product2 is uninstalled, D2.dll will be removed. > However, A.dll will still be at version 1.1.0, so will have lost its > dependency and thusly won't run. > > > > NB: I can't change Product1 - it's already in the field and won't > > have > any updates. In reality Product1 and Product2 are different versions > of our product that can be installed side-by-side - users like to have > access to previous versions. > > > > Cheers, > > Michael > > > > -----Original Message----- > > From: Rob Mensching [mailto:r...@robmensching.com] > > Sent: Monday, 12 August 2013 6:14 PM > > To: General discussion for Windows Installer XML toolset. > > Subject: Re: [WiX-users] Adding a new dependent file to shared > > component > without breaking component rules > > > > Why not put D2.dll in it's own Component? > > > > > > On Sun, Aug 11, 2013 at 10:37 PM, Michael Partridge < > michael.partri...@petrosys.com.au> wrote: > > > > > Hi All, > > > > > > I was wond
Re: [WiX-users] Adding a new dependent file to shared component without breaking component rules
I agree. A common shared component has been updated and it needs fixing in all the products because it can no longer be shared properly. Phil -Original Message- From: David Watson [mailto:dwat...@sdl.com] Sent: Tuesday, August 13, 2013 10:14 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Adding a new dependent fileger to shared component without breaking component rules This is now a bug in product1. It needs fixing at a priority that your product owner decides. You must have an update strategy for that product, what if it has a critical security issue/flaw? You could release product2 as a burn bundle and include a fix in it for product1 by adding a major upgrade msi or msp to it along with your product2 msi. Dave -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 13 August 2013 15:16 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Adding a new dependent file to shared component without breaking component rules No, don't force features to not be uninstalled when uninstalling. Crazy things will happen. In general, don't mess with feature selection lightly. Michael, I misread the word "dependency". I think you have analyzed the math on this correctly. This is one of the scenarios where the Component Rules are fundamentally broken. Windows Installer expected you to not add dependencies like this... but devs will be devs and it'd be nice if they actually handled it correctly. On Tue, Aug 13, 2013 at 2:55 AM, Blair Murri wrote: > You could put D2.dll into its own feature, and force that feature to > not be removed on product removal if product 1 is still installed. You > get the same "effect" of D2.dll getting orphaned but at least you > don't perpetrate the problems of sharing binaries in the same > component in all other scenarios. > > > From: michael.partri...@petrosys.com.au > > To: wix-users@lists.sourceforge.net > > Date: Tue, 13 Aug 2013 04:07:56 +0000 > > Subject: Re: [WiX-users] Adding a new dependent file to shared > > component > without breaking component rules > > > > If I put D2.dll in its own component, then, assuming Product1 and > Product2 installed, when Product2 is uninstalled, D2.dll will be removed. > However, A.dll will still be at version 1.1.0, so will have lost its > dependency and thusly won't run. > > > > NB: I can't change Product1 - it's already in the field and won't > > have > any updates. In reality Product1 and Product2 are different versions > of our product that can be installed side-by-side - users like to have > access to previous versions. > > > > Cheers, > > Michael > > > > -Original Message----- > > From: Rob Mensching [mailto:r...@robmensching.com] > > Sent: Monday, 12 August 2013 6:14 PM > > To: General discussion for Windows Installer XML toolset. > > Subject: Re: [WiX-users] Adding a new dependent file to shared > > component > without breaking component rules > > > > Why not put D2.dll in it's own Component? > > > > > > On Sun, Aug 11, 2013 at 10:37 PM, Michael Partridge < > michael.partri...@petrosys.com.au> wrote: > > > > > Hi All, > > > > > > I was wondering if the state of play has changed at all since > > > > http://stackoverflow.com/questions/703359/wix-add-new-file-to-shared-compone n twasdiscussed? > > > > > > Basically, I have Product1 (already released) and Product2 (in > > > development) which both share the same component A.dll. A.dll is > > > installed to %COMMONFILES%/MyProducts/. > > > > > > Product1 installs A.dll version 1.0.0, which is dependent upon D1.dll. > > > Product2 installs A.dll version 1.1.0, which is dependent upon > > > D1.dll and D2.dll. > > > > > > Due to the way that A.dll is used (it's a COM component registered > > > in a thirdparty application, and we can only register one .dll) > > > there isn't the option of creating newA.dll and putting that into Product2. > > > (At least not without breaking Product1.) > > > > > > I think my only option is to add D2.dll in A.dll's component, > > > breaking the component rules, and live with the fact that D2.dll > > > will remain on the user's computer if they uninstall Product2 then > > > uninstall Product1. At least then, if someone uninstalls Product2 > > > our .dll will continue to run correctly. > > > > > > Does anyone have any further insight? > > > > > > Thanks, > > > Michael > > >
Re: [WiX-users] Adding a new dependent file to shared component without breaking component rules
I stand corrected. Rob Mensching wrote: No, don't force features to not be uninstalled when uninstalling. Crazy things will happen. In general, don't mess with feature selection lightly. Michael, I misread the word "dependency". I think you have analyzed the math on this correctly. This is one of the scenarios where the Component Rules are fundamentally broken. Windows Installer expected you to not add dependencies like this... but devs will be devs and it'd be nice if they actually handled it correctly. On Tue, Aug 13, 2013 at 2:55 AM, Blair Murri wrote: > You could put D2.dll into its own feature, and force that feature to not > be removed on product removal if product 1 is still installed. You get the > same "effect" of D2.dll getting orphaned but at least you don't perpetrate > the problems of sharing binaries in the same component in all other > scenarios. > > > From: michael.partri...@petrosys.com.au > > To: wix-users@lists.sourceforge.net > > Date: Tue, 13 Aug 2013 04:07:56 + > > Subject: Re: [WiX-users] Adding a new dependent file to shared component > without breaking component rules > > > > If I put D2.dll in its own component, then, assuming Product1 and > Product2 installed, when Product2 is uninstalled, D2.dll will be removed. > However, A.dll will still be at version 1.1.0, so will have lost its > dependency and thusly won't run. > > > > NB: I can't change Product1 - it's already in the field and won't have > any updates. In reality Product1 and Product2 are different versions of our > product that can be installed side-by-side - users like to have access to > previous versions. > > > > Cheers, > > Michael > > > > -Original Message- > > From: Rob Mensching [mailto:r...@robmensching.com] > > Sent: Monday, 12 August 2013 6:14 PM > > To: General discussion for Windows Installer XML toolset. > > Subject: Re: [WiX-users] Adding a new dependent file to shared component > without breaking component rules > > > > Why not put D2.dll in it's own Component? > > > > > > On Sun, Aug 11, 2013 at 10:37 PM, Michael Partridge < > michael.partri...@petrosys.com.au> wrote: > > > > > Hi All, > > > > > > I was wondering if the state of play has changed at all since > > > > http://stackoverflow.com/questions/703359/wix-add-new-file-to-shared-componentwasdiscussed? > > > > > > Basically, I have Product1 (already released) and Product2 (in > > > development) which both share the same component A.dll. A.dll is > > > installed to %COMMONFILES%/MyProducts/. > > > > > > Product1 installs A.dll version 1.0.0, which is dependent upon D1.dll. > > > Product2 installs A.dll version 1.1.0, which is dependent upon D1.dll > > > and D2.dll. > > > > > > Due to the way that A.dll is used (it's a COM component registered in > > > a thirdparty application, and we can only register one .dll) there > > > isn't the option of creating newA.dll and putting that into Product2. > > > (At least not without breaking Product1.) > > > > > > I think my only option is to add D2.dll in A.dll's component, breaking > > > the component rules, and live with the fact that D2.dll will remain on > > > the user's computer if they uninstall Product2 then uninstall > > > Product1. At least then, if someone uninstalls Product2 our .dll will > > > continue to run correctly. > > > > > > Does anyone have any further insight? > > > > > > Thanks, > > > Michael > > > > > > -- > > > Get 100% visibility into Java/.NET code with AppDynamics > > > Lite! > > > It's a free troubleshooting tool designed for production. > > > Get down to code-level detail for bottlenecks, with <2% overhead. > > > Download for free and get started troubleshooting in minutes. > > > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.c > > > lktrk ___ > > > WiX-users mailing list > > > WiX-users@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > > > > > > -- > > Get 100% visibility into Java/.NET code with AppDynamics Lite! > > It's a free troubleshooting tool designed for production. > > Get down to code-level detail for bottlen
Re: [WiX-users] Adding a new dependent file to shared component without breaking component rules
This is now a bug in product1. It needs fixing at a priority that your product owner decides. You must have an update strategy for that product, what if it has a critical security issue/flaw? You could release product2 as a burn bundle and include a fix in it for product1 by adding a major upgrade msi or msp to it along with your product2 msi. Dave -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 13 August 2013 15:16 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Adding a new dependent file to shared component without breaking component rules No, don't force features to not be uninstalled when uninstalling. Crazy things will happen. In general, don't mess with feature selection lightly. Michael, I misread the word "dependency". I think you have analyzed the math on this correctly. This is one of the scenarios where the Component Rules are fundamentally broken. Windows Installer expected you to not add dependencies like this... but devs will be devs and it'd be nice if they actually handled it correctly. On Tue, Aug 13, 2013 at 2:55 AM, Blair Murri wrote: > You could put D2.dll into its own feature, and force that feature to > not be removed on product removal if product 1 is still installed. You > get the same "effect" of D2.dll getting orphaned but at least you > don't perpetrate the problems of sharing binaries in the same > component in all other scenarios. > > > From: michael.partri...@petrosys.com.au > > To: wix-users@lists.sourceforge.net > > Date: Tue, 13 Aug 2013 04:07:56 +0000 > > Subject: Re: [WiX-users] Adding a new dependent file to shared > > component > without breaking component rules > > > > If I put D2.dll in its own component, then, assuming Product1 and > Product2 installed, when Product2 is uninstalled, D2.dll will be removed. > However, A.dll will still be at version 1.1.0, so will have lost its > dependency and thusly won't run. > > > > NB: I can't change Product1 - it's already in the field and won't > > have > any updates. In reality Product1 and Product2 are different versions > of our product that can be installed side-by-side - users like to have > access to previous versions. > > > > Cheers, > > Michael > > > > -Original Message----- > > From: Rob Mensching [mailto:r...@robmensching.com] > > Sent: Monday, 12 August 2013 6:14 PM > > To: General discussion for Windows Installer XML toolset. > > Subject: Re: [WiX-users] Adding a new dependent file to shared > > component > without breaking component rules > > > > Why not put D2.dll in it's own Component? > > > > > > On Sun, Aug 11, 2013 at 10:37 PM, Michael Partridge < > michael.partri...@petrosys.com.au> wrote: > > > > > Hi All, > > > > > > I was wondering if the state of play has changed at all since > > > > http://stackoverflow.com/questions/703359/wix-add-new-file-to-shared-componen twasdiscussed? > > > > > > Basically, I have Product1 (already released) and Product2 (in > > > development) which both share the same component A.dll. A.dll is > > > installed to %COMMONFILES%/MyProducts/. > > > > > > Product1 installs A.dll version 1.0.0, which is dependent upon D1.dll. > > > Product2 installs A.dll version 1.1.0, which is dependent upon > > > D1.dll and D2.dll. > > > > > > Due to the way that A.dll is used (it's a COM component registered > > > in a thirdparty application, and we can only register one .dll) > > > there isn't the option of creating newA.dll and putting that into Product2. > > > (At least not without breaking Product1.) > > > > > > I think my only option is to add D2.dll in A.dll's component, > > > breaking the component rules, and live with the fact that D2.dll > > > will remain on the user's computer if they uninstall Product2 then > > > uninstall Product1. At least then, if someone uninstalls Product2 > > > our .dll will continue to run correctly. > > > > > > Does anyone have any further insight? > > > > > > Thanks, > > > Michael > > > > > > -- > > > > > > Get 100% visibility into Java/.NET code with AppDynamics > > > Lite! > > > It's a free troubleshooting tool designed for production. > > > Get down to code-level detail for bottlenecks, with <2% overhead. > > > Download for free and get started tro
Re: [WiX-users] Adding a new dependent file to shared component without breaking component rules
No, don't force features to not be uninstalled when uninstalling. Crazy things will happen. In general, don't mess with feature selection lightly. Michael, I misread the word "dependency". I think you have analyzed the math on this correctly. This is one of the scenarios where the Component Rules are fundamentally broken. Windows Installer expected you to not add dependencies like this... but devs will be devs and it'd be nice if they actually handled it correctly. On Tue, Aug 13, 2013 at 2:55 AM, Blair Murri wrote: > You could put D2.dll into its own feature, and force that feature to not > be removed on product removal if product 1 is still installed. You get the > same "effect" of D2.dll getting orphaned but at least you don't perpetrate > the problems of sharing binaries in the same component in all other > scenarios. > > > From: michael.partri...@petrosys.com.au > > To: wix-users@lists.sourceforge.net > > Date: Tue, 13 Aug 2013 04:07:56 + > > Subject: Re: [WiX-users] Adding a new dependent file to shared component > without breaking component rules > > > > If I put D2.dll in its own component, then, assuming Product1 and > Product2 installed, when Product2 is uninstalled, D2.dll will be removed. > However, A.dll will still be at version 1.1.0, so will have lost its > dependency and thusly won't run. > > > > NB: I can't change Product1 - it's already in the field and won't have > any updates. In reality Product1 and Product2 are different versions of our > product that can be installed side-by-side - users like to have access to > previous versions. > > > > Cheers, > > Michael > > > > -Original Message- > > From: Rob Mensching [mailto:r...@robmensching.com] > > Sent: Monday, 12 August 2013 6:14 PM > > To: General discussion for Windows Installer XML toolset. > > Subject: Re: [WiX-users] Adding a new dependent file to shared component > without breaking component rules > > > > Why not put D2.dll in it's own Component? > > > > > > On Sun, Aug 11, 2013 at 10:37 PM, Michael Partridge < > michael.partri...@petrosys.com.au> wrote: > > > > > Hi All, > > > > > > I was wondering if the state of play has changed at all since > > > > http://stackoverflow.com/questions/703359/wix-add-new-file-to-shared-componentwasdiscussed? > > > > > > Basically, I have Product1 (already released) and Product2 (in > > > development) which both share the same component A.dll. A.dll is > > > installed to %COMMONFILES%/MyProducts/. > > > > > > Product1 installs A.dll version 1.0.0, which is dependent upon D1.dll. > > > Product2 installs A.dll version 1.1.0, which is dependent upon D1.dll > > > and D2.dll. > > > > > > Due to the way that A.dll is used (it's a COM component registered in > > > a thirdparty application, and we can only register one .dll) there > > > isn't the option of creating newA.dll and putting that into Product2. > > > (At least not without breaking Product1.) > > > > > > I think my only option is to add D2.dll in A.dll's component, breaking > > > the component rules, and live with the fact that D2.dll will remain on > > > the user's computer if they uninstall Product2 then uninstall > > > Product1. At least then, if someone uninstalls Product2 our .dll will > > > continue to run correctly. > > > > > > Does anyone have any further insight? > > > > > > Thanks, > > > Michael > > > > > > -- > > > Get 100% visibility into Java/.NET code with AppDynamics > > > Lite! > > > It's a free troubleshooting tool designed for production. > > > Get down to code-level detail for bottlenecks, with <2% overhead. > > > Download for free and get started troubleshooting in minutes. > > > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.c > > > lktrk ___ > > > WiX-users mailing list > > > WiX-users@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > > > > > > -- > > Get 100% visibility into Java/.NET code with AppDynamics Lite! > > It's a free troubleshooting tool designed for production. > > Get down to code-level detail for bottlenecks, with <2% overhead. > > Download
Re: [WiX-users] Adding a new dependent file to shared component without breaking component rules
You could put D2.dll into its own feature, and force that feature to not be removed on product removal if product 1 is still installed. You get the same "effect" of D2.dll getting orphaned but at least you don't perpetrate the problems of sharing binaries in the same component in all other scenarios. > From: michael.partri...@petrosys.com.au > To: wix-users@lists.sourceforge.net > Date: Tue, 13 Aug 2013 04:07:56 +0000 > Subject: Re: [WiX-users] Adding a new dependent file to shared component > without breaking component rules > > If I put D2.dll in its own component, then, assuming Product1 and Product2 > installed, when Product2 is uninstalled, D2.dll will be removed. However, > A.dll will still be at version 1.1.0, so will have lost its dependency and > thusly won't run. > > NB: I can't change Product1 - it's already in the field and won't have any > updates. In reality Product1 and Product2 are different versions of our > product that can be installed side-by-side - users like to have access to > previous versions. > > Cheers, > Michael > > -Original Message- > From: Rob Mensching [mailto:r...@robmensching.com] > Sent: Monday, 12 August 2013 6:14 PM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Adding a new dependent file to shared component > without breaking component rules > > Why not put D2.dll in it's own Component? > > > On Sun, Aug 11, 2013 at 10:37 PM, Michael Partridge < > michael.partri...@petrosys.com.au> wrote: > > > Hi All, > > > > I was wondering if the state of play has changed at all since > > http://stackoverflow.com/questions/703359/wix-add-new-file-to-shared-componentwas > > discussed? > > > > Basically, I have Product1 (already released) and Product2 (in > > development) which both share the same component A.dll. A.dll is > > installed to %COMMONFILES%/MyProducts/. > > > > Product1 installs A.dll version 1.0.0, which is dependent upon D1.dll. > > Product2 installs A.dll version 1.1.0, which is dependent upon D1.dll > > and D2.dll. > > > > Due to the way that A.dll is used (it's a COM component registered in > > a thirdparty application, and we can only register one .dll) there > > isn't the option of creating newA.dll and putting that into Product2. > > (At least not without breaking Product1.) > > > > I think my only option is to add D2.dll in A.dll's component, breaking > > the component rules, and live with the fact that D2.dll will remain on > > the user's computer if they uninstall Product2 then uninstall > > Product1. At least then, if someone uninstalls Product2 our .dll will > > continue to run correctly. > > > > Does anyone have any further insight? > > > > Thanks, > > Michael > > > > -- > > Get 100% visibility into Java/.NET code with AppDynamics > > Lite! > > It's a free troubleshooting tool designed for production. > > Get down to code-level detail for bottlenecks, with <2% overhead. > > Download for free and get started troubleshooting in minutes. > > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.c > > lktrk ___ > > WiX-users mailing list > > WiX-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > > -- > Get 100% visibility into Java/.NET code with AppDynamics Lite! > It's a free troubleshooting tool designed for production. > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > -- > Get 100% visibility into Java/.NET code with AppDynamics Lite! > It's a free troubleshooting tool designed for production. > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > ___ > WiX-users mailing list > WiX-users@lists
Re: [WiX-users] Adding a new dependent file to shared component without breaking component rules
If I put D2.dll in its own component, then, assuming Product1 and Product2 installed, when Product2 is uninstalled, D2.dll will be removed. However, A.dll will still be at version 1.1.0, so will have lost its dependency and thusly won't run. NB: I can't change Product1 - it's already in the field and won't have any updates. In reality Product1 and Product2 are different versions of our product that can be installed side-by-side - users like to have access to previous versions. Cheers, Michael -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Monday, 12 August 2013 6:14 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Adding a new dependent file to shared component without breaking component rules Why not put D2.dll in it's own Component? On Sun, Aug 11, 2013 at 10:37 PM, Michael Partridge < michael.partri...@petrosys.com.au> wrote: > Hi All, > > I was wondering if the state of play has changed at all since > http://stackoverflow.com/questions/703359/wix-add-new-file-to-shared-componentwas > discussed? > > Basically, I have Product1 (already released) and Product2 (in > development) which both share the same component A.dll. A.dll is > installed to %COMMONFILES%/MyProducts/. > > Product1 installs A.dll version 1.0.0, which is dependent upon D1.dll. > Product2 installs A.dll version 1.1.0, which is dependent upon D1.dll > and D2.dll. > > Due to the way that A.dll is used (it's a COM component registered in > a thirdparty application, and we can only register one .dll) there > isn't the option of creating newA.dll and putting that into Product2. > (At least not without breaking Product1.) > > I think my only option is to add D2.dll in A.dll's component, breaking > the component rules, and live with the fact that D2.dll will remain on > the user's computer if they uninstall Product2 then uninstall > Product1. At least then, if someone uninstalls Product2 our .dll will > continue to run correctly. > > Does anyone have any further insight? > > Thanks, > Michael > > -- > Get 100% visibility into Java/.NET code with AppDynamics > Lite! > It's a free troubleshooting tool designed for production. > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.c > lktrk ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Adding a new dependent file to shared component without breaking component rules
Why not put D2.dll in it's own Component? On Sun, Aug 11, 2013 at 10:37 PM, Michael Partridge < michael.partri...@petrosys.com.au> wrote: > Hi All, > > I was wondering if the state of play has changed at all since > http://stackoverflow.com/questions/703359/wix-add-new-file-to-shared-componentwas > discussed? > > Basically, I have Product1 (already released) and Product2 (in > development) which both share the same component A.dll. A.dll is installed > to %COMMONFILES%/MyProducts/. > > Product1 installs A.dll version 1.0.0, which is dependent upon D1.dll. > Product2 installs A.dll version 1.1.0, which is dependent upon D1.dll and > D2.dll. > > Due to the way that A.dll is used (it's a COM component registered in a > thirdparty application, and we can only register one .dll) there isn't the > option of creating newA.dll and putting that into Product2. (At least not > without breaking Product1.) > > I think my only option is to add D2.dll in A.dll's component, breaking the > component rules, and live with the fact that D2.dll will remain on the > user's computer if they uninstall Product2 then uninstall Product1. At > least then, if someone uninstalls Product2 our .dll will continue to run > correctly. > > Does anyone have any further insight? > > Thanks, > Michael > > -- > Get 100% visibility into Java/.NET code with AppDynamics Lite! > It's a free troubleshooting tool designed for production. > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Adding a new dependent file to shared component without breaking component rules
Hi All, I was wondering if the state of play has changed at all since http://stackoverflow.com/questions/703359/wix-add-new-file-to-shared-component was discussed? Basically, I have Product1 (already released) and Product2 (in development) which both share the same component A.dll. A.dll is installed to %COMMONFILES%/MyProducts/. Product1 installs A.dll version 1.0.0, which is dependent upon D1.dll. Product2 installs A.dll version 1.1.0, which is dependent upon D1.dll and D2.dll. Due to the way that A.dll is used (it's a COM component registered in a thirdparty application, and we can only register one .dll) there isn't the option of creating newA.dll and putting that into Product2. (At least not without breaking Product1.) I think my only option is to add D2.dll in A.dll's component, breaking the component rules, and live with the fact that D2.dll will remain on the user's computer if they uninstall Product2 then uninstall Product1. At least then, if someone uninstalls Product2 our .dll will continue to run correctly. Does anyone have any further insight? Thanks, Michael -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
