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 that product, what if it has a critical security issue/flaw? You could release product2
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 os...@live.com 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
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 + 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=48897031iu=/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=48897031iu=/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=48897031iu=/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=48897031iu=/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
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 os...@live.com 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=48897031iu=/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=48897031iu=/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=48897031iu=/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
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 os...@live.com 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-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 troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/os
tg.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=48897031iu=/4140/ostg.c
lktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
Re: [WiX-users] Adding a new dependent file to shared component without breaking component rules
I stand corrected.
Rob Mensching r...@robmensching.com 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 os...@live.com 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=48897031iu=/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=48897031iu=/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=48897031iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https
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 os...@live.com 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-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
--
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=48897031iu=/4140/os
tg.c lktrk ___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Get 100
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 os...@live.com 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-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
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=48897031iu=/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=48897031iu=/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
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=48897031iu=/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=48897031iu=/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=48897031iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
