Re: [WiX-users] Upgrade and new install

[Jiang, Chunyan (GE Healthcare)]

Hi Blair,

I googled how to create custom action dll. And the link error has been resolved.

Now the question is how to complete the function as you suggested.


Regards,

Chunyan

-Ursprüngliche Nachricht-
Von: Jiang, Chunyan (GE Healthcare) 
Gesendet: Donnerstag, 29. Oktober 2009 14:50
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] Upgrade and new install

Hi Blair,

Thanks a lot for your help.

I will try to use the path search custom action as you said. I am not clear how 
to create a custom action native dll. I just create an empty project in Visual 
Studio 2005. Add your code to .cpp file:
#include 
#include 
#include 
#pragma comment(linker, 
"/EXPORT:schedulestartmyservice=schedulestartmyserv...@4")
...
Your code
...

When I compile it, there is error:

LINK : fatal error LNK1561: entry point must be defined


How can I resolve this link error? And I also have some other questions about 
the function: 
retrieve the "ARPINSTALLLOCATION" from the session retrieve the "PREVIOUSFOUND" 
property from the session

I think I have learned a lot from you. I am so lacking of knowledge of Wix.

Regards,

Chunyan

-Ursprüngliche Nachricht-
Von: Blair [mailto:os...@live.com]
Gesendet: Donnerstag, 29. Oktober 2009 13:39
An: 'General discussion for Windows Installer XML toolset.'
Betreff: Re: [WiX-users] Upgrade and new install

Are these services as in Windows Services, controlled by the Service Control 
Manager? They have APIs that let you discover the run state of controlled 
services, as well as the fact that you can ignore the failure to start when the 
result is that the service is already running.

If you must continue down the path you are on, do the following:
In one of your .wxs files, add this line (unless you set ARPINSTALLLOCATION
already):



Then, for an immediate custom action:




 


And in your MyCADll custom action native DLL,

extern "C" UINT __stdcall ScheduleStartMyService(MSIHANDLE session) { ...
//retrieve the "ARPINSTALLLOCATION" from the session, save it in a string 
called MyLocation
BOOL needToStart = TRUE; 
//retrieve the "PREVIOUSFOUND" property from the session, split at each 
';', and loop over each value
// if there was no PREVIOUSFOUND value, the loop would be skipped (it isn't 
an error).
// inside loop each code from the PREVIOUSFOUND property is in variable 
PreviousProduct:
WCHAR buffer[MAX_PATH+1];
DWORD buffLength=sizeof(buffer)/sizeof(WCHAR);
value = ::MsiGetProductInfo(PreviousProduct,
INSTALLPROPERTY_INSTALLLOCATION, buffer, &buffLength);
// error checking
// compare buffer to MyLocation, if they are identical, set needToStart 
= FALSE
// exit loop early if desired
...
// after loop, if no error so far:
if (needToStart)
{
value = ::MsiDoAction("StartMyService");
}
...
}

You could also do the same thing in managed code (use DTF) but you would have 
to translate the API usages and logic above into the objects DTF provides to do 
the same things.

-Original Message-
From: Jiang, Chunyan (GE Healthcare) [mailto:chunyan.ji...@ge.com]
Sent: Thursday, October 29, 2009 3:21 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Upgrade and new install

Hi Blair,

Here I would like to explain you the reason why I use this Custom Action.
This CA is to call an exe to start some services. For the old path, the 
services are already started. If start them again, it will cause problem.
For the new path, the exe must start the services, otherwise the software does 
not work.

The services must be started from install procedure. The user shall not start 
them manually. That is why I write this CA to call the exe.

Your suggestion is very good. I would like to try it. However I have no idea 
how to query the installation path, nor to compare them in CA. Could you please 
do me a favor and give me an example how to perform it?

Best regards,

Chunyan

-Ursprüngliche Nachricht-
Von: Blair [mailto:os...@live.com]
Gesendet: Mittwoch, 28. Oktober 2009 16:55
An: 'General discussion for Windows Installer XML toolset.'
Betreff: Re: [WiX-users] Upgrade and new install

At this point you have an arbitrary number of installs in an arbitrary set of 
installation paths. A simple "registry search" can't return all of the paths 
you have previously installed into.

Your PREVIOUSFOUND property contains a semi-colon-delimited list of ProductCode 
GUIDs that are the products already installed. You could use a custom action 
that queries the installation path of each of those products and compares them 
to the path you are installing into, and based on that determination 
allows/blocks your current custom action.

However, as I think about this, I have another question: What doe

Re: [WiX-users] Upgrade and new install

[Jiang, Chunyan (GE Healthcare)]

Hi Blair,

Thanks a lot for your help.

I will try to use the path search custom action as you said. I am not clear how 
to create a custom action native dll. I just create an empty project in Visual 
Studio 2005. Add your code to .cpp file:
#include 
#include 
#include 
#pragma comment(linker, 
"/EXPORT:schedulestartmyservice=schedulestartmyserv...@4")
...
Your code
...

When I compile it, there is error:

LINK : fatal error LNK1561: entry point must be defined


How can I resolve this link error? And I also have some other questions about 
the function: 
retrieve the "ARPINSTALLLOCATION" from the session
retrieve the "PREVIOUSFOUND" property from the session

I think I have learned a lot from you. I am so lacking of knowledge of Wix.

Regards,

Chunyan

-Ursprüngliche Nachricht-
Von: Blair [mailto:os...@live.com] 
Gesendet: Donnerstag, 29. Oktober 2009 13:39
An: 'General discussion for Windows Installer XML toolset.'
Betreff: Re: [WiX-users] Upgrade and new install

Are these services as in Windows Services, controlled by the Service Control 
Manager? They have APIs that let you discover the run state of controlled 
services, as well as the fact that you can ignore the failure to start when the 
result is that the service is already running.

If you must continue down the path you are on, do the following:
In one of your .wxs files, add this line (unless you set ARPINSTALLLOCATION
already):



Then, for an immediate custom action:




 


And in your MyCADll custom action native DLL,

extern "C" UINT __stdcall ScheduleStartMyService(MSIHANDLE session) { ...
//retrieve the "ARPINSTALLLOCATION" from the session, save it in a string 
called MyLocation
BOOL needToStart = TRUE; 
//retrieve the "PREVIOUSFOUND" property from the session, split at each 
';', and loop over each value
// if there was no PREVIOUSFOUND value, the loop would be skipped (it isn't 
an error).
// inside loop each code from the PREVIOUSFOUND property is in variable 
PreviousProduct:
WCHAR buffer[MAX_PATH+1];
DWORD buffLength=sizeof(buffer)/sizeof(WCHAR);
value = ::MsiGetProductInfo(PreviousProduct,
INSTALLPROPERTY_INSTALLLOCATION, buffer, &buffLength);
// error checking
// compare buffer to MyLocation, if they are identical, set needToStart 
= FALSE
// exit loop early if desired
...
// after loop, if no error so far:
if (needToStart)
{
value = ::MsiDoAction("StartMyService");
}
...
}

You could also do the same thing in managed code (use DTF) but you would have 
to translate the API usages and logic above into the objects DTF provides to do 
the same things.

-Original Message-
From: Jiang, Chunyan (GE Healthcare) [mailto:chunyan.ji...@ge.com]
Sent: Thursday, October 29, 2009 3:21 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Upgrade and new install

Hi Blair,

Here I would like to explain you the reason why I use this Custom Action.
This CA is to call an exe to start some services. For the old path, the 
services are already started. If start them again, it will cause problem.
For the new path, the exe must start the services, otherwise the software does 
not work.

The services must be started from install procedure. The user shall not start 
them manually. That is why I write this CA to call the exe.

Your suggestion is very good. I would like to try it. However I have no idea 
how to query the installation path, nor to compare them in CA. Could you please 
do me a favor and give me an example how to perform it?

Best regards,

Chunyan

-Ursprüngliche Nachricht-
Von: Blair [mailto:os...@live.com]
Gesendet: Mittwoch, 28. Oktober 2009 16:55
An: 'General discussion for Windows Installer XML toolset.'
Betreff: Re: [WiX-users] Upgrade and new install

At this point you have an arbitrary number of installs in an arbitrary set of 
installation paths. A simple "registry search" can't return all of the paths 
you have previously installed into.

Your PREVIOUSFOUND property contains a semi-colon-delimited list of ProductCode 
GUIDs that are the products already installed. You could use a custom action 
that queries the installation path of each of those products and compares them 
to the path you are installing into, and based on that determination 
allows/blocks your current custom action.

However, as I think about this, I have another question: What does your custom 
action do that requires running for all new paths and not for paths already 
installed into? That smells like "configuration" to me (aka registration of 
some sort). If that turns into registry or xml file writes or something like 
that, wouldn't it make more sense to make those explicit in the MSI file itself 
and not hide it behind self-registration? In other words, get rid

Re: [WiX-users] Upgrade and new install

[Blair]

Are these services as in Windows Services, controlled by the Service Control
Manager? They have APIs that let you discover the run state of controlled
services, as well as the fact that you can ignore the failure to start when
the result is that the service is already running.

If you must continue down the path you are on, do the following:
In one of your .wxs files, add this line (unless you set ARPINSTALLLOCATION
already):



Then, for an immediate custom action:







And in your MyCADll custom action native DLL,

