How should I be upgrading one of multiple installed instances of an application?

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

How should I be upgrading one of multiple installed instances of an application?

Daniel Pratt
I've authored an installation package (with WIX) that uses instance
transforms to allow multiple installations of the package. Although setting
up the initial package was pretty easy, I found out too late that there
seems to be very little guidance on how to *upgrade* existing instances when
a new version comes along.

Previous to dealing with multiple instances, I would've configured the
installation package to perform a 'major upgrade' and not worried about it
further. Alas, it seems that major upgrades do not play nice with multiple
instances. Because all instances share the same upgrade code (so WIX seems
to enforce), installing a new version of the package results in *all* of the
installed instances get uninstalled (rather than just the one I'm trying to
upgrade).

What scant advice I could find on the matter led me to doing the following:
For new instances, I use a command line like this:

msiexec.exe /i "Setup.msi" TRANSFORMS=:INSTANCE.10 MSINEWINSTANCE=1 *...*

 When upgrading an instance to a new version, I use a command line like
this:

msiexec.exe /i "Setup.msi" /n {58cabe0e-f0f7-494c-a9e9-2fe101419b10}
REINSTALL=ALL REINSTALLMODE=vamus ...

The above seems to work perfectly *most of the time*. Occasionally, however,
certain files do not get updated as expected.

I suspect the cause might be that I am breaking some upgrade rules when
updating the installation package (that I wouldn't have had to worry about
when doing a major upgrade). One possible broken rule might be how I'm
managing the product code. As I have done with other installation packages,
I set Product Id = "*" so the base product code changes for every new
version. Of course, each instance transform specifies it's own product code,
which is static (if it's possible to make it dynamic, the WIX docs don't say
as much). Should I be manually changing the product code of each instance
every time? Or should the base product code be static also? Or ought it not
matter?

In summary, my question is how should I author the installation package and
how should I run it in order to upgrade only a single installation instance
(when there are multiple installed instances)?
------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users
Reply | Threaded
Open this post in threaded view
|

Re: How should I be upgrading one of multiple installed instances of an application?

robmen
I think there is a feature request open to allow WiX to updated the
UpgradeCode for each instance transform. It just hasn't been implemented.
Same could be done for the ProductCode but I'd have to investigate to see if
there are reasons why "*" isn't allowed right now.

InstanceTransforms always require me to go back and re-read the
documentation.

On Fri, Sep 2, 2011 at 11:18 AM, Daniel Pratt <[hidden email]>wrote:

> I've authored an installation package (with WIX) that uses instance
> transforms to allow multiple installations of the package. Although setting
> up the initial package was pretty easy, I found out too late that there
> seems to be very little guidance on how to *upgrade* existing instances
> when
> a new version comes along.
>
> Previous to dealing with multiple instances, I would've configured the
> installation package to perform a 'major upgrade' and not worried about it
> further. Alas, it seems that major upgrades do not play nice with multiple
> instances. Because all instances share the same upgrade code (so WIX seems
> to enforce), installing a new version of the package results in *all* of
> the
> installed instances get uninstalled (rather than just the one I'm trying to
> upgrade).
>
> What scant advice I could find on the matter led me to doing the following:
> For new instances, I use a command line like this:
>
> msiexec.exe /i "Setup.msi" TRANSFORMS=:INSTANCE.10 MSINEWINSTANCE=1 *...*
>
>  When upgrading an instance to a new version, I use a command line like
> this:
>
> msiexec.exe /i "Setup.msi" /n {58cabe0e-f0f7-494c-a9e9-2fe101419b10}
> REINSTALL=ALL REINSTALLMODE=vamus ...
>
> The above seems to work perfectly *most of the time*. Occasionally,
> however,
> certain files do not get updated as expected.
>
> I suspect the cause might be that I am breaking some upgrade rules when
> updating the installation package (that I wouldn't have had to worry about
> when doing a major upgrade). One possible broken rule might be how I'm
> managing the product code. As I have done with other installation packages,
> I set Product Id = "*" so the base product code changes for every new
> version. Of course, each instance transform specifies it's own product
> code,
> which is static (if it's possible to make it dynamic, the WIX docs don't
> say
> as much). Should I be manually changing the product code of each instance
> every time? Or should the base product code be static also? Or ought it not
> matter?
>
> In summary, my question is how should I author the installation package and
> how should I run it in order to upgrade only a single installation instance
> (when there are multiple installed instances)?
>
> ------------------------------------------------------------------------------
> Special Offer -- Download ArcSight Logger for FREE!
> Finally, a world-class log management solution at an even better
> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> download Logger. Secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsisghtdev2dev
> _______________________________________________
> WiX-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>


--
virtually, Rob Mensching - http://RobMensching.com LLC
------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users
Reply | Threaded
Open this post in threaded view
|

Re: How should I be upgrading one of multiple installed instances of an application?

Christopher Painter
In reply to this post by Daniel Pratt
I've done a lot of multiple instance work ( even within the last couple of
months ).   The big reason why I could see why UpgradeCode can't be * is
because it would break major upgrades.   The UpgradeCode property is far
stickier then ProductCode and PackageCode.

I've written some code that allows for servicing multiple instance minor
upgrade packages.  Basically when you run the application it checks the
OriginalDatabase to see if it's changed and if it  has it invokes msiexec
with all the right arguments to make the magic happen.

----------------------------------------

From: "Rob Mensching" <[hidden email]>

Sent: Friday, September 02, 2011 1:48 PM

To: "General discussion for Windows Installer XML toolset."
<[hidden email]>

Subject: Re: [WiX-users] How should I be upgrading one of multiple
installed instances of an application?


I think there is a feature request open to allow WiX to updated the

UpgradeCode for each instance transform. It just hasn't been implemented.

Same could be done for the ProductCode but I'd have to investigate to see
if

there are reasons why "*" isn't allowed right now.


InstanceTransforms always require me to go back and re-read the

documentation.


On Fri, Sep 2, 2011 at 11:18 AM, Daniel Pratt
<[hidden email]>wrote:


> I've authored an installation package (with WIX) that uses instance

> transforms to allow multiple installations of the package. Although
setting

> up the initial package was pretty easy, I found out too late that there

> seems to be very little guidance on how to *upgrade* existing instances

> when

> a new version comes along.

>

> Previous to dealing with multiple instances, I would've configured the

> installation package to perform a 'major upgrade' and not worried about
it

> further. Alas, it seems that major upgrades do not play nice with
multiple

> instances. Because all instances share the same upgrade code (so WIX
seems

> to enforce), installing a new version of the package results in *all* of

> the

> installed instances get uninstalled (rather than just the one I'm trying
to

> upgrade).

>

> What scant advice I could find on the matter led me to doing the
following:

> For new instances, I use a command line like this:

>

> msiexec.exe /i "Setup.msi" TRANSFORMS=:INSTANCE.10 MSINEWINSTANCE=1
*...*

>

> When upgrading an instance to a new version, I use a command line like

> this:

>

> msiexec.exe /i "Setup.msi" /n {58cabe0e-f0f7-494c-a9e9-2fe101419b10}

> REINSTALL=ALL REINSTALLMODE=vamus ...

>

> The above seems to work perfectly *most of the time*. Occasionally,

> however,

> certain files do not get updated as expected.

>

> I suspect the cause might be that I am breaking some upgrade rules when

> updating the installation package (that I wouldn't have had to worry
about

> when doing a major upgrade). One possible broken rule might be how I'm

> managing the product code. As I have done with other installation
packages,

> I set Product Id = "*" so the base product code changes for every new

> version. Of course, each instance transform specifies it's own product

> code,

> which is static (if it's possible to make it dynamic, the WIX docs don't

> say

> as much). Should I be manually changing the product code of each
instance

> every time? Or should the base product code be static also? Or ought it
not

> matter?

>

> In summary, my question is how should I author the installation package
and

> how should I run it in order to upgrade only a single installation
instance

> (when there are multiple installed instances)?

>

>
----------------------------------------------------------------------------
--

> Special Offer -- Download ArcSight Logger for FREE!