extern "C" UINT __stdcall ScheduleStartMyService(MSIHANDLE session)
{
...
//retrieve the "ARPINSTALLLOCATION" from the session, save it in a
string called MyLocation
BOOL needToStart = TRUE; 
//retrieve the "PREVIOUSFOUND" property from the session, split at each
';', and loop over each value
// if there was no PREVIOUSFOUND value, the loop would be skipped (it
isn't an error).
// inside loop each code from the PREVIOUSFOUND property is in
variable PreviousProduct:
WCHAR buffer[MAX_PATH+1];
DWORD buffLength=sizeof(buffer)/sizeof(WCHAR);
value = ::MsiGetProductInfo(PreviousProduct,
INSTALLPROPERTY_INSTALLLOCATION, buffer, &buffLength);
// error checking
// compare buffer to MyLocation, if they are identical, set
needToStart = FALSE
// exit loop early if desired
...
// after loop, if no error so far:
if (needToStart)
{
value = ::MsiDoAction("StartMyService");
}
...
}

You could also do the same thing in managed code (use DTF) but you would
have to translate the API usages and logic above into the objects DTF
provides to do the same things.

-Original Message-
From: Jiang, Chunyan (GE Healthcare) [mailto:chunyan.ji...@ge.com] 
Sent: Thursday, October 29, 2009 3:21 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Upgrade and new install

Hi Blair,

Here I would like to explain you the reason why I use this Custom Action.
This CA is to call an exe to start some services. For the old path, the
services are already started. If start them again, it will cause problem.
For the new path, the exe must start the services, otherwise the software
does not work.

The services must be started from install procedure. The user shall not
start them manually. That is why I write this CA to call the exe.

Your suggestion is very good. I would like to try it. However I have no idea
how to query the installation path, nor to compare them in CA. Could you
please do me a favor and give me an example how to perform it?

Best regards,

Chunyan

-Ursprüngliche Nachricht-
Von: Blair [mailto:os...@live.com] 
Gesendet: Mittwoch, 28. Oktober 2009 16:55
An: 'General discussion for Windows Installer XML toolset.'
Betreff: Re: [WiX-users] Upgrade and new install

At this point you have an arbitrary number of installs in an arbitrary set
of installation paths. A simple "registry search" can't return all of the
paths you have previously installed into.

Your PREVIOUSFOUND property contains a semi-colon-delimited list of
ProductCode GUIDs that are the products already installed. You could use a
custom action that queries the installation path of each of those products
and compares them to the path you are installing into, and based on that
determination allows/blocks your current custom action.

However, as I think about this, I have another question: What does your
custom action do that requires running for all new paths and not for paths
already installed into? That smells like "configuration" to me (aka
registration of some sort). If that turns into registry or xml file writes
or something like that, wouldn't it make more sense to make those explicit
in the MSI file itself and not hide it behind self-registration? In other
words, get rid of that custom action entirely by making its side effects
part of your installation.

-Original Message-
From: Jiang, Chunyan (GE Healthcare) [mailto:chunyan.ji...@ge.com]
Sent: Wednesday, October 28, 2009 8:27 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Upgrade and new install

Hi Blair,

Thanks for your suggestion. I did the change as you said, set OnlyDetect to
"yes". Now the new install will not cause the removing files from previous
install in other path. It is great!

However, I have on Custon Action. I hope this CA will be run for new install
to new path, but not run for upgrade the previous install in old path.

I tried to set it as

NOT Installed AND NOT
PREVIOUSFOUND MyCA will not run either in upgrade or in install to
the other path. It only runs for totally new install, which is good.

However, how can I make this CA run only for install to other path, but not
in upgrade, under the OnlyDetect = "yes"?


Best regards,

Chunyan



-Ursprüngliche Nachricht

Re: [WiX-users] Upgrade and new install

[Jiang, Chunyan (GE Healthcare)]

Hi Blair,

Here I would like to explain you the reason why I use this Custom Action. This 
CA is to call an exe to start some services. For the old path, the services are 
already started. If start them again, it will cause problem. For the new path, 
the exe must start the services, otherwise the software does not work.

The services must be started from install procedure. The user shall not start 
them manually. That is why I write this CA to call the exe.

Your suggestion is very good. I would like to try it. However I have no idea 
how to query the installation path, nor to compare them in CA. Could you please 
do me a favor and give me an example how to perform it?

Best regards,

Chunyan

-Ursprüngliche Nachricht-
Von: Blair [mailto:os...@live.com] 
Gesendet: Mittwoch, 28. Oktober 2009 16:55
An: 'General discussion for Windows Installer XML toolset.'
Betreff: Re: [WiX-users] Upgrade and new install

At this point you have an arbitrary number of installs in an arbitrary set of 
installation paths. A simple "registry search" can't return all of the paths 
you have previously installed into.

Your PREVIOUSFOUND property contains a semi-colon-delimited list of ProductCode 
GUIDs that are the products already installed. You could use a custom action 
that queries the installation path of each of those products and compares them 
to the path you are installing into, and based on that determination 
allows/blocks your current custom action.

However, as I think about this, I have another question: What does your custom 
action do that requires running for all new paths and not for paths already 
installed into? That smells like "configuration" to me (aka registration of 
some sort). If that turns into registry or xml file writes or something like 
that, wouldn't it make more sense to make those explicit in the MSI file itself 
and not hide it behind self-registration? In other words, get rid of that 
custom action entirely by making its side effects part of your installation.

-Original Message-
From: Jiang, Chunyan (GE Healthcare) [mailto:chunyan.ji...@ge.com]
Sent: Wednesday, October 28, 2009 8:27 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Upgrade and new install

Hi Blair,

Thanks for your suggestion. I did the change as you said, set OnlyDetect to 
"yes". Now the new install will not cause the removing files from previous 
install in other path. It is great!

However, I have on Custon Action. I hope this CA will be run for new install to 
new path, but not run for upgrade the previous install in old path.

I tried to set it as

NOT Installed AND NOT 
PREVIOUSFOUND MyCA will not run either in upgrade or in install to the 
other path. It only runs for totally new install, which is good.

However, how can I make this CA run only for install to other path, but not in 
upgrade, under the OnlyDetect = "yes"?


Best regards,

Chunyan



-Ursprüngliche Nachricht-
Von: Blair [mailto:os...@live.com]
Gesendet: Dienstag, 27. Oktober 2009 18:24
An: 'General discussion for Windows Installer XML toolset.'
Betreff: Re: [WiX-users] Upgrade and new install

The first question was whether the user can switch between case 1 and case 2.

What it appears you want is to have every "version" be a major upgrade (don't 
keep old ProductCodes from one version to the next) EXCEPT when you send out a 
security fix (so you need to keep a history of all the ProductCodes you ever 
ship so that you can make those security fixes later on. This will include the 
ProductCodes in your instance transforms). This also means you will change your 
instance transforms each version as well.

In your UpgradeVersion elements, you want to always set the OnlyDetect 
attribute to "yes". You will never remove an older build/version by installing 
a newer one (although you may overwrite one, unless you protect against that).

I would suggest that your default PathX include your version number in it 
somewhere, to reduce the chance of overwriting old versions.

-Original Message-
From: Jiang, Chunyan (GE Healthcare) [mailto:chunyan.ji...@ge.com]
Sent: Tuesday, October 27, 2009 5:05 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Upgrade and new install

Hi Blair,

Thanks for your reply.

Sorry, I made a mistake. Case 2 is to install version 1 to both PathA and 
PathB. So case 2 is multi instance issue. But I care more about case 1 
currently. To clarify the issue, I answer your questions between lines:

1- Can the user switch cases down the road??

Not understand very well.

2- Does Version 3 overwrite Version 1 in both cases? Or is there some future 
PathC/PathD thing going on?

The Version 3 should be able to upgrade version 1 in PathA or version 2 in 
PathB, even do a new install in PathC.

3- When Version 2 is installed, is version 1 ever remov

Re: [WiX-users] Upgrade and new install

[Blair]

At this point you have an arbitrary number of installs in an arbitrary set
of installation paths. A simple "registry search" can't return all of the
paths you have previously installed into.

Your PREVIOUSFOUND property contains a semi-colon-delimited list of
ProductCode GUIDs that are the products already installed. You could use a
custom action that queries the installation path of each of those products
and compares them to the path you are installing into, and based on that
determination allows/blocks your current custom action.

However, as I think about this, I have another question: What does your
custom action do that requires running for all new paths and not for paths
already installed into? That smells like "configuration" to me (aka
registration of some sort). If that turns into registry or xml file writes
or something like that, wouldn't it make more sense to make those explicit
in the MSI file itself and not hide it behind self-registration? In other
words, get rid of that custom action entirely by making its side effects
part of your installation.

-Original Message-
From: Jiang, Chunyan (GE Healthcare) [mailto:chunyan.ji...@ge.com] 
Sent: Wednesday, October 28, 2009 8:27 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Upgrade and new install

Hi Blair,

Thanks for your suggestion. I did the change as you said, set OnlyDetect to
"yes". Now the new install will not cause the removing files from previous
install in other path. It is great!

However, I have on Custon Action. I hope this CA will be run for new install
to new path, but not run for upgrade the previous install in old path.

I tried to set it as

NOT Installed AND NOT
PREVIOUSFOUND
MyCA will not run either in upgrade or in install to the other path. It only
runs for totally new install, which is good.

However, how can I make this CA run only for install to other path, but not
in upgrade, under the OnlyDetect = "yes"?