> Finally, a world-class log management solution at an even better

> price-free! And you'll get a free "Love Thy Logs" t-shirt when you

> download Logger. Secure your free ArcSight Logger TODAY!

> http://p.sf.net/sfu/arcsisghtdev2dev

> _______________________________________________

> WiX-users mailing list

> [hidden email]

> https://lists.sourceforge.net/lists/listinfo/wix-users

>

>


--

virtually, Rob Mensching - http://RobMensching.com LLC

----------------------------------------------------------------------------
--

Special Offer -- Download ArcSight Logger for FREE!

Finally, a world-class log management solution at an even better

price-free! And you'll get a free "Love Thy Logs" t-shirt when you

download Logger. Secure your free ArcSight Logger TODAY!

http://p.sf.net/sfu/arcsisghtdev2dev

_______________________________________________

WiX-users mailing list

[hidden email]

https://lists.sourceforge.net/lists/listinfo/wix-users


------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users
Reply | Threaded
Open this post in threaded view
|

Re: How should I be upgrading one of multiple installed instances of an application?

Tyler Walters
In reply to this post by Daniel Pratt
Haha, yeah this sucks bad. We ended up having to do different upgrade codes
for every instance transform.

Now that sounds simple, and if you have a simple way of doing it I would
love to hear it, but we made a dummy upgrade code, so that the Upgrade table
would be populated with something at build time. Since it is bogus it should
never find anything to upgrade. Then we made a c# custom action to
determine, based on the instance transform being used, which upgrade code to
use. The custom action then inserted the two rows that we needed (one for
upgrading and one to prevent downgrading) into the upgrade table.

On Fri, Sep 2, 2011 at 1:18 PM, Daniel Pratt <[hidden email]>wrote:

> I've authored an installation package (with WIX) that uses instance
> transforms to allow multiple installations of the package. Although setting
> up the initial package was pretty easy, I found out too late that there
> seems to be very little guidance on how to *upgrade* existing instances
> when
> a new version comes along.
>
> Previous to dealing with multiple instances, I would've configured the
> installation package to perform a 'major upgrade' and not worried about it
> further. Alas, it seems that major upgrades do not play nice with multiple
> instances. Because all instances share the same upgrade code (so WIX seems
> to enforce), installing a new version of the package results in *all* of
> the
> installed instances get uninstalled (rather than just the one I'm trying to
> upgrade).
>
> What scant advice I could find on the matter led me to doing the following:
> For new instances, I use a command line like this:
>
> msiexec.exe /i "Setup.msi" TRANSFORMS=:INSTANCE.10 MSINEWINSTANCE=1 *...*
>
>  When upgrading an instance to a new version, I use a command line like
> this:
>
> msiexec.exe /i "Setup.msi" /n {58cabe0e-f0f7-494c-a9e9-2fe101419b10}
> REINSTALL=ALL REINSTALLMODE=vamus ...
>
> The above seems to work perfectly *most of the time*. Occasionally,
> however,
> certain files do not get updated as expected.
>
> I suspect the cause might be that I am breaking some upgrade rules when
> updating the installation package (that I wouldn't have had to worry about
> when doing a major upgrade). One possible broken rule might be how I'm
> managing the product code. As I have done with other installation packages,
> I set Product Id = "*" so the base product code changes for every new
> version. Of course, each instance transform specifies it's own product
> code,
> which is static (if it's possible to make it dynamic, the WIX docs don't
> say
> as much). Should I be manually changing the product code of each instance
> every time? Or should the base product code be static also? Or ought it not
> matter?
>
> In summary, my question is how should I author the installation package and
> how should I run it in order to upgrade only a single installation instance
> (when there are multiple installed instances)?
>
> ------------------------------------------------------------------------------
> Special Offer -- Download ArcSight Logger for FREE!
> Finally, a world-class log management solution at an even better
> price-free! And you'll get a free "Love Thy Logs" t-shirt when you
> download Logger. Secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsisghtdev2dev
> _______________________________________________
> WiX-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-users
>



--
Tyler Walters
------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users
Reply | Threaded
Open this post in threaded view
|

Re: How should I be upgrading one of multiple installed instances of an application?

Christopher Painter
In reply to this post by Daniel Pratt
I was able to use KDiff to see there were differences in the two mst files
near the top of the file.  That encourage me to open the two files using
the SummaryInfo class in DTF and the result was major differences.

I'm wondering if this is a bug in Database.GenerateTransform().   It seems
like the SummaryInfo should have been populated.  The method only has one
overrload with no mention on SummaryInfo.

----------------------------------------

From: "Christopher Painter" <[hidden email]>

Sent: Friday, September 02, 2011 1:58 PM

To: "General discussion for Windows Installer XML toolset."
<[hidden email]>, "General discussion for Windows
Installer XML toolset." <[hidden email]>

Subject: Re: [WiX-users] How should I be upgrading one of multiple
installed instances of an application?


I've done a lot of multiple instance work ( even within the last couple of


months ). The big reason why I could see why UpgradeCode can't be * is

because it would break major upgrades. The UpgradeCode property is far

stickier then ProductCode and PackageCode.


I've written some code that allows for servicing multiple instance minor

upgrade packages. Basically when you run the application it checks the

OriginalDatabase to see if it's changed and if it has it invokes msiexec

with all the right arguments to make the magic happen.


----------------------------------------


From: "Rob Mensching" <[hidden email]>


Sent: Friday, September 02, 2011 1:48 PM


To: "General discussion for Windows Installer XML toolset."

<[hidden email]>


Subject: Re: [WiX-users] How should I be upgrading one of multiple

installed instances of an application?


I think there is a feature request open to allow WiX to updated the


UpgradeCode for each instance transform. It just hasn't been implemented.


Same could be done for the ProductCode but I'd have to investigate to see

if


there are reasons why "*" isn't allowed right now.


InstanceTransforms always require me to go back and re-read the


documentation.


On Fri, Sep 2, 2011 at 11:18 AM, Daniel Pratt

<[hidden email]>wrote:


> I've authored an installation package (with WIX) that uses instance


> transforms to allow multiple installations of the package. Although

setting


> up the initial package was pretty easy, I found out too late that there


> seems to be very little guidance on how to *upgrade* existing instances


> when


> a new version comes along.


>


> Previous to dealing with multiple instances, I would've configured the


> installation package to perform a 'major upgrade' and not worried about

it


> further. Alas, it seems that major upgrades do not play nice with

multiple


> instances. Because all instances share the same upgrade code (so WIX

seems


> to enforce), installing a new version of the package results in *all* of


> the


> installed instances get uninstalled (rather than just the one I'm trying


to


> upgrade).


>


> What scant advice I could find on the matter led me to doing the

following:


> For new instances, I use a command line like this:


>


> msiexec.exe /i "Setup.msi" TRANSFORMS=:INSTANCE.10 MSINEWINSTANCE=1

*...*


>


> When upgrading an instance to a new version, I use a command line like


> this:


>


> msiexec.exe /i "Setup.msi" /n {58cabe0e-f0f7-494c-a9e9-2fe101419b10}


> REINSTALL=ALL REINSTALLMODE=vamus ...


>


> The above seems to work perfectly *most of the time*. Occasionally,


> however,


> certain files do not get updated as expected.


>


> I suspect the cause might be that I am breaking some upgrade rules when


> updating the installation package (that I wouldn't have had to worry

about


> when doing a major upgrade). One possible broken rule might be how I'm


> managing the product code. As I have done with other installation

packages,


> I set Product Id = "*" so the base product code changes for every new


> version. Of course, each instance transform specifies it's own product


> code,


> which is static (if it's possible to make it dynamic, the WIX docs don't


> say


> as much). Should I be manually changing the product code of each

instance


> every time? Or should the base product code be static also? Or ought it

not


> matter?


>


> In summary, my question is how should I author the installation package

and


> how should I run it in order to upgrade only a single installation

instance


> (when there are multiple installed instances)?


>


>

----------------------------------------------------------------------------


--


> Special Offer -- Download ArcSight Logger for FREE!