Best regards,

Chunyan



-Ursprüngliche Nachricht-
Von: Blair [mailto:os...@live.com] 
Gesendet: Dienstag, 27. Oktober 2009 18:24
An: 'General discussion for Windows Installer XML toolset.'
Betreff: Re: [WiX-users] Upgrade and new install

The first question was whether the user can switch between case 1 and case
2.

What it appears you want is to have every "version" be a major upgrade
(don't keep old ProductCodes from one version to the next) EXCEPT when you
send out a security fix (so you need to keep a history of all the
ProductCodes you ever ship so that you can make those security fixes later
on. This will include the ProductCodes in your instance transforms). This
also means you will change your instance transforms each version as well.

In your UpgradeVersion elements, you want to always set the OnlyDetect
attribute to "yes". You will never remove an older build/version by
installing a newer one (although you may overwrite one, unless you protect
against that).

I would suggest that your default PathX include your version number in it
somewhere, to reduce the chance of overwriting old versions.

-Original Message-
From: Jiang, Chunyan (GE Healthcare) [mailto:chunyan.ji...@ge.com]
Sent: Tuesday, October 27, 2009 5:05 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Upgrade and new install

Hi Blair,

Thanks for your reply.

Sorry, I made a mistake. Case 2 is to install version 1 to both PathA and
PathB. So case 2 is multi instance issue. But I care more about case 1
currently. To clarify the issue, I answer your questions between lines:

1- Can the user switch cases down the road??

Not understand very well.

2- Does Version 3 overwrite Version 1 in both cases? Or is there some future
PathC/PathD thing going on?

The Version 3 should be able to upgrade version 1 in PathA or version 2 in
PathB, even do a new install in PathC.

3- When Version 2 is installed, is version 1 ever removed by any means?

When version 2 is installed in PathB, it should be no related to version 1
in PathA. So Version 1 can be removed or upgraded. 

4- If a security or other flaw is discovered in Version 1, how do you intend
to address it?

I would like to adress the installation by product code, upgrade code, and
the path information. Althought version 1 installed in PathA, and Version 2
installed in PathB, they are independent actually.

I don't know if it is possible to realize this.


Best regards,

Chunyan

-Ursprüngliche Nachricht-
Von: Blair [mailto:os...@live.com]
Gesendet: Dienstag, 27. Oktober 2009 12:48
An: 'General discussion for Windows Installer XML toolset.'
Betreff: Re: [WiX-users] Upgrade and new install

I don't see the difference between Case 1 and Case 2, except that the
installation directories are switched.

Four more questions (unless there is some error in what I understood so far)
1- Can the user 

Re: [WiX-users] Upgrade and new install

[Jiang, Chunyan (GE Healthcare)]

Hi Blair,

Thanks for your suggestion. I did the change as you said, set OnlyDetect to 
"yes". Now the new install will not cause the removing files from previous 
install in other path. It is great!

However, I have on Custon Action. I hope this CA will be run for new install to 
new path, but not run for upgrade the previous install in old path.

I tried to set it as

NOT Installed AND NOT 
PREVIOUSFOUND
MyCA will not run either in upgrade or in install to the other path. It only 
runs for totally new install, which is good.

However, how can I make this CA run only for install to other path, but not in 
upgrade, under the OnlyDetect = "yes"?


Best regards,

Chunyan



-Ursprüngliche Nachricht-
Von: Blair [mailto:os...@live.com] 
Gesendet: Dienstag, 27. Oktober 2009 18:24
An: 'General discussion for Windows Installer XML toolset.'
Betreff: Re: [WiX-users] Upgrade and new install

The first question was whether the user can switch between case 1 and case 2.

What it appears you want is to have every "version" be a major upgrade (don't 
keep old ProductCodes from one version to the next) EXCEPT when you send out a 
security fix (so you need to keep a history of all the ProductCodes you ever 
ship so that you can make those security fixes later on. This will include the 
ProductCodes in your instance transforms). This also means you will change your 
instance transforms each version as well.

In your UpgradeVersion elements, you want to always set the OnlyDetect 
attribute to "yes". You will never remove an older build/version by installing 
a newer one (although you may overwrite one, unless you protect against that).

I would suggest that your default PathX include your version number in it 
somewhere, to reduce the chance of overwriting old versions.

-Original Message-
From: Jiang, Chunyan (GE Healthcare) [mailto:chunyan.ji...@ge.com]
Sent: Tuesday, October 27, 2009 5:05 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Upgrade and new install

Hi Blair,

Thanks for your reply.

Sorry, I made a mistake. Case 2 is to install version 1 to both PathA and 
PathB. So case 2 is multi instance issue. But I care more about case 1 
currently. To clarify the issue, I answer your questions between lines:

1- Can the user switch cases down the road??

Not understand very well.

2- Does Version 3 overwrite Version 1 in both cases? Or is there some future 
PathC/PathD thing going on?

The Version 3 should be able to upgrade version 1 in PathA or version 2 in 
PathB, even do a new install in PathC.

3- When Version 2 is installed, is version 1 ever removed by any means?

When version 2 is installed in PathB, it should be no related to version 1 in 
PathA. So Version 1 can be removed or upgraded. 

4- If a security or other flaw is discovered in Version 1, how do you intend to 
address it?

I would like to adress the installation by product code, upgrade code, and the 
path information. Althought version 1 installed in PathA, and Version 2 
installed in PathB, they are independent actually.

I don't know if it is possible to realize this.


Best regards,

Chunyan

-Ursprüngliche Nachricht-
Von: Blair [mailto:os...@live.com]
Gesendet: Dienstag, 27. Oktober 2009 12:48
An: 'General discussion for Windows Installer XML toolset.'
Betreff: Re: [WiX-users] Upgrade and new install

I don't see the difference between Case 1 and Case 2, except that the 
installation directories are switched.

Four more questions (unless there is some error in what I understood so far)
1- Can the user switch cases down the road??
2- Does Version 3 overwrite Version 1 in both cases? Or is there some future 
PathC/PathD thing going on?
3- When Version 2 is installed, is version 1 ever removed by any means?
4- If a security or other flaw is discovered in Version 1, how do you intend to 
address it?

-Original Message-
From: Jiang, Chunyan (GE Healthcare) [mailto:chunyan.ji...@ge.com]
Sent: Tuesday, October 27, 2009 2:45 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Upgrade and new install

Hi Blair,

Probably my use-case is special. My software should be able to install 
flexiably. It can be installed as following:

Case 1:
Version 1 install to PathA, Version 2 install to PathB

Case 2:
Version 2 install to PathA, version 1 install to PathB, again.

I am stuck in developing case 1. When I have installed version 1 to PathA, then 
try to install verison 2 to PathB, the version 1 will always be detected via 
"Install Validate". And it tries to remove files from PathA during "Remove 
Files". Althought version 2 can be installed to PathB at last, version 1 is 
brocken. And some CA in version 2 PathB can not run since version 1 PathA are 
detected for upgrade. Therefore, I hope there is some registry mechanism so 
that when install version 2 to PathB, in

Re: [WiX-users] Upgrade and new install

[Blair]

If you use your Upgrade table only for package detection, you won't need to
do the directory search. By not removing version 1 (because you will set the
OnlyDetect flag) the RemoveFiles action doesn't need any conditions either
(and in fact should never have conditions).

Also, your ProductCode MUST be different between version 1 and version 2.
Make sure it is changed between your two versions.

-Original Message-
From: Jiang, Chunyan (GE Healthcare) [mailto:chunyan.ji...@ge.com] 
Sent: Tuesday, October 27, 2009 8:59 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Upgrade and new install

I set one property in my wix project:


   

  
 
And set the custom actions as:
PREVIOUSFOUND AND
INSTALLDIR

When Version 1 installed in PathA, and try to install version 2 to PathB,
from verbose log, it shows MyCA will not be called. It means property
"INSTALLDIR" works for MyCA. However, "InstallValidate" action still check
the installed files in PathA, and "RemoveFiles" action will remove files in
PathA. Those are not what I want.

How to set conditions to InstallValidate. and RemoveFiles so that they will
not work in this case?

Regards,

Chunyan

-Ursprüngliche Nachricht-
Von: Jiang, Chunyan (GE Healthcare) 
Gesendet: Dienstag, 27. Oktober 2009 13:05
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] Upgrade and new install

Hi Blair,

Thanks for your reply.

Sorry, I made a mistake. Case 2 is to install version 1 to both PathA and
PathB. So case 2 is multi instance issue. But I care more about case 1
currently. To clarify the issue, I answer your questions between lines:

1- Can the user switch cases down the road??

Not understand very well.

2- Does Version 3 overwrite Version 1 in both cases? Or is there some future
PathC/PathD thing going on?

The Version 3 should be able to upgrade version 1 in PathA or version 2 in
PathB, even do a new install in PathC.

3- When Version 2 is installed, is version 1 ever removed by any means?

When version 2 is installed in PathB, it should be no related to version 1
in PathA. So Version 1 can be removed or upgraded. 

4- If a security or other flaw is discovered in Version 1, how do you intend
to address it?

I would like to adress the installation by product code, upgrade code, and
the path information. Althought version 1 installed in PathA, and Version 2
installed in PathB, they are independent actually.

I don't know if it is possible to realize this.


Best regards,

Chunyan

-Ursprüngliche Nachricht-
Von: Blair [mailto:os...@live.com]
Gesendet: Dienstag, 27. Oktober 2009 12:48
An: 'General discussion for Windows Installer XML toolset.'
Betreff: Re: [WiX-users] Upgrade and new install

I don't see the difference between Case 1 and Case 2, except that the
installation directories are switched.

Four more questions (unless there is some error in what I understood so far)
1- Can the user switch cases down the road??
2- Does Version 3 overwrite Version 1 in both cases? Or is there some future
PathC/PathD thing going on?
3- When Version 2 is installed, is version 1 ever removed by any means?
4- If a security or other flaw is discovered in Version 1, how do you intend
to address it?

-Original Message-
From: Jiang, Chunyan (GE Healthcare) [mailto:chunyan.ji...@ge.com]
Sent: Tuesday, October 27, 2009 2:45 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Upgrade and new install

Hi Blair,

Probably my use-case is special. My software should be able to install
flexiably. It can be installed as following:

Case 1:
Version 1 install to PathA, Version 2 install to PathB

Case 2:
Version 2 install to PathA, version 1 install to PathB, again.

I am stuck in developing case 1. When I have installed version 1 to PathA,
then try to install verison 2 to PathB, the version 1 will always be
detected via "Install Validate". And it tries to remove files from PathA
during "Remove Files". Althought version 2 can be installed to PathB at
last, version 1 is brocken. And some CA in version 2 PathB can not run since
version 1 PathA are detected for upgrade. Therefore, I hope there is some
registry mechanism so that when install version 2 to PathB, instead of
PathA, then the new version will not be treated as upgrade. So that the
files are not "validated" and "removed".

For case 2, I know it is "multi instance" issue in wix installer develop. It
is my next step.

Could you please give me some help how to realize case 1?


Thanks a lot!

Chunyan

-Ursprüngliche Nachricht-
Von: Blair [mailto:os...@live.com]
Gesendet: Dienstag, 27. Oktober 2009 02:35
An: 'General discussion for Windows Installer XML toolset.'
Betreff: Re: [WiX-users] Upgrade and new install

So you need upgrades to not replace previous installation

Re: [WiX-users] Upgrade and new install

[Blair]

The first question was whether the user can switch between case 1 and case
2.