> Finally, a world-class log management solution at an even better


> price-free! And you'll get a free "Love Thy Logs" t-shirt when you


> download Logger. Secure your free ArcSight Logger TODAY!


> http://p.sf.net/sfu/arcsisghtdev2dev


> _______________________________________________


> WiX-users mailing list


> [hidden email]


> https://lists.sourceforge.net/lists/listinfo/wix-users


>


>


--


virtually, Rob Mensching - http://RobMensching.com LLC


----------------------------------------------------------------------------


--


Special Offer -- Download ArcSight Logger for FREE!


Finally, a world-class log management solution at an even better


price-free! And you'll get a free "Love Thy Logs" t-shirt when you


download Logger. Secure your free ArcSight Logger TODAY!


http://p.sf.net/sfu/arcsisghtdev2dev


_______________________________________________


WiX-users mailing list


[hidden email]


https://lists.sourceforge.net/lists/listinfo/wix-users


----------------------------------------------------------------------------
--

Special Offer -- Download ArcSight Logger for FREE!

Finally, a world-class log management solution at an even better

price-free! And you'll get a free "Love Thy Logs" t-shirt when you

download Logger. Secure your free ArcSight Logger TODAY!

http://p.sf.net/sfu/arcsisghtdev2dev

_______________________________________________

WiX-users mailing list

[hidden email]

https://lists.sourceforge.net/lists/listinfo/wix-users


------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users
Reply | Threaded
Open this post in threaded view
|

Re: How should I be upgrading one of multiple installed instances of an application?

Christopher Painter
In reply to this post by Daniel Pratt
Sorry for the rapid emails but I now have a much simpler explantion.   DTF
behaves the way it does because this is the way MSI behaves.  Go figure...
:-)

It seems that after calling MsiDatabaseGenerateTransform you also have to
call MsiCreateTransformSummaryInfo.  It's not automatic.

----------------------------------------

From: "Christopher Painter" <[hidden email]>

Sent: Friday, September 02, 2011 2:06 PM

To: "General discussion for Windows Installer XML toolset."
<[hidden email]>, "General discussion for Windows
Installer XML toolset." <[hidden email]>, "General
discussion for Windows Installer XML toolset."
<[hidden email]>

Subject: Re: [WiX-users] How should I be upgrading one of multiple
installed instances of an application?


I was able to use KDiff to see there were differences in the two mst files


near the top of the file. That encourage me to open the two files using

the SummaryInfo class in DTF and the result was major differences.


I'm wondering if this is a bug in Database.GenerateTransform(). It seems

like the SummaryInfo should have been populated. The method only has one

overrload with no mention on SummaryInfo.


----------------------------------------


From: "Christopher Painter" <[hidden email]>


Sent: Friday, September 02, 2011 1:58 PM


To: "General discussion for Windows Installer XML toolset."

<[hidden email]>, "General discussion for Windows

Installer XML toolset." <[hidden email]>


Subject: Re: [WiX-users] How should I be upgrading one of multiple

installed instances of an application?


I've done a lot of multiple instance work ( even within the last couple of



months ). The big reason why I could see why UpgradeCode can't be * is


because it would break major upgrades. The UpgradeCode property is far


stickier then ProductCode and PackageCode.


I've written some code that allows for servicing multiple instance minor


upgrade packages. Basically when you run the application it checks the


OriginalDatabase to see if it's changed and if it has it invokes msiexec


with all the right arguments to make the magic happen.


----------------------------------------


From: "Rob Mensching" <[hidden email]>


Sent: Friday, September 02, 2011 1:48 PM


To: "General discussion for Windows Installer XML toolset."


<[hidden email]>


Subject: Re: [WiX-users] How should I be upgrading one of multiple


installed instances of an application?


I think there is a feature request open to allow WiX to updated the


UpgradeCode for each instance transform. It just hasn't been implemented.


Same could be done for the ProductCode but I'd have to investigate to see


if


there are reasons why "*" isn't allowed right now.


InstanceTransforms always require me to go back and re-read the


documentation.