What it appears you want is to have every "version" be a major upgrade
(don't keep old ProductCodes from one version to the next) EXCEPT when you
send out a security fix (so you need to keep a history of all the
ProductCodes you ever ship so that you can make those security fixes later
on. This will include the ProductCodes in your instance transforms). This
also means you will change your instance transforms each version as well.

In your UpgradeVersion elements, you want to always set the OnlyDetect
attribute to "yes". You will never remove an older build/version by
installing a newer one (although you may overwrite one, unless you protect
against that).

I would suggest that your default PathX include your version number in it
somewhere, to reduce the chance of overwriting old versions.

-Original Message-
From: Jiang, Chunyan (GE Healthcare) [mailto:chunyan.ji...@ge.com] 
Sent: Tuesday, October 27, 2009 5:05 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Upgrade and new install

Hi Blair,

Thanks for your reply.

Sorry, I made a mistake. Case 2 is to install version 1 to both PathA and
PathB. So case 2 is multi instance issue. But I care more about case 1
currently. To clarify the issue, I answer your questions between lines:

1- Can the user switch cases down the road??

Not understand very well.

2- Does Version 3 overwrite Version 1 in both cases? Or is there some future
PathC/PathD thing going on?

The Version 3 should be able to upgrade version 1 in PathA or version 2 in
PathB, even do a new install in PathC.

3- When Version 2 is installed, is version 1 ever removed by any means?

When version 2 is installed in PathB, it should be no related to version 1
in PathA. So Version 1 can be removed or upgraded. 

4- If a security or other flaw is discovered in Version 1, how do you intend
to address it?

I would like to adress the installation by product code, upgrade code, and
the path information. Althought version 1 installed in PathA, and Version 2
installed in PathB, they are independent actually.

I don't know if it is possible to realize this.


Best regards,

Chunyan

-Ursprüngliche Nachricht-
Von: Blair [mailto:os...@live.com] 
Gesendet: Dienstag, 27. Oktober 2009 12:48
An: 'General discussion for Windows Installer XML toolset.'
Betreff: Re: [WiX-users] Upgrade and new install

I don't see the difference between Case 1 and Case 2, except that the
installation directories are switched.

Four more questions (unless there is some error in what I understood so far)
1- Can the user switch cases down the road??
2- Does Version 3 overwrite Version 1 in both cases? Or is there some future
PathC/PathD thing going on?
3- When Version 2 is installed, is version 1 ever removed by any means?
4- If a security or other flaw is discovered in Version 1, how do you intend
to address it?

-Original Message-
From: Jiang, Chunyan (GE Healthcare) [mailto:chunyan.ji...@ge.com]
Sent: Tuesday, October 27, 2009 2:45 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Upgrade and new install

Hi Blair,

Probably my use-case is special. My software should be able to install
flexiably. It can be installed as following:

Case 1:
Version 1 install to PathA, Version 2 install to PathB

Case 2:
Version 2 install to PathA, version 1 install to PathB, again.

I am stuck in developing case 1. When I have installed version 1 to PathA,
then try to install verison 2 to PathB, the version 1 will always be
detected via "Install Validate". And it tries to remove files from PathA
during "Remove Files". Althought version 2 can be installed to PathB at
last, version 1 is brocken. And some CA in version 2 PathB can not run since
version 1 PathA are detected for upgrade. Therefore, I hope there is some
registry mechanism so that when install version 2 to PathB, instead of
PathA, then the new version will not be treated as upgrade. So that the
files are not "validated" and "removed".

For case 2, I know it is "multi instance" issue in wix installer develop. It
is my next step.

Could you please give me some help how to realize case 1?


Thanks a lot!

Chunyan

-Ursprüngliche Nachricht-
Von: Blair [mailto:os...@live.com]
Gesendet: Dienstag, 27. Oktober 2009 02:35
An: 'General discussion for Windows Installer XML toolset.'
Betreff: Re: [WiX-users] Upgrade and new install

So you need upgrades to not replace previous installations? In that case
they are not upgrades.

I'm still trying to understand your use-case and your servicing strategy.
How do you intend to fix older versions? What do your users expect when they
run a newer installation package from you when they have an older version
installed?

-Original Message-
From: Jiang, Chunyan (

Re: [WiX-users] Upgrade and new install

[Jiang, Chunyan (GE Healthcare)]

I set one property in my wix project:


   

  
 
And set the custom actions as:
PREVIOUSFOUND AND 
INSTALLDIR

When Version 1 installed in PathA, and try to install version 2 to PathB, from 
verbose log, it shows MyCA will not be called. It means property "INSTALLDIR" 
works for MyCA. However, "InstallValidate" action still check the installed 
files in PathA, and "RemoveFiles" action will remove files in PathA. Those are 
not what I want.

How to set conditions to InstallValidate. and RemoveFiles so that they will not 
work in this case?

Regards,

Chunyan

-Ursprüngliche Nachricht-
Von: Jiang, Chunyan (GE Healthcare) 
Gesendet: Dienstag, 27. Oktober 2009 13:05
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] Upgrade and new install

Hi Blair,

Thanks for your reply.

Sorry, I made a mistake. Case 2 is to install version 1 to both PathA and 
PathB. So case 2 is multi instance issue. But I care more about case 1 
currently. To clarify the issue, I answer your questions between lines:

1- Can the user switch cases down the road??

Not understand very well.

2- Does Version 3 overwrite Version 1 in both cases? Or is there some future 
PathC/PathD thing going on?

The Version 3 should be able to upgrade version 1 in PathA or version 2 in 
PathB, even do a new install in PathC.

3- When Version 2 is installed, is version 1 ever removed by any means?

When version 2 is installed in PathB, it should be no related to version 1 in 
PathA. So Version 1 can be removed or upgraded. 

4- If a security or other flaw is discovered in Version 1, how do you intend to 
address it?

I would like to adress the installation by product code, upgrade code, and the 
path information. Althought version 1 installed in PathA, and Version 2 
installed in PathB, they are independent actually.

I don't know if it is possible to realize this.


Best regards,

Chunyan

-Ursprüngliche Nachricht-
Von: Blair [mailto:os...@live.com]
Gesendet: Dienstag, 27. Oktober 2009 12:48
An: 'General discussion for Windows Installer XML toolset.'
Betreff: Re: [WiX-users] Upgrade and new install

I don't see the difference between Case 1 and Case 2, except that the 
installation directories are switched.

Four more questions (unless there is some error in what I understood so far)
1- Can the user switch cases down the road??
2- Does Version 3 overwrite Version 1 in both cases? Or is there some future 
PathC/PathD thing going on?
3- When Version 2 is installed, is version 1 ever removed by any means?
4- If a security or other flaw is discovered in Version 1, how do you intend to 
address it?

-Original Message-
From: Jiang, Chunyan (GE Healthcare) [mailto:chunyan.ji...@ge.com]
Sent: Tuesday, October 27, 2009 2:45 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Upgrade and new install

Hi Blair,

Probably my use-case is special. My software should be able to install 
flexiably. It can be installed as following:

Case 1:
Version 1 install to PathA, Version 2 install to PathB

Case 2:
Version 2 install to PathA, version 1 install to PathB, again.

I am stuck in developing case 1. When I have installed version 1 to PathA, then 
try to install verison 2 to PathB, the version 1 will always be detected via 
"Install Validate". And it tries to remove files from PathA during "Remove 
Files". Althought version 2 can be installed to PathB at last, version 1 is 
brocken. And some CA in version 2 PathB can not run since version 1 PathA are 
detected for upgrade. Therefore, I hope there is some registry mechanism so 
that when install version 2 to PathB, instead of PathA, then the new version 
will not be treated as upgrade. So that the files are not "validated" and 
"removed".

For case 2, I know it is "multi instance" issue in wix installer develop. It is 
my next step.

Could you please give me some help how to realize case 1?


Thanks a lot!

Chunyan

-Ursprüngliche Nachricht-
Von: Blair [mailto:os...@live.com]
Gesendet: Dienstag, 27. Oktober 2009 02:35
An: 'General discussion for Windows Installer XML toolset.'
Betreff: Re: [WiX-users] Upgrade and new install

So you need upgrades to not replace previous installations? In that case they 
are not upgrades.

I'm still trying to understand your use-case and your servicing strategy.
How do you intend to fix older versions? What do your users expect when they 
run a newer installation package from you when they have an older version 
installed?

-Original Message-
From: Jiang, Chunyan (GE Healthcare) [mailto:chunyan.ji...@ge.com]
Sent: Friday, October 23, 2009 2:48 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Upgrade and new install

Hi Rob,

I think over my scenario and clarify it that I want my App should be installed 
with the r

Re: [WiX-users] Upgrade and new install

[Jiang, Chunyan (GE Healthcare)]

Hi Blair,

Thanks for your reply.

Sorry, I made a mistake. Case 2 is to install version 1 to both PathA and 
PathB. So case 2 is multi instance issue. But I care more about case 1 
currently. To clarify the issue, I answer your questions between lines:

1- Can the user switch cases down the road??

Not understand very well.

2- Does Version 3 overwrite Version 1 in both cases? Or is there some future 
PathC/PathD thing going on?

The Version 3 should be able to upgrade version 1 in PathA or version 2 in 
PathB, even do a new install in PathC.

3- When Version 2 is installed, is version 1 ever removed by any means?

When version 2 is installed in PathB, it should be no related to version 1 in 
PathA. So Version 1 can be removed or upgraded. 

4- If a security or other flaw is discovered in Version 1, how do you intend to 
address it?

I would like to adress the installation by product code, upgrade code, and the 
path information. Althought version 1 installed in PathA, and Version 2 
installed in PathB, they are independent actually.

I don't know if it is possible to realize this.


Best regards,

Chunyan

-Ursprüngliche Nachricht-
Von: Blair [mailto:os...@live.com] 
Gesendet: Dienstag, 27. Oktober 2009 12:48
An: 'General discussion for Windows Installer XML toolset.'
Betreff: Re: [WiX-users] Upgrade and new install

I don't see the difference between Case 1 and Case 2, except that the 
installation directories are switched.

Four more questions (unless there is some error in what I understood so far)
1- Can the user switch cases down the road??
2- Does Version 3 overwrite Version 1 in both cases? Or is there some future 
PathC/PathD thing going on?
3- When Version 2 is installed, is version 1 ever removed by any means?
4- If a security or other flaw is discovered in Version 1, how do you intend to 
address it?

-Original Message-
From: Jiang, Chunyan (GE Healthcare) [mailto:chunyan.ji...@ge.com]
Sent: Tuesday, October 27, 2009 2:45 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Upgrade and new install

Hi Blair,

Probably my use-case is special. My software should be able to install 
flexiably. It can be installed as following:

Case 1:
Version 1 install to PathA, Version 2 install to PathB

Case 2:
Version 2 install to PathA, version 1 install to PathB, again.

I am stuck in developing case 1. When I have installed version 1 to PathA, then 
try to install verison 2 to PathB, the version 1 will always be detected via 
"Install Validate". And it tries to remove files from PathA during "Remove 
Files". Althought version 2 can be installed to PathB at last, version 1 is 
brocken. And some CA in version 2 PathB can not run since version 1 PathA are 
detected for upgrade. Therefore, I hope there is some registry mechanism so 
that when install version 2 to PathB, instead of PathA, then the new version 
will not be treated as upgrade. So that the files are not "validated" and 
"removed".

For case 2, I know it is "multi instance" issue in wix installer develop. It is 
my next step.

Could you please give me some help how to realize case 1?


Thanks a lot!

Chunyan

-Ursprüngliche Nachricht-
Von: Blair [mailto:os...@live.com]
Gesendet: Dienstag, 27. Oktober 2009 02:35
An: 'General discussion for Windows Installer XML toolset.'
Betreff: Re: [WiX-users] Upgrade and new install

So you need upgrades to not replace previous installations? In that case they 
are not upgrades.

I'm still trying to understand your use-case and your servicing strategy.
How do you intend to fix older versions? What do your users expect when they 
run a newer installation package from you when they have an older version 
installed?

-Original Message-
From: Jiang, Chunyan (GE Healthcare) [mailto:chunyan.ji...@ge.com]
Sent: Friday, October 23, 2009 2:48 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Upgrade and new install

Hi Rob,

I think over my scenario and clarify it that I want my App should be installed 
with the registry, which has the path information (PathA) in it.
So that when install a higher version (version 2) in another path (PathB), even 
they have same UpgradeCode, the previous version (version1) should not be 
upgraded (no Remove Action, no CustomAction). And the higher version is only 
treated as new install.

However, if I define the RegistryKey and RegistrySearch as my previous email, 
the Property "INSTALLDIR" will be always true, since it is all for the current 
install, not search previus install.

And when I check the Registry Editor, I only find the current Registry:
ViewPointUpgrade, value:PathB

There is no previous registry. So the RegistrySearch will always be true.

As I imagine, all the installation should be in the registry. And the property 
"INSTALLDIR" will do the registrysearch for all

Re: [WiX-users] Upgrade and new install

[Blair]

I don't see the difference between Case 1 and Case 2, except that the
installation directories are switched.

Four more questions (unless there is some error in what I understood so far)
1- Can the user switch cases down the road??
2- Does Version 3 overwrite Version 1 in both cases? Or is there some future
PathC/PathD thing going on?
3- When Version 2 is installed, is version 1 ever removed by any means?
4- If a security or other flaw is discovered in Version 1, how do you intend
to address it?

-Original Message-
From: Jiang, Chunyan (GE Healthcare) [mailto:chunyan.ji...@ge.com] 
Sent: Tuesday, October 27, 2009 2:45 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Upgrade and new install

Hi Blair,

Probably my use-case is special. My software should be able to install
flexiably. It can be installed as following:

Case 1:
Version 1 install to PathA, Version 2 install to PathB

Case 2:
Version 2 install to PathA, version 1 install to PathB, again.

I am stuck in developing case 1. When I have installed version 1 to PathA,
then try to install verison 2 to PathB, the version 1 will always be
detected via "Install Validate". And it tries to remove files from PathA
during "Remove Files". Althought version 2 can be installed to PathB at
last, version 1 is brocken. And some CA in version 2 PathB can not run since
version 1 PathA are detected for upgrade. Therefore, I hope there is some
registry mechanism so that when install version 2 to PathB, instead of
PathA, then the new version will not be treated as upgrade. So that the
files are not "validated" and "removed".

For case 2, I know it is "multi instance" issue in wix installer develop. It
is my next step.

Could you please give me some help how to realize case 1?


Thanks a lot!

Chunyan

-Ursprüngliche Nachricht-
Von: Blair [mailto:os...@live.com] 
Gesendet: Dienstag, 27. Oktober 2009 02:35
An: 'General discussion for Windows Installer XML toolset.'
Betreff: Re: [WiX-users] Upgrade and new install

So you need upgrades to not replace previous installations? In that case
they are not upgrades.

I'm still trying to understand your use-case and your servicing strategy.
How do you intend to fix older versions? What do your users expect when they
run a newer installation package from you when they have an older version
installed?

-Original Message-
From: Jiang, Chunyan (GE Healthcare) [mailto:chunyan.ji...@ge.com]
Sent: Friday, October 23, 2009 2:48 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Upgrade and new install

Hi Rob,

I think over my scenario and clarify it that I want my App should be
installed with the registry, which has the path information (PathA) in it.
So that when install a higher version (version 2) in another path (PathB),
even they have same UpgradeCode, the previous version (version1) should not
be upgraded (no Remove Action, no CustomAction). And the higher version is
only treated as new install.

However, if I define the RegistryKey and RegistrySearch as my previous
email, the Property "INSTALLDIR" will be always true, since it is all for
the current install, not search previus install.

And when I check the Registry Editor, I only find the current Registry:
ViewPointUpgrade, value:PathB

There is no previous registry. So the RegistrySearch will always be true.

As I imagine, all the installation should be in the registry. And the
property "INSTALLDIR" will do the registrysearch for all installed version.

How to realize it?

Regards,


Chunyan

-Ursprüngliche Nachricht-
Von: Jiang, Chunyan (GE Healthcare)
Gesendet: Freitag, 23. Oktober 2009 10:39
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] Upgrade and new install

Hi Rob,

You are right. I have been in the pain for long time. But I have no charge
of this CustomAction. I only know this CustomAction should be run only in
the upgrade. And I have to make it work. :(

I have modified the Registry element and give the condition to the custom as
bellow:


  



  

  

  


PREVIOUSFOUND
AND INSTALLDIR

The the upgrade is defined in the beginning of the wxs:

  


However, when I run the upgrade, install version 2 in PathA, where the
version 1 installed, CustomAction is still not called. It causes the problem
for later function.

Is there something wrong in Property define, or in the condition for
CustomAction?


Regards,

Chunyan

-Ursprüngliche Nachricht-
Von: Rob Mensching [mailto:r...@robmensching.com]
Gesendet: Donnerstag, 22. Oktober 2009 17:38
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] Upgrade and new install

1. Personally, I would highly suggest you change your application so this
CustomAction is unnecessary. You are in for a world of

Re: [WiX-users] Upgrade and new install

[Jiang, Chunyan (GE Healthcare)]

Hi Blair,

Probably my use-case is special. My software should be able to install 
flexiably. It can be installed as following:

Case 1:
Version 1 install to PathA, Version 2 install to PathB

Case 2:
Version 2 install to PathA, version 1 install to PathB, again.

I am stuck in developing case 1. When I have installed version 1 to PathA, then 
try to install verison 2 to PathB, the version 1 will always be detected via 
"Install Validate". And it tries to remove files from PathA during "Remove 
Files". Althought version 2 can be installed to PathB at last, version 1 is 
brocken. And some CA in version 2 PathB can not run since version 1 PathA are 
detected for upgrade. Therefore, I hope there is some registry mechanism so 
that when install version 2 to PathB, instead of PathA, then the new version 
will not be treated as upgrade. So that the files are not "validated" and 
"removed".

For case 2, I know it is "multi instance" issue in wix installer develop. It is 
my next step.

Could you please give me some help how to realize case 1?


Thanks a lot!

Chunyan

-Ursprüngliche Nachricht-
Von: Blair [mailto:os...@live.com] 
Gesendet: Dienstag, 27. Oktober 2009 02:35
An: 'General discussion for Windows Installer XML toolset.'
Betreff: Re: [WiX-users] Upgrade and new install

So you need upgrades to not replace previous installations? In that case they 
are not upgrades.

I'm still trying to understand your use-case and your servicing strategy.
How do you intend to fix older versions? What do your users expect when they 
run a newer installation package from you when they have an older version 
installed?

-Original Message-
From: Jiang, Chunyan (GE Healthcare) [mailto:chunyan.ji...@ge.com]
Sent: Friday, October 23, 2009 2:48 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Upgrade and new install

Hi Rob,

I think over my scenario and clarify it that I want my App should be installed 
with the registry, which has the path information (PathA) in it.
So that when install a higher version (version 2) in another path (PathB), even 
they have same UpgradeCode, the previous version (version1) should not be 
upgraded (no Remove Action, no CustomAction). And the higher version is only 
treated as new install.

However, if I define the RegistryKey and RegistrySearch as my previous email, 
the Property "INSTALLDIR" will be always true, since it is all for the current 
install, not search previus install.

And when I check the Registry Editor, I only find the current Registry:
ViewPointUpgrade, value:PathB

There is no previous registry. So the RegistrySearch will always be true.

As I imagine, all the installation should be in the registry. And the property 
"INSTALLDIR" will do the registrysearch for all installed version.

How to realize it?

Regards,


Chunyan

-Ursprüngliche Nachricht-
Von: Jiang, Chunyan (GE Healthcare)
Gesendet: Freitag, 23. Oktober 2009 10:39
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] Upgrade and new install

Hi Rob,

You are right. I have been in the pain for long time. But I have no charge of 
this CustomAction. I only know this CustomAction should be run only in the 
upgrade. And I have to make it work. :(

I have modified the Registry element and give the condition to the custom as
bellow:


  



  

  

  


PREVIOUSFOUND
AND INSTALLDIR

The the upgrade is defined in the beginning of the wxs:

  


However, when I run the upgrade, install version 2 in PathA, where the version 
1 installed, CustomAction is still not called. It causes the problem for later 
function.

Is there something wrong in Property define, or in the condition for 
CustomAction?


Regards,

Chunyan

-Ursprüngliche Nachricht-
Von: Rob Mensching [mailto:r...@robmensching.com]
Gesendet: Donnerstag, 22. Oktober 2009 17:38
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] Upgrade and new install

1. Personally, I would highly suggest you change your application so this 
CustomAction is unnecessary. You are in for a world of pain in the long run.

2. The Registry element has been deprecated in WiX v3. The warning tells you 
exactly what to do.

3. You'll have to condition your CustomAction in your first version of your MSI 
to not run on upgrade in the cases you are trying to avoid. If you have already 
shipped the first version of the MSI then you probably have to release a patch 
to that version to add the condition. After the patch is applied then you can 
try the upgrade.

4. See #1. 


On Thu, Oct 22, 2009 at 6:51 AM, Jiang, Chunyan (GE Healthcare) < 
chunyan.ji...@ge.com> wrote:

> Although there is Warning message on compile. From the verbose log I 
> got to know that the Custom Action will not be called when i

Re: [WiX-users] Upgrade and new install

[Blair]

So you need upgrades to not replace previous installations? In that case
they are not upgrades.

I'm still trying to understand your use-case and your servicing strategy.
How do you intend to fix older versions? What do your users expect when they
run a newer installation package from you when they have an older version
installed?

-Original Message-
From: Jiang, Chunyan (GE Healthcare) [mailto:chunyan.ji...@ge.com] 
Sent: Friday, October 23, 2009 2:48 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Upgrade and new install

Hi Rob,

I think over my scenario and clarify it that I want my App should be
installed with the registry, which has the path information (PathA) in it.
So that when install a higher version (version 2) in another path (PathB),
even they have same UpgradeCode, the previous version (version1) should not
be upgraded (no Remove Action, no CustomAction). And the higher version is
only treated as new install.

However, if I define the RegistryKey and RegistrySearch as my previous
email, the Property "INSTALLDIR" will be always true, since it is all for
the current install, not search previus install.

And when I check the Registry Editor, I only find the current Registry:
ViewPointUpgrade, value:PathB

There is no previous registry. So the RegistrySearch will always be true.

As I imagine, all the installation should be in the registry. And the
property "INSTALLDIR" will do the registrysearch for all installed version.

How to realize it?

Regards,


Chunyan

-Ursprüngliche Nachricht-
Von: Jiang, Chunyan (GE Healthcare) 
Gesendet: Freitag, 23. Oktober 2009 10:39
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] Upgrade and new install

Hi Rob,

You are right. I have been in the pain for long time. But I have no charge
of this CustomAction. I only know this CustomAction should be run only in
the upgrade. And I have to make it work. :(

I have modified the Registry element and give the condition to the custom as
bellow:


  



  

  

  


PREVIOUSFOUND
AND INSTALLDIR

The the upgrade is defined in the beginning of the wxs:

  


However, when I run the upgrade, install version 2 in PathA, where the
version 1 installed, CustomAction is still not called. It causes the problem
for later function.

Is there something wrong in Property define, or in the condition for
CustomAction?


Regards,

Chunyan

-Ursprüngliche Nachricht-
Von: Rob Mensching [mailto:r...@robmensching.com]
Gesendet: Donnerstag, 22. Oktober 2009 17:38
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] Upgrade and new install

1. Personally, I would highly suggest you change your application so this
CustomAction is unnecessary. You are in for a world of pain in the long run.

2. The Registry element has been deprecated in WiX v3. The warning tells you
exactly what to do.

3. You'll have to condition your CustomAction in your first version of your
MSI to not run on upgrade in the cases you are trying to avoid. If you have
already shipped the first version of the MSI then you probably have to
release a patch to that version to add the condition. After the patch is
applied then you can try the upgrade.

4. See #1. 


On Thu, Oct 22, 2009 at 6:51 AM, Jiang, Chunyan (GE Healthcare) <
chunyan.ji...@ge.com> wrote:

> Although there is Warning message on compile. From the verbose log I 
> got to know that the Custom Action will not be called when install 
> version 2 to PathB.
>
> Howver, there is Remove Action trying to remove files from PathA for 
> version 1 install during installing version 2 to PathB. And Install 
> Validate also checks the files in PathA.
>
> How can I prevent the Remove Action performing on Version 1 in PathA, 
> when install Version 2 in PathB. Should I set the condition 
> "INSTALLDIR" to somewhere, like I did for custom action?
>
>
>
> -Ursprüngliche Nachricht-
> Von: Jiang, Chunyan (GE Healthcare)
> Gesendet: Donnerstag, 22. Oktober 2009 13:19
> An: General discussion for Windows Installer XML toolset.
> Betreff: Re: [WiX-users] Upgrade and new install
>
> When I searched in Google, I found some one has the same problem as 
> me. And the suggested solution is to define a property using 
> RegistrySearch. And also define a registry with the install path 
> [APPLICATIONFOLDER]. So that the upgrade will only happen when the
registry with path found.
>
> I tried it as:
>
>
>   Root='HKCU' Key='Software\Microsoft\ViewPointUpgrade'
> Name='InstallDir' />
>
>
>
>   Guid="D555488C-C8E7-44eb-91EC-3750602A7599">
> Key='Software\Microsoft\ViewPointUpgrade'
>  Name='Inst

Re: [WiX-users] Upgrade and new install

[Jiang, Chunyan (GE Healthcare)]

Hi Rob,