On Fri, Sep 2, 2011 at 11:18 AM, Daniel Pratt


<[hidden email]>wrote:


> I've authored an installation package (with WIX) that uses instance


> transforms to allow multiple installations of the package. Although


setting


> up the initial package was pretty easy, I found out too late that there


> seems to be very little guidance on how to *upgrade* existing instances


> when


> a new version comes along.


>


> Previous to dealing with multiple instances, I would've configured the


> installation package to perform a 'major upgrade' and not worried about


it


> further. Alas, it seems that major upgrades do not play nice with


multiple


> instances. Because all instances share the same upgrade code (so WIX


seems


> to enforce), installing a new version of the package results in *all* of


> the


> installed instances get uninstalled (rather than just the one I'm trying



to


> upgrade).


>


> What scant advice I could find on the matter led me to doing the


following:


> For new instances, I use a command line like this:


>


> msiexec.exe /i "Setup.msi" TRANSFORMS=:INSTANCE.10 MSINEWINSTANCE=1


*...*


>


> When upgrading an instance to a new version, I use a command line like


> this:


>


> msiexec.exe /i "Setup.msi" /n {58cabe0e-f0f7-494c-a9e9-2fe101419b10}


> REINSTALL=ALL REINSTALLMODE=vamus ...


>


> The above seems to work perfectly *most of the time*. Occasionally,


> however,


> certain files do not get updated as expected.


>


> I suspect the cause might be that I am breaking some upgrade rules when


> updating the installation package (that I wouldn't have had to worry


about


> when doing a major upgrade). One possible broken rule might be how I'm


> managing the product code. As I have done with other installation


packages,


> I set Product Id = "*" so the base product code changes for every new


> version. Of course, each instance transform specifies it's own product


> code,


> which is static (if it's possible to make it dynamic, the WIX docs don't


> say


> as much). Should I be manually changing the product code of each


instance


> every time? Or should the base product code be static also? Or ought it


not


> matter?


>


> In summary, my question is how should I author the installation package


and


> how should I run it in order to upgrade only a single installation


instance


> (when there are multiple installed instances)?


>


>


----------------------------------------------------------------------------



--


> Special Offer -- Download ArcSight Logger for FREE!


> Finally, a world-class log management solution at an even better


> price-free! And you'll get a free "Love Thy Logs" t-shirt when you


> download Logger. Secure your free ArcSight Logger TODAY!


> http://p.sf.net/sfu/arcsisghtdev2dev


> _______________________________________________


> WiX-users mailing list


> [hidden email]


> https://lists.sourceforge.net/lists/listinfo/wix-users


>


>


--


virtually, Rob Mensching - http://RobMensching.com LLC


----------------------------------------------------------------------------



--


Special Offer -- Download ArcSight Logger for FREE!


Finally, a world-class log management solution at an even better


price-free! And you'll get a free "Love Thy Logs" t-shirt when you


download Logger. Secure your free ArcSight Logger TODAY!


http://p.sf.net/sfu/arcsisghtdev2dev


_______________________________________________


WiX-users mailing list


[hidden email]


https://lists.sourceforge.net/lists/listinfo/wix-users


----------------------------------------------------------------------------


--


Special Offer -- Download ArcSight Logger for FREE!


Finally, a world-class log management solution at an even better


price-free! And you'll get a free "Love Thy Logs" t-shirt when you


download Logger. Secure your free ArcSight Logger TODAY!


http://p.sf.net/sfu/arcsisghtdev2dev


_______________________________________________


WiX-users mailing list


[hidden email]


https://lists.sourceforge.net/lists/listinfo/wix-users


----------------------------------------------------------------------------
--

Special Offer -- Download ArcSight Logger for FREE!

Finally, a world-class log management solution at an even better

price-free! And you'll get a free "Love Thy Logs" t-shirt when you

download Logger. Secure your free ArcSight Logger TODAY!

http://p.sf.net/sfu/arcsisghtdev2dev

_______________________________________________

WiX-users mailing list

[hidden email]

https://lists.sourceforge.net/lists/listinfo/wix-users


------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users
Reply | Threaded
Open this post in threaded view
|