I think over my scenario and clarify it that I want my App should be installed 
with the registry, which has the path information (PathA) in it. So that when 
install a higher version (version 2) in another path (PathB), even they have 
same UpgradeCode, the previous version (version1) should not be upgraded (no 
Remove Action, no CustomAction). And the higher version is only treated as new 
install.

However, if I define the RegistryKey and RegistrySearch as my previous email, 
the Property "INSTALLDIR" will be always true, since it is all for the current 
install, not search previus install.

And when I check the Registry Editor, I only find the current Registry:
ViewPointUpgrade, value:PathB

There is no previous registry. So the RegistrySearch will always be true.

As I imagine, all the installation should be in the registry. And the property 
"INSTALLDIR" will do the registrysearch for all installed version.

How to realize it?

Regards,


Chunyan

-Ursprüngliche Nachricht-
Von: Jiang, Chunyan (GE Healthcare) 
Gesendet: Freitag, 23. Oktober 2009 10:39
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] Upgrade and new install

Hi Rob,

You are right. I have been in the pain for long time. But I have no charge of 
this CustomAction. I only know this CustomAction should be run only in the 
upgrade. And I have to make it work. :(

I have modified the Registry element and give the condition to the custom as 
bellow:


  



  

  

  


PREVIOUSFOUND AND 
INSTALLDIR

The the upgrade is defined in the beginning of the wxs:

  


However, when I run the upgrade, install version 2 in PathA, where the version 
1 installed, CustomAction is still not called. It causes the problem for later 
function.

Is there something wrong in Property define, or in the condition for 
CustomAction?


Regards,

Chunyan

-Ursprüngliche Nachricht-
Von: Rob Mensching [mailto:r...@robmensching.com]
Gesendet: Donnerstag, 22. Oktober 2009 17:38
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] Upgrade and new install

1. Personally, I would highly suggest you change your application so this 
CustomAction is unnecessary. You are in for a world of pain in the long run.

2. The Registry element has been deprecated in WiX v3. The warning tells you 
exactly what to do.

3. You'll have to condition your CustomAction in your first version of your MSI 
to not run on upgrade in the cases you are trying to avoid. If you have already 
shipped the first version of the MSI then you probably have to release a patch 
to that version to add the condition. After the patch is applied then you can 
try the upgrade.

4. See #1. 


On Thu, Oct 22, 2009 at 6:51 AM, Jiang, Chunyan (GE Healthcare) < 
chunyan.ji...@ge.com> wrote:

> Although there is Warning message on compile. From the verbose log I 
> got to know that the Custom Action will not be called when install 
> version 2 to PathB.
>
> Howver, there is Remove Action trying to remove files from PathA for 
> version 1 install during installing version 2 to PathB. And Install 
> Validate also checks the files in PathA.
>
> How can I prevent the Remove Action performing on Version 1 in PathA, 
> when install Version 2 in PathB. Should I set the condition 
> "INSTALLDIR" to somewhere, like I did for custom action?
>
>
>
> -Ursprüngliche Nachricht-
> Von: Jiang, Chunyan (GE Healthcare)
> Gesendet: Donnerstag, 22. Oktober 2009 13:19
> An: General discussion for Windows Installer XML toolset.
> Betreff: Re: [WiX-users] Upgrade and new install
>
> When I searched in Google, I found some one has the same problem as 
> me. And the suggested solution is to define a property using 
> RegistrySearch. And also define a registry with the install path 
> [APPLICATIONFOLDER]. So that the upgrade will only happen when the registry 
> with path found.
>
> I tried it as:
>
>
>   Root='HKCU' Key='Software\Microsoft\ViewPointUpgrade'
> Name='InstallDir' />
>
>
>
>   Guid="D555488C-C8E7-44eb-91EC-3750602A7599">
> Key='Software\Microsoft\ViewPointUpgrade'
>  Name='InstallDir' Action='write' Type='string'
> Value='[APPLICATIONFOLDER]' />
>  
>
>
> And call custom action as:
>
>   Before="InstallFiles">PREVIOUSFOUND AND INSTALLDIR
>
> But I got warning when I compile it:
>
>  warning CNDL1080: The Registry element has been deprecated.  Please 
> use one of the new elements which replaces its functionality:
> RegistryKey for creating registry keys, RegistryValue for writing 
> registry values, RemoveRegistryKey fo

Re: [WiX-users] Upgrade and new install

[Jiang, Chunyan (GE Healthcare)]

Hi Rob,

You are right. I have been in the pain for long time. But I have no charge of 
this CustomAction. I only know this CustomAction should be run only in the 
upgrade. And I have to make it work. :(

I have modified the Registry element and give the condition to the custom as 
bellow:


  



  

  

  


PREVIOUSFOUND AND 
INSTALLDIR

The the upgrade is defined in the beginning of the wxs:

  


However, when I run the upgrade, install version 2 in PathA, where the version 
1 installed, CustomAction is still not called. It causes the problem for later 
function.

Is there something wrong in Property define, or in the condition for 
CustomAction?


Regards,

Chunyan

-Ursprüngliche Nachricht-
Von: Rob Mensching [mailto:r...@robmensching.com] 
Gesendet: Donnerstag, 22. Oktober 2009 17:38
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] Upgrade and new install

1. Personally, I would highly suggest you change your application so this 
CustomAction is unnecessary. You are in for a world of pain in the long run.

2. The Registry element has been deprecated in WiX v3. The warning tells you 
exactly what to do.

3. You'll have to condition your CustomAction in your first version of your MSI 
to not run on upgrade in the cases you are trying to avoid. If you have already 
shipped the first version of the MSI then you probably have to release a patch 
to that version to add the condition. After the patch is applied then you can 
try the upgrade.

4. See #1. 


On Thu, Oct 22, 2009 at 6:51 AM, Jiang, Chunyan (GE Healthcare) < 
chunyan.ji...@ge.com> wrote:

> Although there is Warning message on compile. From the verbose log I 
> got to know that the Custom Action will not be called when install 
> version 2 to PathB.
>
> Howver, there is Remove Action trying to remove files from PathA for 
> version 1 install during installing version 2 to PathB. And Install 
> Validate also checks the files in PathA.
>
> How can I prevent the Remove Action performing on Version 1 in PathA, 
> when install Version 2 in PathB. Should I set the condition 
> "INSTALLDIR" to somewhere, like I did for custom action?
>
>
>
> -Ursprüngliche Nachricht-
> Von: Jiang, Chunyan (GE Healthcare)
> Gesendet: Donnerstag, 22. Oktober 2009 13:19
> An: General discussion for Windows Installer XML toolset.
> Betreff: Re: [WiX-users] Upgrade and new install
>
> When I searched in Google, I found some one has the same problem as 
> me. And the suggested solution is to define a property using 
> RegistrySearch. And also define a registry with the install path 
> [APPLICATIONFOLDER]. So that the upgrade will only happen when the registry 
> with path found.
>
> I tried it as:
>
>
>   Root='HKCU' Key='Software\Microsoft\ViewPointUpgrade'
> Name='InstallDir' />
>
>
>
>   Guid="D555488C-C8E7-44eb-91EC-3750602A7599">
> Key='Software\Microsoft\ViewPointUpgrade'
>  Name='InstallDir' Action='write' Type='string'
> Value='[APPLICATIONFOLDER]' />
>  
>
>
> And call custom action as:
>
>   Before="InstallFiles">PREVIOUSFOUND AND INSTALLDIR
>
> But I got warning when I compile it:
>
>  warning CNDL1080: The Registry element has been deprecated.  Please 
> use one of the new elements which replaces its functionality: 
> RegistryKey for creating registry keys, RegistryValue for writing 
> registry values, RemoveRegistryKey for removing registry keys, and 
> RemoveRegistryValue for removing registry values.
>
> And when I install this version 2 installer msi, select PathB, the 
> problem is still there.
>
> Is there something wrong in the Registry define? How to change it?
>
>
>
> -Ursprüngliche Nachricht-
> Von: Jiang, Chunyan (GE Healthcare)
> Gesendet: Donnerstag, 22. Oktober 2009 09:04
> An: General discussion for Windows Installer XML toolset.
> Betreff: [WiX-users] Upgrade and new install
>
> Hi Wix-users,
>
> I have developed one upgradable installer with Wix3. As I understand 
> that main upgrade is same as new install. My scenario is that my 
> version
> 1 has been installed to PathA. And I have an upgraded version 2. If I 
> install version to to PathA, the old files are removed, the new files 
> are installed. Everything is fine. If I install version 2 to PathB, 
> the new files are copied to PathB, same as new install. It sounds good.
>
> However, there are custom actions in my installer, named MyCA. MyCA 
> should be called only by upgrade. So if version 2 installed to PathA, 
> MyCA in PathA will be calle

Re: [WiX-users] Upgrade and new install

[Rob Mensching]

1. Personally, I would highly suggest you change your application so this
CustomAction is unnecessary. You are in for a world of pain in the long run.

2. The Registry element has been deprecated in WiX v3. The warning tells you
exactly what to do.

3. You'll have to condition your CustomAction in your first version of your
MSI to not run on upgrade in the cases you are trying to avoid. If you have
already shipped the first version of the MSI then you probably have to
release a patch to that version to add the condition. After the patch is
applied then you can try the upgrade.

4. See #1. 


On Thu, Oct 22, 2009 at 6:51 AM, Jiang, Chunyan (GE Healthcare) <
chunyan.ji...@ge.com> wrote:

> Although there is Warning message on compile. From the verbose log I got to
> know that the Custom Action will not be called when install version 2 to
> PathB.
>
> Howver, there is Remove Action trying to remove files from PathA for
> version 1 install during installing version 2 to PathB. And Install Validate
> also checks the files in PathA.
>
> How can I prevent the Remove Action performing on Version 1 in PathA, when
> install Version 2 in PathB. Should I set the condition "INSTALLDIR" to
> somewhere, like I did for custom action?
>
>
>
> -Ursprüngliche Nachricht-
> Von: Jiang, Chunyan (GE Healthcare)
> Gesendet: Donnerstag, 22. Oktober 2009 13:19
> An: General discussion for Windows Installer XML toolset.
> Betreff: Re: [WiX-users] Upgrade and new install
>
> When I searched in Google, I found some one has the same problem as me. And
> the suggested solution is to define a property using RegistrySearch. And
> also define a registry with the install path [APPLICATIONFOLDER]. So that
> the upgrade will only happen when the registry with path found.
>
> I tried it as:
>
>
>   Root='HKCU' Key='Software\Microsoft\ViewPointUpgrade'
> Name='InstallDir' />
>
>
>
>   Guid="D555488C-C8E7-44eb-91EC-3750602A7599">
> Key='Software\Microsoft\ViewPointUpgrade'
>  Name='InstallDir' Action='write' Type='string'
> Value='[APPLICATIONFOLDER]' />
>  
>
>
> And call custom action as:
>
>   Before="InstallFiles">PREVIOUSFOUND AND INSTALLDIR
>
> But I got warning when I compile it:
>
>  warning CNDL1080: The Registry element has been deprecated.  Please use
> one of the new elements which replaces its functionality: RegistryKey for
> creating registry keys, RegistryValue for writing registry values,
> RemoveRegistryKey for removing registry keys, and RemoveRegistryValue for
> removing registry values.
>
> And when I install this version 2 installer msi, select PathB, the problem
> is still there.
>
> Is there something wrong in the Registry define? How to change it?
>
>
>
> -Ursprüngliche Nachricht-
> Von: Jiang, Chunyan (GE Healthcare)
> Gesendet: Donnerstag, 22. Oktober 2009 09:04
> An: General discussion for Windows Installer XML toolset.
> Betreff: [WiX-users] Upgrade and new install
>
> Hi Wix-users,
>
> I have developed one upgradable installer with Wix3. As I understand that
> main upgrade is same as new install. My scenario is that my version
> 1 has been installed to PathA. And I have an upgraded version 2. If I
> install version to to PathA, the old files are removed, the new files are
> installed. Everything is fine. If I install version 2 to PathB, the new
> files are copied to PathB, same as new install. It sounds good.
>
> However, there are custom actions in my installer, named MyCA. MyCA should
> be called only by upgrade. So if version 2 installed to PathA, MyCA in PathA
> will be called. It is fine. But if version 2 is installed in PathB, MyCA in
> PathA will still be called. It causes some problem for PathB install.
>
> How can I make a condition to MyCA, so that it will only be called when the
> upgraded version installed in it's path? If version 2 is installed in PathB,
> discard MyCA in PathA, do it same as new install.
>
>
> Best regards
>
> Chunyan
>
> --
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the
> only developer event you need to attend this year. Jumpstart your developing
> skills, take BlackBerry mobile applications to market and stay ahead of the
> curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/l

Re: [WiX-users] Upgrade and new install

[Jiang, Chunyan (GE Healthcare)]

Although there is Warning message on compile. From the verbose log I got to 
know that the Custom Action will not be called when install version 2 to PathB. 
 

Howver, there is Remove Action trying to remove files from PathA for version 1 
install during installing version 2 to PathB. And Install Validate also checks 
the files in PathA.

How can I prevent the Remove Action performing on Version 1 in PathA, when 
install Version 2 in PathB. Should I set the condition "INSTALLDIR" to 
somewhere, like I did for custom action?



-Ursprüngliche Nachricht-
Von: Jiang, Chunyan (GE Healthcare) 
Gesendet: Donnerstag, 22. Oktober 2009 13:19
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] Upgrade and new install

When I searched in Google, I found some one has the same problem as me. And the 
suggested solution is to define a property using RegistrySearch. And also 
define a registry with the install path [APPLICATIONFOLDER]. So that the 
upgrade will only happen when the registry with path found. 

I tried it as:


   



  

  
 

And call custom action as:

  PREVIOUSFOUND 
AND INSTALLDIR

But I got warning when I compile it:

 warning CNDL1080: The Registry element has been deprecated.  Please use one of 
the new elements which replaces its functionality: RegistryKey for creating 
registry keys, RegistryValue for writing registry values, RemoveRegistryKey for 
removing registry keys, and RemoveRegistryValue for removing registry values.

And when I install this version 2 installer msi, select PathB, the problem is 
still there.

Is there something wrong in the Registry define? How to change it?



-Ursprüngliche Nachricht-
Von: Jiang, Chunyan (GE Healthcare)
Gesendet: Donnerstag, 22. Oktober 2009 09:04
An: General discussion for Windows Installer XML toolset.
Betreff: [WiX-users] Upgrade and new install

Hi Wix-users,
 
I have developed one upgradable installer with Wix3. As I understand that main 
upgrade is same as new install. My scenario is that my version
1 has been installed to PathA. And I have an upgraded version 2. If I install 
version to to PathA, the old files are removed, the new files are installed. 
Everything is fine. If I install version 2 to PathB, the new files are copied 
to PathB, same as new install. It sounds good.
 
However, there are custom actions in my installer, named MyCA. MyCA should be 
called only by upgrade. So if version 2 installed to PathA, MyCA in PathA will 
be called. It is fine. But if version 2 is installed in PathB, MyCA in PathA 
will still be called. It causes some problem for PathB install. 
 
How can I make a condition to MyCA, so that it will only be called when the 
upgraded version installed in it's path? If version 2 is installed in PathB, 
discard MyCA in PathA, do it same as new install.
 
 
Best regards
 
Chunyan
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the 
only developer event you need to attend this year. Jumpstart your developing 
skills, take BlackBerry mobile applications to market and stay ahead of the 
curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the 
only developer event you need to attend this year. Jumpstart your developing 
skills, take BlackBerry mobile applications to market and stay ahead of the 
curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Upgrade and new install

[Jiang, Chunyan (GE Healthcare)]

When I searched in Google, I found some one has the same problem as me. And the 
suggested solution is to define a property using RegistrySearch. And also 
define a registry with the install path [APPLICATIONFOLDER]. So that the 
upgrade will only happen when the registry with path found. 

I tried it as:


   



  

  
 

And call custom action as:

  PREVIOUSFOUND 
AND INSTALLDIR

But I got warning when I compile it:

 warning CNDL1080: The Registry element has been deprecated.  Please use one of 
the new elements which replaces its functionality: RegistryKey for creating 
registry keys, RegistryValue for writing registry values, RemoveRegistryKey for 
removing registry keys, and RemoveRegistryValue for removing registry values.

And when I install this version 2 installer msi, select PathB, the problem is 
still there.

Is there something wrong in the Registry define? How to change it?



-Ursprüngliche Nachricht-
Von: Jiang, Chunyan (GE Healthcare) 
Gesendet: Donnerstag, 22. Oktober 2009 09:04
An: General discussion for Windows Installer XML toolset.
Betreff: [WiX-users] Upgrade and new install

Hi Wix-users,
 
I have developed one upgradable installer with Wix3. As I understand that main 
upgrade is same as new install. My scenario is that my version
1 has been installed to PathA. And I have an upgraded version 2. If I install 
version to to PathA, the old files are removed, the new files are installed. 
Everything is fine. If I install version 2 to PathB, the new files are copied 
to PathB, same as new install. It sounds good.
 
However, there are custom actions in my installer, named MyCA. MyCA should be 
called only by upgrade. So if version 2 installed to PathA, MyCA in PathA will 
be called. It is fine. But if version 2 is installed in PathB, MyCA in PathA 
will still be called. It causes some problem for PathB install. 
 
How can I make a condition to MyCA, so that it will only be called when the 
upgraded version installed in it's path? If version 2 is installed in PathB, 
discard MyCA in PathA, do it same as new install.
 
 
Best regards
 
Chunyan
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the 
only developer event you need to attend this year. Jumpstart your developing 
skills, take BlackBerry mobile applications to market and stay ahead of the 
curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Upgrade and new install

[Jiang, Chunyan (GE Healthcare)]

Hi Wix-users,
 
I have developed one upgradable installer with Wix3. As I understand
that main upgrade is same as new install. My scenario is that my version
1 has been installed to PathA. And I have an upgraded version 2. If I
install version to to PathA, the old files are removed, the new files
are installed. Everything is fine. If I install version 2 to PathB, the
new files are copied to PathB, same as new install. It sounds good.
 
However, there are custom actions in my installer, named MyCA. MyCA
should be called only by upgrade. So if version 2 installed to PathA,
MyCA in PathA will be called. It is fine. But if version 2 is installed
in PathB, MyCA in PathA will still be called. It causes some problem for
PathB install. 
 
How can I make a condition to MyCA, so that it will only be called when
the upgraded version installed in it's path? If version 2 is installed
in PathB, discard MyCA in PathA, do it same as new install.
 
 
Best regards
 
Chunyan
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users