Re: How should I be upgrading one of multiple installed instances of an application?

jnanneng
In reply to this post by Daniel Pratt
> Should I be manually changing the product code of each instance
every time? Or should the base product code be static also? Or ought it not
matter?

Follow the Windows Installer documentation guidelines as for when to change your PC:
http://msdn.microsoft.com/en-us/library/aa370579(v=VS.85).aspx .  There are some cases where changing the PC on every build might be justified; I'm not sure what your servicing strategy is...

Also, review the guidance regarding the UpgradeCode:  http://msdn.microsoft.com/en-us/library/aa372399(v=VS.85).aspx


> In summary, my question is how should I author the installation package and
how should I run it in order to upgrade only a single installation instance
(when there are multiple installed instances)?

Windows Installer's "Upgrade" table has a field called 'ActionProperty':  http://msdn.microsoft.com/en-us/library/aa372379(v=vs.85).aspx

WiX allows you to define that property name through the "UpgradeVersion" element's attribute called "Property".  WiX documentation here notes:
"When the FindRelatedProducts action detects a related product installed on the system, it appends the product code to the property specified in this field....After the FindRelatedProducts action is run, the value of this property is a list of product codes, separated by semicolons (;), detected on the system."

Armed with all of this information it should be clear why all of your existing instances are being removed.  Thus, one rather simple way of removing only the instance you care about is to author a custom action to manipulate the value of your 'ActionProperty' after 'FindRelatedProducts' has executed.  You could totally clear it out (install a new instance), or set it to the instance product code you wish to have 'upgraded'.

There are other things to consider, but this should get you headed in a more proper direction.





------------------------------------------------------------------------------
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users
Reply | Threaded
Open this post in threaded view
|

Re: How should I be upgrading one of multiple installed instances of an application?

Daniel Pratt
On Tue, Sep 6, 2011 at 1:07 PM, John Nannenga
<[hidden email]>wrote:

> > Should I be manually changing the product code of each instance
> every time? Or should the base product code be static also? Or ought it not
> matter?
>
> Follow the Windows Installer documentation guidelines as for when to change
> your PC:
> http://msdn.microsoft.com/en-us/library/aa370579(v=VS.85).aspx .  There
> are some cases where changing the PC on every build might be justified; I'm
> not sure what your servicing strategy is...
>
> Also, review the guidance regarding the UpgradeCode:
> http://msdn.microsoft.com/en-us/library/aa372399(v=VS.85).aspx
>
>
> > In summary, my question is how should I author the installation package
> and
> how should I run it in order to upgrade only a single installation instance
> (when there are multiple installed instances)?
>
> Windows Installer's "Upgrade" table has a field called 'ActionProperty':
> http://msdn.microsoft.com/en-us/library/aa372379(v=vs.85).aspx
>
> WiX allows you to define that property name through the "UpgradeVersion"
> element's attribute called "Property".  WiX documentation here notes:
> "When the FindRelatedProducts action detects a related product installed on
> the system, it appends the product code to the property specified in this
> field....After the FindRelatedProducts action is run, the value of this
> property is a list of product codes, separated by semicolons (;), detected
> on the system."
>
> Armed with all of this information it should be clear why all of your
> existing instances are being removed.  Thus, one rather simple way of
> removing only the instance you care about is to author a custom action to
> manipulate the value of your 'ActionProperty' after 'FindRelatedProducts'
> has executed.  You could totally clear it out (install a new instance), or
> set it to the instance product code you wish to have 'upgraded'.
>
> There are other things to consider, but this should get you headed in a
> more proper direction.


Thanks for the advice, John. Actually, I had attempted to set it up this way
in the beginning, but ran into some weird issues, which caused me to go in
another direction. Thinking back on it, I think I may know why my prior
efforts failed. I'll definitely have another go at it.
------------------------------------------------------------------------------
Why Cloud-Based Security and Archiving Make Sense
Osterman Research conducted this study that outlines how and why cloud
computing security and archiving is rapidly being adopted across the IT
space for its ease of implementation, lower cost, and increased
reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users