Re: [WiX-users] How to add FilesInUse support

[little.forest]

Thanks Phil.


"Version 1.0 is running when you do the upgrade. It cannot replace MainApp.exe 
unless it can be completely shut down."
- yes, I understood this.

"The purpose of the FilesInUse dialog is to ask the user to manually shut it 
down. There's no automatic shutdown."
- yes, I understood the purpose of FilesInUse. We don't mind to let the user to 
manually shut it down - actually this is something we're trying to do. I 
actually did shut it down. But after that, there was the error.

Anyways, I kept trying and trying. Finally it seems working. I did it by 
scheduling the custom action from [Before="InstallFinalize"] to 
[After="InstallFiles"]. I'll need to do more testing, but now this is how it 
works:
- keep the old version running
- install the new version
- FilesInUse dialog shows up
- Manually shut down the old version
- the installation process keeps going
- then apparently the custom action runs
- the installatioin finished.

But honestly, I don't understand why it didn't work. I don't understand why it 
does work now, either.

I mean, why FilesInUse associates with a custom action's sequence? Why 
everything works fine if the old version wasn't running? Is it possible the 
internally Wix has some flag not setup correctly in the FilesInUse case and the 
application happens running? I understand the application must be shut down 
before it gets installed. I already had shut it down. And I hit the "Retry" 
button on the FilesInUse dialog. The installation process keeps going. How come 
the application isn't installed after the FilesInUse dialog?

If you know the reason, please tell me. 

Thanks.





From: "Wilson, Phil" 
To: General discussion for Windows Installer XML toolset. 

Sent: Friday, October 2, 2009 4:43:10 PM
Subject: Re: [WiX-users] How to add FilesInUse support

Your custom action effectively says "Run version 2.0 of mainapp.exe after it's 
been installed on the system". Version 1.0 is running when you do the upgrade. 
It cannot replace MainApp.exe unless it can be completely shut down.  The 
purpose of the FilesInUse dialog is to ask the user to manually shut it down. 
There's no automatic shutdown.  FilesInUse isn't really linked with a custom 
action, except that you've forced it to be linked by creating a custom action 
to run a program that cannot be installed on the system until after a reboot.


Phil Wilson


-Original Message-
From: little.forest [mailto:little.for...@ymail.com]
Sent: Friday, October 02, 2009 4:02 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How to add FilesInUse support

Thanks Phil! I really appreciate your reply and your time.


"If MainApp running and FilesInUse does not shut it down, then it cannot be 
replaced on the system, so it can't be run."
- Correct. This is why we need to put this FilesInUse in. Here are what I 
experienced:
- the old version running
- start running the new version installer
- a few seconds, the FilesInUse dialog showed up
- I manually exit the old version of application
- the new version installation process kept going.. a few seconds, the build 
failed Error 2753
- go to the "Program Files" folder, the application folder wasn't even created.

"Is it doing something that requires it to be a custom action actually being 
installed onto the system? I'm thinking it can be in the Binary table, 
depending on why it's being run."
- Our application is a .NET 3.5 WPF based application. The application is 
written in C#. There is a perform issue. Every time when the application 
startup, it'll take a fair mount of time to start. So the development team came 
up with an idea. The idea is, right after the installation and before the end 
user launching the application, start the "bootloader" by using the main 
application with a command line argument(something like "mainapp.exe 
-bootload"). Note: the main application name is mainapp.exe. If we "real" run 
the application, the same mainapp.exe will be executed. What this "-bootload" 
does is that it will start some services, load some DLL files etc. I'm not sure 
whether this design is good or not. But it does work fine. When the end user 
launch the application, she will feel the application is fast - because 
services and DLLs already loaded. So we need this custom action to start this 
bootloader in installer. Actually, you know, this
bootloader is the same as the main application, but just with an argument. Will 
this cause problem? But why there is no any files installed? The application 
folder not even created? I did schedule this custom action before 
"InstallFinalize" which is almost the end of the installation. I use custom 
action type 18 because the executable(actually it's the main application) is 
installed with the application, and I need to set the command line argument. Is 
this the problem?

So one thing worth noticing, if there is no old version running, everything is 
fine. I'm really 

Re: [WiX-users] Feature 'ConfigureIISCompression' referenced in column'InstallExecuteSequence'.'Condition' of row 'SetDoDynamicCompression' is invalid.

[Blair]

That comes from ICE validation.

That report means that there is no feature named ConfigureIISCompression
which you referenced in your action's condition. Is that feature in a
different fragment that wasn't linked in?

-Original Message-
From: Anand [mailto:anand.daya...@gmail.com] 
Sent: Friday, October 02, 2009 4:31 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Feature 'ConfigureIISCompression' referenced in
column'InstallExecuteSequence'.'Condition' of row 'SetDoDynamicCompression'
is invalid.

HI,

  I'm getting the bellow error while linking with light. Any idea?

error LGHT0204 : ICE79: Feature 'ConfigureIISCompression' referenced in
column'InstallExecuteSequence'.'Condition' of row 'SetDoDynamicCompression'
is invalid.

Following is the code ,

(&ConfigureIISCompression = 1)

Thanks,
Anand

--
Come build with us! The BlackBerry® 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/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Come build with us! The BlackBerry® 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/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How to add FilesInUse support

[Wilson, Phil]

Your custom action effectively says "Run version 2.0 of mainapp.exe after it's 
been installed on the system". Version 1.0 is running when you do the upgrade. 
It cannot replace MainApp.exe unless it can be completely shut down.  The 
purpose of the FilesInUse dialog is to ask the user to manually shut it down. 
There's no automatic shutdown.  FilesInUse isn't really linked with a custom 
action, except that you've forced it to be linked by creating a custom action 
to run a program that cannot be installed on the system until after a reboot.


Phil Wilson


-Original Message-
From: little.forest [mailto:little.for...@ymail.com]
Sent: Friday, October 02, 2009 4:02 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How to add FilesInUse support

Thanks Phil! I really appreciate your reply and your time.


"If MainApp running and FilesInUse does not shut it down, then it cannot be 
replaced on the system, so it can't be run."
- Correct. This is why we need to put this FilesInUse in. Here are what I 
experienced:
- the old version running
- start running the new version installer
- a few seconds, the FilesInUse dialog showed up
- I manually exit the old version of application
- the new version installation process kept going.. a few seconds, the build 
failed Error 2753
- go to the "Program Files" folder, the application folder wasn't even created.

"Is it doing something that requires it to be a custom action actually being 
installed onto the system? I'm thinking it can be in the Binary table, 
depending on why it's being run."
- Our application is a .NET 3.5 WPF based application. The application is 
written in C#. There is a perform issue. Every time when the application 
startup, it'll take a fair mount of time to start. So the development team came 
up with an idea. The idea is, right after the installation and before the end 
user launching the application, start the "bootloader" by using the main 
application with a command line argument(something like "mainapp.exe 
-bootload"). Note: the main application name is mainapp.exe. If we "real" run 
the application, the same mainapp.exe will be executed. What this "-bootload" 
does is that it will start some services, load some DLL files etc. I'm not sure 
whether this design is good or not. But it does work fine. When the end user 
launch the application, she will feel the application is fast - because 
services and DLLs already loaded. So we need this custom action to start this 
bootloader in installer. Actually, you know, this
 bootloader is the same as the main application, but just with an argument. 
Will this cause problem? But why there is no any files installed? The 
application folder not even created? I did schedule this custom action before 
"InstallFinalize" which is almost the end of the installation. I use custom 
action type 18 because the executable(actually it's the main application) is 
installed with the application, and I need to set the command line argument. Is 
this the problem?

So one thing worth noticing, if there is no old version running, everything is 
fine. I'm really puzzled.

Thanks again, Phil.

/Brian




From: "Wilson, Phil" 
To: General discussion for Windows Installer XML toolset. 

Sent: Friday, October 2, 2009 3:07:36 PM
Subject: Re: [WiX-users] How to add FilesInUse support

If MainApp running and FilesInUse does not shut it down, then it cannot be 
replaced on the system, so it can't be run.  Is it doing something that 
requires it to be a custom action actually being installed onto the system? I'm 
thinking it can be in the Binary table, depending on why it's being run.

Phil Wilson


-Original Message-
From: little.forest [mailto:little.for...@ymail.com]
Sent: Friday, October 02, 2009 2:43 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How to add FilesInUse support

Hi Phil,


Thanks for you reply.

It's good to know that "2753 is nothing directly related to FilesInUse".

For "It's typically caused by running a custom action referring to a program 
that is not going to be installed.  So it looks like you're asking to run 
MainApp but the one in your setup isn't being installed." - It's true. We do 
have a custom action like this(Does this code look okay?):







As long as the old version wasn't running, the major upgrade worked fine. I 
mean, there wasn't error, the old version was removed, and the new version was 
installed. The custom action run okay as well. But, if the old version was 
running, we did see something different: we see the FilesInUse dialog, we 
shutdown the old version manually, so far so good, we kept it going.. then it 
failed. I noticed the application folder under "Program Files" was not even 
created. Netherless to say, anything new version wasn't installed. So when the 
custom action was triggered, the program can't be found, then error. So in 
here, it seems to me th

Re: [WiX-users] How to add FilesInUse support

[little.forest]

Hi Phil,


I just made another try: I removed the bootload custom action from the code. 
And this time, it works. By saying works, I mean, I had the old version app 
running, installing the new version. I did see FilesInUse dialog, and I 
manually shut down the app. The installation process kept going.. until it was 
finished. Things worked fine.

So it seems the problem links with this bootload custom action. But why 
FilesInUse links with a custom action? I don't get it. 

By the way, here is my code(post it again):


...


...







>From here: 
>http://blogs.technet.com/alexshev/archive/2008/02/21/from-msi-to-wix-part-5-custom-actions.aspx
> 
There are some info:
* If the source file is not already installed on the computer:
* Deferred custom actions of this type must be sequenced after the 
InstallFiles action.
* Non-deferred custom actions of this type must be sequenced after the 
InstallFinalize action.
Is it possible that the deferred/non-deferred things is wrong in my code? Is it 
allowed if we run a custom action which uses the main application with command 
line arguments? Is it possible for us to keep FilesInUse, and also keep our 
bootload custom action? How to resolve it?

FilesInUse and custom action, I still don't understand why these irrelevant 
things could conflict each other and cause error 2753.

Thanks.





From: little.forest 
To: General discussion for Windows Installer XML toolset. 

Sent: Friday, October 2, 2009 4:01:35 PM
Subject: Re: [WiX-users] How to add FilesInUse support

Thanks Phil! I really appreciate your reply and your time.


"If MainApp running and FilesInUse does not shut it down, then it cannot be 
replaced on the system, so it can't be run."
- Correct. This is why we need to put this FilesInUse in. Here are what I 
experienced:
- the old version running
- start running the new version installer
- a few seconds, the FilesInUse dialog showed up
- I manually exit the old version of application
- the new version installation process kept going.. a few seconds, the build 
failed Error 2753
- go to the "Program Files" folder, the application folder wasn't even created.

"Is it doing something that requires it to be a custom action actually being 
installed onto the system? I'm thinking it can be in the Binary table, 
depending on why it's being run."
- Our application is a .NET 3.5 WPF based application. The application is 
written in C#. There is a perform issue. Every time when the application 
startup, it'll take a fair mount of time to start. So the development team came 
up with an idea. The idea is, right after the installation and before the end 
user launching the application, start the "bootloader" by using the main 
application with a command line argument(something like "mainapp.exe 
-bootload"). Note: the main application name is mainapp.exe. If we "real" run 
the application, the same mainapp.exe will be executed. What this "-bootload" 
does is that it will start some services, load some DLL files etc. I'm not sure 
whether this design is good or not. But it does work fine. When the end user 
launch the application, she will feel the application is fast - because 
services and DLLs already loaded. So we need this custom action to start this 
bootloader in installer. Actually, you know, this
bootloader is the same as the main application, but just with an argument. Will 
this cause problem? But why there is no any files installed? The application 
folder not even created? I did schedule this custom action before 
"InstallFinalize" which is almost the end of the installation. I use custom 
action type 18 because the executable(actually it's the main application) is 
installed with the application, and I need to set the command line argument. Is 
this the problem?

So one thing worth noticing, if there is no old version running, everything is 
fine. I'm really puzzled.

Thanks again, Phil.

/Brian




From: "Wilson, Phil" 
To: General discussion for Windows Installer XML toolset. 

Sent: Friday, October 2, 2009 3:07:36 PM
Subject: Re: [WiX-users] How to add FilesInUse support

If MainApp running and FilesInUse does not shut it down, then it cannot be 
replaced on the system, so it can't be run.  Is it doing something that 
requires it to be a custom action actually being installed onto the system? I'm 
thinking it can be in the Binary table, depending on why it's being run. 

Phil Wilson 


-Original Message-
From: little.forest [mailto:little.for...@ymail.com] 
Sent: Friday, October 02, 2009 2:43 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How to add FilesInUse support

Hi Phil,


Thanks for you reply.

It's good to know that "2753 is nothing directly related to FilesInUse". 

For "It's typically caused by running a custom action referring to a program 
that is not going to be installed.  So it looks like you're asking to 

[WiX-users] Feature 'ConfigureIISCompression' referenced in column'InstallExecuteSequence'.'Condition' of row 'SetDoDynamicCompression' is invalid.

[Anand]

HI,

  I'm getting the bellow error while linking with light. Any idea?

error LGHT0204 : ICE79: Feature 'ConfigureIISCompression' referenced in
column'InstallExecuteSequence'.'Condition' of row 'SetDoDynamicCompression'
is invalid.

Following is the code ,

(&ConfigureIISCompression = 1)

Thanks,
Anand
--
Come build with us! The BlackBerry® 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/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Out Of Office Reply

[gary]

Thank you for your message. I am currently out of the office on Holiday with no 
access to e-mail.

I will be returning to work on 12 October.

If you need assistance before then, you may reach Atlas on 0845 867 2845 or 
i...@atlascs.co.uk.

Regards

Gary Howlett

--
Come build with us! The BlackBerry® 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/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How to add FilesInUse support

[little.forest]

Thanks Phil! I really appreciate your reply and your time.


"If MainApp running and FilesInUse does not shut it down, then it cannot be 
replaced on the system, so it can't be run."
- Correct. This is why we need to put this FilesInUse in. Here are what I 
experienced:
- the old version running
- start running the new version installer
- a few seconds, the FilesInUse dialog showed up
- I manually exit the old version of application
- the new version installation process kept going.. a few seconds, the build 
failed Error 2753
- go to the "Program Files" folder, the application folder wasn't even created.

"Is it doing something that requires it to be a custom action actually being 
installed onto the system? I'm thinking it can be in the Binary table, 
depending on why it's being run."
- Our application is a .NET 3.5 WPF based application. The application is 
written in C#. There is a perform issue. Every time when the application 
startup, it'll take a fair mount of time to start. So the development team came 
up with an idea. The idea is, right after the installation and before the end 
user launching the application, start the "bootloader" by using the main 
application with a command line argument(something like "mainapp.exe 
-bootload"). Note: the main application name is mainapp.exe. If we "real" run 
the application, the same mainapp.exe will be executed. What this "-bootload" 
does is that it will start some services, load some DLL files etc. I'm not sure 
whether this design is good or not. But it does work fine. When the end user 
launch the application, she will feel the application is fast - because 
services and DLLs already loaded. So we need this custom action to start this 
bootloader in installer. Actually, you know, this
 bootloader is the same as the main application, but just with an argument. 
Will this cause problem? But why there is no any files installed? The 
application folder not even created? I did schedule this custom action before 
"InstallFinalize" which is almost the end of the installation. I use custom 
action type 18 because the executable(actually it's the main application) is 
installed with the application, and I need to set the command line argument. Is 
this the problem?

So one thing worth noticing, if there is no old version running, everything is 
fine. I'm really puzzled.

Thanks again, Phil.

/Brian




From: "Wilson, Phil" 
To: General discussion for Windows Installer XML toolset. 

Sent: Friday, October 2, 2009 3:07:36 PM
Subject: Re: [WiX-users] How to add FilesInUse support

If MainApp running and FilesInUse does not shut it down, then it cannot be 
replaced on the system, so it can't be run.  Is it doing something that 
requires it to be a custom action actually being installed onto the system? I'm 
thinking it can be in the Binary table, depending on why it's being run. 

Phil Wilson 


-Original Message-
From: little.forest [mailto:little.for...@ymail.com] 
Sent: Friday, October 02, 2009 2:43 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How to add FilesInUse support

Hi Phil,


Thanks for you reply.

It's good to know that "2753 is nothing directly related to FilesInUse". 

For "It's typically caused by running a custom action referring to a program 
that is not going to be installed.  So it looks like you're asking to run 
MainApp but the one in your setup isn't being installed." - It's true. We do 
have a custom action like this(Does this code look okay?):







As long as the old version wasn't running, the major upgrade worked fine. I 
mean, there wasn't error, the old version was removed, and the new version was 
installed. The custom action run okay as well. But, if the old version was 
running, we did see something different: we see the FilesInUse dialog, we 
shutdown the old version manually, so far so good, we kept it going.. then it 
failed. I noticed the application folder under "Program Files" was not even 
created. Netherless to say, anything new version wasn't installed. So when the 
custom action was triggered, the program can't be found, then error. So in 
here, it seems to me that the only difference is whether "the old version is 
running" and further "FilesInUse". 

So for "This can because there's a component or feature state that means it's 
not being installed, or yours isn't being installed because there's already one 
on the system with a higher version." - I doubt if it's about the version 
higher/lower. Because if this is true, then we couldn't explain why the new 
version was installed and run okay while the old version wasn't running. It's 
suppposed to fail even the old version wasn't running, right? 

Again, the only difference is the "old version running". If not running, no 
FilesInUse showing up, things are okay. If running, the FilesInUse part behave 
correctly but nothing will be installed. So I guess this is about FilesInUse. 
But, really

Re: [WiX-users] How to add FilesInUse support

[little.forest]

Just double checked:

The new version of the installer is higher than the old installer; the version 
of the new main application is higher than the old version of the main 
application.

So I think this is not about the version, but I don't know.

Also, can you tell me if my code for FilesInUse correct? I found this: 
http://neilsleightholm.blogspot.com/2008/08/customised-uis-for-wix.html 
There are quite a few other DialogRef listed:
  







Should I do the same thing?

Anyways, if you know anything about FilesInUse, please let me know.

Thanks.
/Brian




From: little.forest 
To: General discussion for Windows Installer XML toolset. 

Sent: Friday, October 2, 2009 2:42:41 PM
Subject: Re: [WiX-users] How to add FilesInUse support

Hi Phil,


Thanks for you reply.

It's good to know that "2753 is nothing directly related to FilesInUse". 

For "It's typically caused by running a custom action referring to a program 
that is not going to be installed.  So it looks like you're asking to run 
MainApp but the one in your setup isn't being installed." - It's true. We do 
have a custom action like this(Does this code look okay?):







As long as the old version wasn't running, the major upgrade worked fine. I 
mean, there wasn't error, the old version was removed, and the new version was 
installed. The custom action run okay as well. But, if the old version was 
running, we did see something different: we see the FilesInUse dialog, we 
shutdown the old version manually, so far so good, we kept it going.. then it 
failed. I noticed the application folder under "Program Files" was not even 
created. Netherless to say, anything new version wasn't installed. So when the 
custom action was triggered, the program can't be found, then error. So in 
here, it seems to me that the only difference is whether "the old version is 
running" and further "FilesInUse". 

So for "This can because there's a component or feature state that means it's 
not being installed, or yours isn't being installed because there's already one 
on the system with a higher version." - I doubt if it's about the version 
higher/lower. Because if this is true, then we couldn't explain why the new 
version was installed and run okay while the old version wasn't running. It's 
suppposed to fail even the old version wasn't running, right? 

Again, the only difference is the "old version running". If not running, no 
FilesInUse showing up, things are okay. If running, the FilesInUse part behave 
correctly but nothing will be installed. So I guess this is about FilesInUse. 
But, really, I don't know the reason and the solution.

By the way, we use WiX version 3.0.4805.0.

If you have any idea, please let me know.

Thanks a lot.

/Brian





From: "Wilson, Phil" 
To: General discussion for Windows Installer XML toolset. 

Sent: Friday, October 2, 2009 1:57:16 PM
Subject: Re: [WiX-users] How to add FilesInUse support

2753 is nothing directly related to FilesInUse - look up the Windows SDK 
Windows Installer errors for this kind of thing.  

It's typically caused by running a custom action referring to a program that is 
not going to be installed.  So it looks like you're asking to run MainApp but 
the one in your setup isn't being installed. This can because there's a 
component or feature state that means it's not being installed, or yours isn't 
being installed because there's already one on the system with a higher 
version. 

Phil Wilson 


-Original Message-
From: little.forest [mailto:little.for...@ymail.com] 
Sent: Friday, October 02, 2009 12:07 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How to add FilesInUse support

Let me correct something a bit:

If not add "" line, the installation is okay but 
it won't detect and show "FilesInUse" dialog.
If add "" line in code, the installation is okay 
if this is a fresh intallation(fresh means no previous version installed). 
If add "" line in code, and there is the old 
version application running, then the installation of the new version will 
detect and show the "FilesInUse" dialog which is good. But later on the 
installation of the new version will be failed because of an Error called 2753. 
Why this happens? How to resolve it?

Thanks.




From: little.forest 
To: wix-users@lists.sourceforge.net
Sent: Friday, October 2, 2009 11:17:01 AM
Subject: [WiX-users] How to add FilesInUse support

We use WiX 3.0.

We have a problem: the end user is running the old version of the application, 
but she tries to install the new version at the same time. As we use major 
upgrade, the old version will be uninstalled first. So in this case, if the old 
version is running, we can't install the new version properly.

I knew "util:CloseApplication". So I tried that. But in our application, there 
is a requirement "close application will just minimize the GUI to syst

Re: [WiX-users] Update adding a new compontent

[Stout, Mike]

I have not seen any additional responses but I have gotten something
working on my own.

The below script is a mock up of what I have put together.  The intent
is that the installer will detect previous versions of the library and
keep those versions in the GAC while adding itself, but if no previous
versions were installed then only the current version should be added.  

The question remains, is there a better way to do this?  To make this
approach work each upgrade is a major upgrade, and I have to maintain an
archive of all release builds so that they can be include in every
version of the MSI.  Is there any easy way of modifying this so that the
behavior is the same from the user perspective but the MSI only contains
the current files?
 
This script is set up to build an installer for v1.0.  If you switch the
product tags and remove the comments around the other blocks then you
have the installer for v1.1.  



























































NOT
FOO100







Mike 

-Original Message-
From: Stout, Mike [mailto:mike.st...@oa.mo.gov] 
Sent: Friday, September 25, 2009 8:31 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Update adding a new compontent

My preference would be to have the new MSI only include the new files,
however we could include older versions if necessary. Ideally the
versions in the GAC would stack up until someone uninstalls them.  If we
could pull it off I would like to have one entry in add remove programs
that gives the option of removing a specific version or completely
removing all of the installed versions.

Correct.  File names and paths for VS support stay the same.

Preference would be to release a single MSI that can be run from
windows.

Mike 

-Original Message-
From: Blair [mailto:os...@live.com] 
Sent: Thursday, September 24, 2009 5:27 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Update adding a new compontent

I assume from the description you don't want to ship the older versions
you
intend to leave behind in newer MSIs, correct? Will those old components
ever be removed? If so, by what mechanism?

The component you update (that is the DLL, Debug, Doc, and Registry,
correct?) keeps its filename and directory, correct?

Are you intending to simply ship the raw MSI file out, or are you
bootstrapping it?

-Original Message-
From: Stout, Mike [mailto:mike.st...@oa.mo.gov] 
Sent: Thursday, September 24, 2009 1:06 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Update adding a new compontent

I am new to writing set up packages in general and I am looking for a
way to have a single file installer that will work as both a clean
install and an update to previous installs.  The catch is that in update
mode I need to change an existing component, add a new component, and
leave a third in place.

 

Example:  We have an installer for a framework library.  One component
drops a copy of the DLL into the GAC.  Another component writes the DLL,
Debug and Documentation files to an install directory and adds a
registry entry telling Visual Studio where to find them.  Now when it is
time to update we want to add the new version to the GAC (new component)
without removing the original version(leave existing component), but
overwrite the files VS uses with the new version (update existing
component).

 

The approach seems to have gotten me closest is to change the ID of the
GAC component with each revision while leaving the ID of the VS
component static. However to get this to work I am also having to change
the product ID which results in each update having its own entry in
add/remove programs.

 

Am I on the right track with this?  Is there a simple way to get this
type of behavior without having to change the product ID?

 

Mike

 

 



--
Come build with us! The BlackBer

Re: [WiX-users] How to add FilesInUse support

[Wilson, Phil]

If MainApp running and FilesInUse does not shut it down, then it cannot be 
replaced on the system, so it can't be run.  Is it doing something that 
requires it to be a custom action actually being installed onto the system? I'm 
thinking it can be in the Binary table, depending on why it's being run. 

Phil Wilson 


-Original Message-
From: little.forest [mailto:little.for...@ymail.com] 
Sent: Friday, October 02, 2009 2:43 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How to add FilesInUse support

Hi Phil,


Thanks for you reply.

It's good to know that "2753 is nothing directly related to FilesInUse". 

For "It's typically caused by running a custom action referring to a program 
that is not going to be installed.  So it looks like you're asking to run 
MainApp but the one in your setup isn't being installed." - It's true. We do 
have a custom action like this(Does this code look okay?):







As long as the old version wasn't running, the major upgrade worked fine. I 
mean, there wasn't error, the old version was removed, and the new version was 
installed. The custom action run okay as well. But, if the old version was 
running, we did see something different: we see the FilesInUse dialog, we 
shutdown the old version manually, so far so good, we kept it going.. then it 
failed. I noticed the application folder under "Program Files" was not even 
created. Netherless to say, anything new version wasn't installed. So when the 
custom action was triggered, the program can't be found, then error. So in 
here, it seems to me that the only difference is whether "the old version is 
running" and further "FilesInUse". 

So for "This can because there's a component or feature state that means it's 
not being installed, or yours isn't being installed because there's already one 
on the system with a higher version." - I doubt if it's about the version 
higher/lower. Because if this is true, then we couldn't explain why the new 
version was installed and run okay while the old version wasn't running. It's 
suppposed to fail even the old version wasn't running, right? 

Again, the only difference is the "old version running". If not running, no 
FilesInUse showing up, things are okay. If running, the FilesInUse part behave 
correctly but nothing will be installed. So I guess this is about FilesInUse. 
But, really, I don't know the reason and the solution.

By the way, we use WiX version 3.0.4805.0.

If you have any idea, please let me know.

Thanks a lot.

/Brian





From: "Wilson, Phil" 
To: General discussion for Windows Installer XML toolset. 

Sent: Friday, October 2, 2009 1:57:16 PM
Subject: Re: [WiX-users] How to add FilesInUse support

2753 is nothing directly related to FilesInUse - look up the Windows SDK 
Windows Installer errors for this kind of thing.  

It's typically caused by running a custom action referring to a program that is 
not going to be installed.  So it looks like you're asking to run MainApp but 
the one in your setup isn't being installed. This can because there's a 
component or feature state that means it's not being installed, or yours isn't 
being installed because there's already one on the system with a higher 
version. 

Phil Wilson 


-Original Message-
From: little.forest [mailto:little.for...@ymail.com] 
Sent: Friday, October 02, 2009 12:07 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How to add FilesInUse support

Let me correct something a bit:

If not add "" line, the installation is okay but 
it won't detect and show "FilesInUse" dialog.
If add "" line in code, the installation is okay 
if this is a fresh intallation(fresh means no previous version installed). 
If add "" line in code, and there is the old 
version application running, then the installation of the new version will 
detect and show the "FilesInUse" dialog which is good. But later on the 
installation of the new version will be failed because of an Error called 2753. 
Why this happens? How to resolve it?

Thanks.




From: little.forest 
To: wix-users@lists.sourceforge.net
Sent: Friday, October 2, 2009 11:17:01 AM
Subject: [WiX-users] How to add FilesInUse support

We use WiX 3.0.

We have a problem: the end user is running the old version of the application, 
but she tries to install the new version at the same time. As we use major 
upgrade, the old version will be uninstalled first. So in this case, if the old 
version is running, we can't install the new version properly.

I knew "util:CloseApplication". So I tried that. But in our application, there 
is a requirement "close application will just minimize the GUI to system tray 
just like Yahoo Messenger". I'm not sure if "util:CloseApplication" does send 
WM_CLOSE message to our application. But even if it does, our application will 
just minimize itself to system tray but not close itself. W

Re: [WiX-users] How to add FilesInUse support

[little.forest]

Hi Phil,


Thanks for you reply.

It's good to know that "2753 is nothing directly related to FilesInUse". 

For "It's typically caused by running a custom action referring to a program 
that is not going to be installed.  So it looks like you're asking to run 
MainApp but the one in your setup isn't being installed." - It's true. We do 
have a custom action like this(Does this code look okay?):







As long as the old version wasn't running, the major upgrade worked fine. I 
mean, there wasn't error, the old version was removed, and the new version was 
installed. The custom action run okay as well. But, if the old version was 
running, we did see something different: we see the FilesInUse dialog, we 
shutdown the old version manually, so far so good, we kept it going.. then it 
failed. I noticed the application folder under "Program Files" was not even 
created. Netherless to say, anything new version wasn't installed. So when the 
custom action was triggered, the program can't be found, then error. So in 
here, it seems to me that the only difference is whether "the old version is 
running" and further "FilesInUse". 

So for "This can because there's a component or feature state that means it's 
not being installed, or yours isn't being installed because there's already one 
on the system with a higher version." - I doubt if it's about the version 
higher/lower. Because if this is true, then we couldn't explain why the new 
version was installed and run okay while the old version wasn't running. It's 
suppposed to fail even the old version wasn't running, right? 

Again, the only difference is the "old version running". If not running, no 
FilesInUse showing up, things are okay. If running, the FilesInUse part behave 
correctly but nothing will be installed. So I guess this is about FilesInUse. 
But, really, I don't know the reason and the solution.

By the way, we use WiX version 3.0.4805.0.

If you have any idea, please let me know.

Thanks a lot.

/Brian





From: "Wilson, Phil" 
To: General discussion for Windows Installer XML toolset. 

Sent: Friday, October 2, 2009 1:57:16 PM
Subject: Re: [WiX-users] How to add FilesInUse support

2753 is nothing directly related to FilesInUse - look up the Windows SDK 
Windows Installer errors for this kind of thing.  

It's typically caused by running a custom action referring to a program that is 
not going to be installed.  So it looks like you're asking to run MainApp but 
the one in your setup isn't being installed. This can because there's a 
component or feature state that means it's not being installed, or yours isn't 
being installed because there's already one on the system with a higher 
version. 

Phil Wilson 


-Original Message-
From: little.forest [mailto:little.for...@ymail.com] 
Sent: Friday, October 02, 2009 12:07 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How to add FilesInUse support

Let me correct something a bit:

If not add "" line, the installation is okay but 
it won't detect and show "FilesInUse" dialog.
If add "" line in code, the installation is okay 
if this is a fresh intallation(fresh means no previous version installed). 
If add "" line in code, and there is the old 
version application running, then the installation of the new version will 
detect and show the "FilesInUse" dialog which is good. But later on the 
installation of the new version will be failed because of an Error called 2753. 
Why this happens? How to resolve it?

Thanks.




From: little.forest 
To: wix-users@lists.sourceforge.net
Sent: Friday, October 2, 2009 11:17:01 AM
Subject: [WiX-users] How to add FilesInUse support

We use WiX 3.0.

We have a problem: the end user is running the old version of the application, 
but she tries to install the new version at the same time. As we use major 
upgrade, the old version will be uninstalled first. So in this case, if the old 
version is running, we can't install the new version properly.

I knew "util:CloseApplication". So I tried that. But in our application, there 
is a requirement "close application will just minimize the GUI to system tray 
just like Yahoo Messenger". I'm not sure if "util:CloseApplication" does send 
WM_CLOSE message to our application. But even if it does, our application will 
just minimize itself to system tray but not close itself. We already tested it. 
The application didn't shut down. So we can't use this "util:CloseApplication".

Then I tried another solution: 
http://n2.nabble.com/Custom-action-sequencing-problem-td709311.html#a709311 
Well, it partly worked. If we keep the old version running, then the process is 
killed when installing the new version. However, just a few seconds later, the 
installation failed because of "Error code 2753". I realized the old version 
was uninstalled, the new version wasn't installed. Also, I was thinking killing 
a process directly mig

Re: [WiX-users] CustomAction Error not displaying...

[Blair]

According to the wix docs, those properties are NotSet if the API errors
out. So, without testing, I would suppose that you would need (for your
error message's condition):

((WIX_DIRECTX_PIXELSHADERVERSION < 200) OR NOT
WIX_DIRECTX_PIXELSHADERVERSION) AND ((WIX_DIRECTX_VERTEXSHADERVERSION < 200)
OR NOT WIX_DIRECTX_VERTEXSHADERVERSION)

Or possibly (more simply, if the values don't really matter):

(NOT WIX_DIRECTX_PIXELSHADERVERSION) AND (NOT
WIX_DIRECTX_VERTEXSHADERVERSION)

-Original Message-
From: Dominique Louis [mailto:dominique.lo...@amxeurope.com] 
Sent: Friday, October 02, 2009 8:03 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] CustomAction Error not displaying...

Hi all,
  I'm trying to detect if certain pixel and vertex shaders are installed
on a machine. I have followed the exampled in the Wix 3.0 help, but I'm
not getting the desired error message.


  






  




  

  

  


  

When I run the above code on a virtual machine, which obviously does not
have the required pixel shader support, the log files says...
Action 14:36:53: WixQueryDirectXCaps. 
Action start 14:36:53: WixQueryDirectXCaps.
WixQueryDirectXCaps:  Error 0x8876086a: GetDeviceCaps call failed
Action ended 14:36:54: WixQueryDirectXCaps. Return value 1.

But My error message is never displayed. 

When I run it on a real machine I correctly get the
WIX_DIRECTX_PIXELSHADERVERSION and WIX_DIRECTX_VERTEXSHADERVERSION
variables set with the right values.

What am I missing/doing wrong?

Thanks,

DOMINIQUE LOUIS | IS DEVELOPER, AMX DIGITAL MEDIA GROUP
AMX UK| 6TH FLOOR SALISBURY HOUSE,| LONDON WALL | LONDON | EC2M 5QQ
www.amx.com
AMX

AMX UK
Auster Road
Clifton Moor
York, North Yorkshire
United Kingdom
YO30 4GD

+44 (0) 1904 343100 office
+44 (0) 1904 343101 fax

AMX South
6th Floor Salisbury House
London Wall
London
United Kingdom
EC2M 5QQ

+44 (0) 2076 529450 office
+44 (0) 8701 991661 fax

AMX Belgium
Boerenkrijglaan, 96a
B-2260
Westerlo
Belgium


+ 32 (0) 1454 2763  office
+ 32 (0) 1454 2766  fax

##
Attention: 
This e-mail message is privileged and confidential. If you are not the 
intended recipient please delete the message and notify the sender. 
Any views or opinions presented are solely those of the author.

This email was scanned and cleared by NetIQ MailMarshal.
##


--
Come build with us! The BlackBerry® 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/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Come build with us! The BlackBerry® 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/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Major Upgrade install - why are files missing?

[Blair]

Schedule RemoveExistingProducts around InstallFinalize instead of
InstallInitialize.

Here is what happens:

Remove-before-install:
File Foo.ext (part of component Foo) cannot be removed because it is in use
during RemoveFiles. Windows Installer adds it to the pending-delete list. It
doesn't move it first because there are no other component instances
referencing it (it hasn't processed the installation yet, since you
scheduled the remove first).
Later, the new file is written over the top of the old file. Since that file
is still in use (presumably), the old one may be moved and the new location
is added to the pending-delete list, and the new file is written in its
place.
Then when you reboot, both files are deleted (since both are in the list).
Windows installer never associated the two files because there were never
two component instances using the same file at the same time.

Remove-after-install (requires following the component rules):
File Foo.exe (part of component Foo) can't be overwritten because it is in
use during InstallFiles. Windows Installer moves it and adds the moved
location to the pending-delete list, then writes the new version of the file
in the place where the old one was.
Later, when RemoveExistingProducts runs, Windows Installer notes that a
component scheduled for removal has another instance and the file is not
touched.
When you reboot, the old file is deleted, and the new one is right where you
want it to be.

The advise to place RemoveExistingProducts early is for those who cannot
afford to follow the component rules rigorously because they are generating
their installation file lists in their builds and they are dealing with
1000's of files. Generally all the rest of us should be able to author our
file lists once, use stable component guids (and/or auto-generated ones),
and place RemoveExistingProducts late (which is more efficient in several
measures).

-Original Message-
From: Scott Palmer [mailto:swpal...@gmail.com] 
Sent: Friday, October 02, 2009 1:33 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Major Upgrade install - why are files missing?

I have determined how to reproduce this problem.When the user runs the
installer it is possible that part of the application is still running.
 That means there are files in use that the RemoveExisting task wants to
remove.  These are then scheduled to be deleted after a reboot.  The problem
is that the same files are needed by the (Major) upgrade. These are all
files from the very same merge module - the merge module used by v1 and v2
is the very same file.
If I refuse to reboot and run my application after the installer terminates,
it works.  If I then reboot, files are missing.

MSI should know that the components from v2 match the components it wanted
to remove from v1 and be smart about scheduling the deletion after a reboot.

How can I solve this?

Scott

On Mon, Sep 21, 2009 at 2:02 PM, Blair  wrote:

> I would be interested in seeing the design of the merge module as well as
> install logs.
>
> With my previous employer we designed and had written much of such a tool
> (integrated into our evolving build system). I have plans to write such a
> tool, if there is interest I could push it up in the list.
>
> -Original Message-
> From: Scott Palmer [mailto:swpal...@gmail.com]
> Sent: Monday, September 21, 2009 6:19 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Major Upgrade install - why are files missing?
>
> Getting back to the original problem.  The files that were missing after
my
> major upgrade install were in a merge module that I created that was the
> same in both products and therefore followed the component rules (since
> there were no changes to the install path or content of any components).
>  Would the incorrect scheduling of the RemoveExistingProducts task affect
> more than just the VC 2005 redistributables?
> It's going to be a tremendous effort to educate all of the people on the
> team about the component rules so they can properly update the WiX code
for
> the installer when they add new files to the project.  There doesn't
appear
> to be any good way to verify that the rules are being followed either.  Is
> there a tool that can compare my .msi files (V1.msi vs. V2.msi) and warn
me
> about possible violations to the component rules?  I would think that
> component guids could be compared between the two msi files and if the
> number of files in a component or the install path has changed detailed
> warnings could be shown.
>
> Thanks for your help,
>
> Scott
>
>
>
> On Sun, Sep 20, 2009 at 11:32 AM, Blair  wrote:
>
> > It isn't that bad. The rules are intended to keep your architecture
> stable
> > from build to build and release to release (which is why you should only
> > (re)generate component guids during builds in limited scenarios, in all
> > other cases you should write once/don't touch except for th

Re: [WiX-users] How to add FilesInUse support

[Wilson, Phil]

2753 is nothing directly related to FilesInUse - look up the Windows SDK 
Windows Installer errors for this kind of thing.  

It's typically caused by running a custom action referring to a program that is 
not going to be installed.  So it looks like you're asking to run MainApp but 
the one in your setup isn't being installed. This can because there's a 
component or feature state that means it's not being installed, or yours isn't 
being installed because there's already one on the system with a higher 
version. 

Phil Wilson 


-Original Message-
From: little.forest [mailto:little.for...@ymail.com] 
Sent: Friday, October 02, 2009 12:07 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How to add FilesInUse support

Let me correct something a bit:

If not add "" line, the installation is okay but 
it won't detect and show "FilesInUse" dialog.
If add "" line in code, the installation is okay 
if this is a fresh intallation(fresh means no previous version installed). 
If add "" line in code, and there is the old 
version application running, then the installation of the new version will 
detect and show the "FilesInUse" dialog which is good. But later on the 
installation of the new version will be failed because of an Error called 2753. 
Why this happens? How to resolve it?

Thanks.




From: little.forest 
To: wix-users@lists.sourceforge.net
Sent: Friday, October 2, 2009 11:17:01 AM
Subject: [WiX-users] How to add FilesInUse support

We use WiX 3.0.

We have a problem: the end user is running the old version of the application, 
but she tries to install the new version at the same time. As we use major 
upgrade, the old version will be uninstalled first. So in this case, if the old 
version is running, we can't install the new version properly.

I knew "util:CloseApplication". So I tried that. But in our application, there 
is a requirement "close application will just minimize the GUI to system tray 
just like Yahoo Messenger". I'm not sure if "util:CloseApplication" does send 
WM_CLOSE message to our application. But even if it does, our application will 
just minimize itself to system tray but not close itself. We already tested it. 
The application didn't shut down. So we can't use this "util:CloseApplication".

Then I tried another solution: 
http://n2.nabble.com/Custom-action-sequencing-problem-td709311.html#a709311 
Well, it partly worked. If we keep the old version running, then the process is 
killed when installing the new version. However, just a few seconds later, the 
installation failed because of "Error code 2753". I realized the old version 
was uninstalled, the new version wasn't installed. Also, I was thinking killing 
a process directly might not be a good thing. So I kept searching other 
solutions.

Then I found someone said "FilesInUse". I think this solution even works for 
us. So I added this line:


...


Now we have new problem "Error code 2753". I tried two cases: 
Case 1: I kept the old version running, and I installed the new version. During 
installation, the "FilesInUse" dialog did show up - I was very happy. Then I 
exited the old version. The installation kept going.. just a few seconds, it 
failed. I noticed the old version was uninstalled, but the new version wasn't 
installed. Here is the log:
MSI (s) (48:4C) [10:15:34:839]: Note: 1: 2753 2: MainApp 
MSI (s) (48:4C) [10:15:34:839]: Note: 1: 2205 2:  3: Error 
MSI (s) (48:4C) [10:15:34:839]: Note: 1: 2228 2:  3: Error 4: SELECT `Message` 
FROM `Error` WHERE `Error` = 2753 
DEBUG: Error 2753:  The File 'MainApp' is not marked for installation.
The installer has encountered an unexpected error installing this package. This 
may indicate a problem with this package. The error code is 2753. The arguments 
are: MainApp, , 
MSI (s) (48:4C) [10:15:44:245]: Note: 1: 2205 2:  3: Error 
MSI (s) (48:4C) [10:15:44:245]: Note: 1: 2228 2:  3: Error 4: SELECT `Message` 
FROM `Error` WHERE `Error` = 1709 
MSI (s) (48:4C) [10:15:44:245]: Product: BigAppleProduct -- The installer has 
encountered an unexpected error installing this package. This may indicate a 
problem with this package. The error code is 2753. The arguments are: MainApp, 
, 
The log says error, but what the error means? What caused this error? The log 
didn't say.

Case 2: do a fresh installation. There is no "FilesInUse" dialog showing up, of 
course. But the install still failed - Error 2753. This doesn't make any sense. 

It seems the problem is this new added line "". By 
adding this line, the error 2753 is introduced. Why is that? So how can I add 
this FilesInUse support in WiX 3? Where I did wrong here? 

Many many thanks.
/Brian


  __
Looking for the perfect gift? Give the gift of Flickr! 

http://www.flickr.com/gift/
--
Come build with us! The

[WiX-users] CustomAction Error not displaying...

[Dominique Louis]

Hi all,
  I'm trying to detect if certain pixel and vertex shaders are installed
on a machine. I have followed the exampled in the Wix 3.0 help, but I'm
not getting the desired error message.


  






  




  

  

  


  

When I run the above code on a virtual machine, which obviously does not
have the required pixel shader support, the log files says...
Action 14:36:53: WixQueryDirectXCaps. 
Action start 14:36:53: WixQueryDirectXCaps.
WixQueryDirectXCaps:  Error 0x8876086a: GetDeviceCaps call failed
Action ended 14:36:54: WixQueryDirectXCaps. Return value 1.

But My error message is never displayed. 

When I run it on a real machine I correctly get the
WIX_DIRECTX_PIXELSHADERVERSION and WIX_DIRECTX_VERTEXSHADERVERSION
variables set with the right values.

What am I missing/doing wrong?

Thanks,

DOMINIQUE LOUIS | IS DEVELOPER, AMX DIGITAL MEDIA GROUP
AMX UK| 6TH FLOOR SALISBURY HOUSE,| LONDON WALL | LONDON | EC2M 5QQ
www.amx.com
AMX

AMX UK
Auster Road
Clifton Moor
York, North Yorkshire
United Kingdom
YO30 4GD

+44 (0) 1904 343100 office
+44 (0) 1904 343101 fax

AMX South
6th Floor Salisbury House
London Wall
London
United Kingdom
EC2M 5QQ

+44 (0) 2076 529450 office
+44 (0) 8701 991661 fax

AMX Belgium
Boerenkrijglaan, 96a
B-2260
Westerlo
Belgium


+ 32 (0) 1454 2763  office
+ 32 (0) 1454 2766  fax

##
Attention: 
This e-mail message is privileged and confidential. If you are not the 
intended recipient please delete the message and notify the sender. 
Any views or opinions presented are solely those of the author.

This email was scanned and cleared by NetIQ MailMarshal.
##

--
Come build with us! The BlackBerry® 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/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Major Upgrade install - why are files missing?

[Scott Palmer]

I have determined how to reproduce this problem.When the user runs the
installer it is possible that part of the application is still running.
 That means there are files in use that the RemoveExisting task wants to
remove.  These are then scheduled to be deleted after a reboot.  The problem
is that the same files are needed by the (Major) upgrade. These are all
files from the very same merge module - the merge module used by v1 and v2
is the very same file.
If I refuse to reboot and run my application after the installer terminates,
it works.  If I then reboot, files are missing.

MSI should know that the components from v2 match the components it wanted
to remove from v1 and be smart about scheduling the deletion after a reboot.

How can I solve this?

Scott

On Mon, Sep 21, 2009 at 2:02 PM, Blair  wrote:

> I would be interested in seeing the design of the merge module as well as
> install logs.
>
> With my previous employer we designed and had written much of such a tool
> (integrated into our evolving build system). I have plans to write such a
> tool, if there is interest I could push it up in the list.
>
> -Original Message-
> From: Scott Palmer [mailto:swpal...@gmail.com]
> Sent: Monday, September 21, 2009 6:19 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Major Upgrade install - why are files missing?
>
> Getting back to the original problem.  The files that were missing after my
> major upgrade install were in a merge module that I created that was the
> same in both products and therefore followed the component rules (since
> there were no changes to the install path or content of any components).
>  Would the incorrect scheduling of the RemoveExistingProducts task affect
> more than just the VC 2005 redistributables?
> It's going to be a tremendous effort to educate all of the people on the
> team about the component rules so they can properly update the WiX code for
> the installer when they add new files to the project.  There doesn't appear
> to be any good way to verify that the rules are being followed either.  Is
> there a tool that can compare my .msi files (V1.msi vs. V2.msi) and warn me
> about possible violations to the component rules?  I would think that
> component guids could be compared between the two msi files and if the
> number of files in a component or the install path has changed detailed
> warnings could be shown.
>
> Thanks for your help,
>
> Scott
>
>
>
> On Sun, Sep 20, 2009 at 11:32 AM, Blair  wrote:
>
> > It isn't that bad. The rules are intended to keep your architecture
> stable
> > from build to build and release to release (which is why you should only
> > (re)generate component guids during builds in limited scenarios, in all
> > other cases you should write once/don't touch except for the few changes
> > that really exist). The problem with breaking the component rules lies in
> > two basic assumptions on the part of Windows Installer: 1) a component is
> > an
> > atomic unit of installation (all or nothing always), and 2) there is a
> > one-to-one relationship between a component's guid (it's "unique" name)
> and
> > it's "physical state" (the keypath's presence and other identifying marks
> > such as version).
> >
> > Regarding component keypaths: you already do have a defined keypath
> > hierarchy. Even though you allow the user to override the paths for
> > specific
> > nodes in your directory tree, pretend as though those overrides don't
> exist
> > and you will be fine as long as, for any given filename of a keypath, if
> > you
> > don't change its position in your non-overridden directory tree (and you
> > didn't rename the nodes in that section of your directory tree) you
> > basically just need to keep the guids stable. If you do change the
> > directory
> > the file is in and/or the filename, you will generally need to change the
> > guid for that component. There is some "forgiveness" for file-based
> > non-fusion keypaths: the keypaths are stored per-product for those
> > components, so if you install a "shared" component between two different
> > programs (even if one is an upgrade from the other) that part of the
> > component will be treated correctly.
> >
> > Yes, you may find that already released versions of your installer didn't
> > follow the rules the way you wish they had. If you don't change the
> > composition your components, those components who's directory
> > hierarchy/filename don't change should be left alone (keep things
> stable).
> > That should limit the trouble spots to those that files that are
> > changing/swapping resources around. Cleanup your old violations during a
> > time period when you don't have much churn in your inputs to your
> packages.
> > Go in stages on that cleanup (not all at once, generally).
> >
> > Yes, there are times when the rules will put you into a difficult place:
> > one
> > example is combining two COM files into one (and not changing the
> > CL

Re: [WiX-users] How to find the installed path for update

[Stout, Mike]

The way I accomplished this was to store the install path in the
registry and then do a registry search to find out where the previous
version was installed.  I believe the same thing could be accomplished
with a file search.















Mike 

-Original Message-
From: Jiang, Chunyan (GE Healthcare) [mailto:chunyan.ji...@ge.com] 
Sent: Friday, October 02, 2009 8:26 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] How to find the installed path for update

Hi Wix-users,
 
I have developed a wix installer. It is an updatable installation
package. For the path, I set the default path as 
 




 

It will show "D:\ViewPoint6" as the default in InstallDirDlg.wxs:





 

However, if I installed the software in the other path, like
d:\testinatll for the first time. When there is new version avalable, I
want to update it. The InstallDirDlg still shows the path as
"D:\ViewPoint6", instead of "d:\testinatll".

How can I get the path for the update installation and set it to
InstallDirDlg? Probably, I need to have to dialogs, one for new
installation, defaut path is "D:\ViewPoint6", the other one is update
dialog, the path should be set as installed path.

 

Best regards

Chunyan


--
Come build with us! The BlackBerry® 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/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Come build with us! The BlackBerry® 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/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Building wixproj with MSBuild, preprocessor variable undefined

[Blair]

Not sure. Looks to me like it should work. Which build of the toolset are
you using?

Another option that may work is DefineConstants (drop the "-d" prefix):

AdapterFolder=E:\projects\Adapter

-Original Message-
From: Chris Buchanan [mailto:bucktro...@googlemail.com] 
Sent: Friday, October 02, 2009 8:34 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Building wixproj with MSBuild, preprocessor variable
undefined

Hi there,

I'm having some problems trying to build a WIX project from another
application using Microsoft.Build.BuildEngine.Project.

The WIX project builds fine from within Visual Studio and produces my msi.

If I look into my .wixproj file, I can see the CompilerAdditionalOptions and
the preprocessor variables I've defined:


-dAdapterFolder=E:\projects\Adapter

However the build fails with:  "Undefined preprocessor variable
$(var.AdapterFolder)".

If I look at the call to Candle in my build log, the AdapterFolder variable
isn't being passed:

C:\Program Files\Windows Installer XML v3\bin\candle.exe
-d"DevEnvDir=*Undefined if not building from within Visual Studio*"
-dSolutionDir=E:\Projects\Installer\ -dSolutionExt=.sln
-dSolutionFileName=Installer.sln -dSolutionName=Installer
-dSolutionPath=E:\Projects\Installer\Installer.sln -dConfiguration=Release
-dOutDir=bin\Release\ -dPlatform=x86 -dProjectDir=E:\Projects\Installer\
-dProjectExt=.wixproj -dProjectFileName=Installer.wixproj
-dProjectName=Installer
-dProjectPath=E:\Projects\Installer\Installer.wixproj
-dTargetDir=E:\Projects\Installer\bin\Release\ -dTargetExt=.msi
-d"TargetFileName=Product v2.0.msi" -d"TargetName=Product v2.0"
-d"TargetPath=E:\Projects\Installer\bin\Release\Product v2.0.msi" -out
obj\Release\Adapter.wixobj -arch x86 -ext "C:\Program Files\Windows
Installer XML v3\bin\WixNetFxExtension.dll" -ext "C:\Program Files\Windows
Installer XML v3\bin\WixUtilExtension.dll" -ext "C:\Program Files\Windows
Installer XML v3\bin\WixUIExtension.dll" -ext "C:\Program Files\Windows
Installer XML v3\bin\WixIIsExtension.dll" Adapter.wxs


Does anyone know how to pass the compiler additional options to Candle? Or
have I missed something else?

Thanks,
Chris.

--
Come build with us! The BlackBerry® 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/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Come build with us! The BlackBerry® 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/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How to add FilesInUse support

[little.forest]

Let me correct something a bit:

If not add "" line, the installation is okay but 
it won't detect and show "FilesInUse" dialog.
If add "" line in code, the installation is okay 
if this is a fresh intallation(fresh means no previous version installed). 
If add "" line in code, and there is the old 
version application running, then the installation of the new version will 
detect and show the "FilesInUse" dialog which is good. But later on the 
installation of the new version will be failed because of an Error called 2753. 
Why this happens? How to resolve it?

Thanks.




From: little.forest 
To: wix-users@lists.sourceforge.net
Sent: Friday, October 2, 2009 11:17:01 AM
Subject: [WiX-users] How to add FilesInUse support

We use WiX 3.0.

We have a problem: the end user is running the old version of the application, 
but she tries to install the new version at the same time. As we use major 
upgrade, the old version will be uninstalled first. So in this case, if the old 
version is running, we can't install the new version properly.

I knew "util:CloseApplication". So I tried that. But in our application, there 
is a requirement "close application will just minimize the GUI to system tray 
just like Yahoo Messenger". I'm not sure if "util:CloseApplication" does send 
WM_CLOSE message to our application. But even if it does, our application will 
just minimize itself to system tray but not close itself. We already tested it. 
The application didn't shut down. So we can't use this "util:CloseApplication".

Then I tried another solution: 
http://n2.nabble.com/Custom-action-sequencing-problem-td709311.html#a709311 
Well, it partly worked. If we keep the old version running, then the process is 
killed when installing the new version. However, just a few seconds later, the 
installation failed because of "Error code 2753". I realized the old version 
was uninstalled, the new version wasn't installed. Also, I was thinking killing 
a process directly might not be a good thing. So I kept searching other 
solutions.

Then I found someone said "FilesInUse". I think this solution even works for 
us. So I added this line:


...


Now we have new problem "Error code 2753". I tried two cases: 
Case 1: I kept the old version running, and I installed the new version. During 
installation, the "FilesInUse" dialog did show up - I was very happy. Then I 
exited the old version. The installation kept going.. just a few seconds, it 
failed. I noticed the old version was uninstalled, but the new version wasn't 
installed. Here is the log:
MSI (s) (48:4C) [10:15:34:839]: Note: 1: 2753 2: MainApp 
MSI (s) (48:4C) [10:15:34:839]: Note: 1: 2205 2:  3: Error 
MSI (s) (48:4C) [10:15:34:839]: Note: 1: 2228 2:  3: Error 4: SELECT `Message` 
FROM `Error` WHERE `Error` = 2753 
DEBUG: Error 2753:  The File 'MainApp' is not marked for installation.
The installer has encountered an unexpected error installing this package. This 
may indicate a problem with this package. The error code is 2753. The arguments 
are: MainApp, , 
MSI (s) (48:4C) [10:15:44:245]: Note: 1: 2205 2:  3: Error 
MSI (s) (48:4C) [10:15:44:245]: Note: 1: 2228 2:  3: Error 4: SELECT `Message` 
FROM `Error` WHERE `Error` = 1709 
MSI (s) (48:4C) [10:15:44:245]: Product: BigAppleProduct -- The installer has 
encountered an unexpected error installing this package. This may indicate a 
problem with this package. The error code is 2753. The arguments are: MainApp, 
, 
The log says error, but what the error means? What caused this error? The log 
didn't say.

Case 2: do a fresh installation. There is no "FilesInUse" dialog showing up, of 
course. But the install still failed - Error 2753. This doesn't make any sense. 

It seems the problem is this new added line "". By 
adding this line, the error 2753 is introduced. Why is that? So how can I add 
this FilesInUse support in WiX 3? Where I did wrong here? 

Many many thanks.
/Brian


  __
Looking for the perfect gift? Give the gift of Flickr! 

http://www.flickr.com/gift/
--
Come build with us! The BlackBerry® 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/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



  __
The new Internet Explorer® 8 - Faster, safer, easier.  Optimized for Yahoo!  
Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/
--
Come build with us! Th

Re: [WiX-users] CustomAction : Enumerating SQLServer Instancesacrossthe network using SQLDMO

[Slide]

Dominique,

I was the one that registered WiXRepo on CodePlex, so I guess I should
answer these questions :-)

I think your idea of grouping is a good one, I like the per-language
approach.

I'm still trying to figure out the best way for people to submit items to
the repo, I think the original suggestion was for people to submit them as
patches and then I will do the work of categorizing them and putting them
into "releases" and so forth.

Thanks!

slide

On Fri, Oct 2, 2009 at 6:22 AM, Dominique Louis <
dominique.lo...@amxeurope.com> wrote:

> Hi Thomas,
>  Great to see the WiXRepo is up and running so quickly.
>
> I'm not sure how organized you can make things on codeplex, as I've
> never used it, but maybe CustomActions could be grouped per programming
> language. So a sub-dir for VB Script and another for C/C++ and C# etc.
>
> How can developers submit things to the project? Do you have to register
> to be able to be part of the project?
>
> A more portable solution to this SQLDMO code below would be to use SMO,
> as that is supported on SQLServer 2005 and 2008, but VB Script cannot
> call static methods, so it seems only a C/C+/C# etc solution would work
> for that.
>
> Dominique.
>
> -Original Message-
> From: Thomas Due [mailto:thomas@scanvaegt.dk]
> Sent: 02 October 2009 06:47
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] CustomAction : Enumerating SQLServer
> Instancesacrossthe network using SQLDMO
>
> This would be perfect for http://wixrepo.codeplex.com/
>
> Also: Looks good, looking forward to playing around with it, although
> the company I work for, will have to support 2008 as well in the near
> future.
>
> /Thomas
>
> -Original Message-
> From: Dominique Louis [mailto:dominique.lo...@amxeurope.com]
> Sent: 1. oktober 2009 18:16
> To: General discussion for Windows Installer XML toolset.
> Subject: [WiX-users] CustomAction : Enumerating SQLServer Instances
> acrossthe network using SQLDMO
>
> Hi all,
>  I couldn't find all this code in one place so I thought this list
> might be a good place to archive it.
>
>
>  Set sqlApp = CreateObject("SQLDMO.Application")
>
>  If ( Err.Number <> 0 ) Then
>  wscript.echo "SQLDMO.Application Not found. Error : " &
> Err.Number
>  wscript.Quit -1
>  End If
>
>  Set sqlServer2 = CreateObject("SQLDMO.SQLServer2")
>
>  If ( Err.Number <> 0 ) Then
>  wscript.echo "SQLDMO.SQLServer2 Not found. Error : " &
> Err.Number
>  wscript.Quit -1
>  End If
>
>  Set serverList = sqlApp.ListAvailableSQLServers
>
>  numServers = serverList.Count
>
>  Dim x, y
>
>  For x = 1 To numServers
>
>Set instanceList = sqlServer2.ListInstalledInstances(
> serverList(x) )
>
>if Not ( instanceList is Nothing ) Then
>
>  numInstances = instanceList.Count
>
>  wscript.echo serverList(x)
>  For y = 1 To numInstances
>wscript.echo "" & instanceList(y)
>  Next
>End IF
>  Next
>
>  Set sqlServer2 = Nothing
>  Set sqlApp = Nothing
>
>
> Note SQLDMO only works with SQLServer 2005 and below and is not
> installed by default on SQLServer 2008 onwards
>
>
> Hope this helps someone.
>
>
> DOMINIQUE LOUIS | IS DEVELOPER, AMX DIGITAL MEDIA GROUP
> AMX UK| 6TH FLOOR SALISBURY HOUSE,| LONDON WALL | LONDON | EC2M 5QQ
> www.amx.com
> AMX
>
> AMX UK
> Auster Road
> Clifton Moor
> York, North Yorkshire
> United Kingdom
> YO30 4GD
>
> +44 (0) 1904 343100 office
> +44 (0) 1904 343101 fax
>
> AMX South
> 6th Floor Salisbury House
> London Wall
> London
> United Kingdom
> EC2M 5QQ
>
> +44 (0) 2076 529450 office
> +44 (0) 8701 991661 fax
>
> AMX Belgium
> Boerenkrijglaan, 96a
> B-2260
> Westerlo
> Belgium
>
>
> + 32 (0) 1454 2763  office
> + 32 (0) 1454 2766  fax
>
> ##
> Attention:
> This e-mail message is privileged and confidential. If you are not the
> intended recipient please delete the message and notify the sender.
> Any views or opinions presented are solely those of the author.
>
> This email was scanned and cleared by NetIQ MailMarshal.
> ##
>
>
> --
> Come build with us! The BlackBerry® 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/devconf
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>



-- 
slide-o-blog
http://slide-o-blog.blogspo

[WiX-users] How to add FilesInUse support

[little.forest]

We use WiX 3.0.

We have a problem: the end user is running the old version of the application, 
but she tries to install the new version at the same time. As we use major 
upgrade, the old version will be uninstalled first. So in this case, if the old 
version is running, we can't install the new version properly.

I knew "util:CloseApplication". So I tried that. But in our application, there 
is a requirement "close application will just minimize the GUI to system tray 
just like Yahoo Messenger". I'm not sure if "util:CloseApplication" does send 
WM_CLOSE message to our application. But even if it does, our application will 
just minimize itself to system tray but not close itself. We already tested it. 
The application didn't shut down. So we can't use this "util:CloseApplication".

Then I tried another solution: 
http://n2.nabble.com/Custom-action-sequencing-problem-td709311.html#a709311 
Well, it partly worked. If we keep the old version running, then the process is 
killed when installing the new version. However, just a few seconds later, the 
installation failed because of "Error code 2753". I realized the old version 
was uninstalled, the new version wasn't installed. Also, I was thinking killing 
a process directly might not be a good thing. So I kept searching other 
solutions.

Then I found someone said "FilesInUse". I think this solution even works for 
us. So I added this line:


...


Now we have new problem "Error code 2753". I tried two cases: 
Case 1: I kept the old version running, and I installed the new version. During 
installation, the "FilesInUse" dialog did show up - I was very happy. Then I 
exited the old version. The installation kept going.. just a few seconds, it 
failed. I noticed the old version was uninstalled, but the new version wasn't 
installed. Here is the log:
MSI (s) (48:4C) [10:15:34:839]: Note: 1: 2753 2: MainApp 
MSI (s) (48:4C) [10:15:34:839]: Note: 1: 2205 2:  3: Error 
MSI (s) (48:4C) [10:15:34:839]: Note: 1: 2228 2:  3: Error 4: SELECT `Message` 
FROM `Error` WHERE `Error` = 2753 
DEBUG: Error 2753:  The File 'MainApp' is not marked for installation.
The installer has encountered an unexpected error installing this package. This 
may indicate a problem with this package. The error code is 2753. The arguments 
are: MainApp, , 
MSI (s) (48:4C) [10:15:44:245]: Note: 1: 2205 2:  3: Error 
MSI (s) (48:4C) [10:15:44:245]: Note: 1: 2228 2:  3: Error 4: SELECT `Message` 
FROM `Error` WHERE `Error` = 1709 
MSI (s) (48:4C) [10:15:44:245]: Product: BigAppleProduct -- The installer has 
encountered an unexpected error installing this package. This may indicate a 
problem with this package. The error code is 2753. The arguments are: MainApp, 
, 
The log says error, but what the error means? What caused this error? The log 
didn't say.

Case 2: do a fresh installation. There is no "FilesInUse" dialog showing up, of 
course. But the install still failed - Error 2753. This doesn't make any sense. 

It seems the problem is this new added line "". By 
adding this line, the error 2753 is introduced. Why is that? So how can I add 
this FilesInUse support in WiX 3? Where I did wrong here? 

Many many thanks.
/Brian


  __
Looking for the perfect gift? Give the gift of Flickr! 

http://www.flickr.com/gift/
--
Come build with us! The BlackBerry® 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/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Building wixproj with MSBuild, preprocessor variable undefined

[Chris Buchanan]

Hi there,

I'm having some problems trying to build a WIX project from another
application using Microsoft.Build.BuildEngine.Project.

The WIX project builds fine from within Visual Studio and produces my msi.

If I look into my .wixproj file, I can see the CompilerAdditionalOptions and
the preprocessor variables I've defined:


-dAdapterFolder=E:\projects\Adapter

However the build fails with:  "Undefined preprocessor variable
$(var.AdapterFolder)".

If I look at the call to Candle in my build log, the AdapterFolder variable
isn't being passed:

C:\Program Files\Windows Installer XML v3\bin\candle.exe
-d"DevEnvDir=*Undefined if not building from within Visual Studio*"
-dSolutionDir=E:\Projects\Installer\ -dSolutionExt=.sln
-dSolutionFileName=Installer.sln -dSolutionName=Installer
-dSolutionPath=E:\Projects\Installer\Installer.sln -dConfiguration=Release
-dOutDir=bin\Release\ -dPlatform=x86 -dProjectDir=E:\Projects\Installer\
-dProjectExt=.wixproj -dProjectFileName=Installer.wixproj
-dProjectName=Installer
-dProjectPath=E:\Projects\Installer\Installer.wixproj
-dTargetDir=E:\Projects\Installer\bin\Release\ -dTargetExt=.msi
-d"TargetFileName=Product v2.0.msi" -d"TargetName=Product v2.0"
-d"TargetPath=E:\Projects\Installer\bin\Release\Product v2.0.msi" -out
obj\Release\Adapter.wixobj -arch x86 -ext "C:\Program Files\Windows
Installer XML v3\bin\WixNetFxExtension.dll" -ext "C:\Program Files\Windows
Installer XML v3\bin\WixUtilExtension.dll" -ext "C:\Program Files\Windows
Installer XML v3\bin\WixUIExtension.dll" -ext "C:\Program Files\Windows
Installer XML v3\bin\WixIIsExtension.dll" Adapter.wxs


Does anyone know how to pass the compiler additional options to Candle? Or
have I missed something else?

Thanks,
Chris.
--
Come build with us! The BlackBerry® 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/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] remove website on uninstall

[Scharp, Craig]

Hi wix users,

Here's a summary of what I've found about uninstall and removing
websites:

Assuming all is setup correctly with components and such, the
uninstaller removes the website for whatever value WebsitePort property
is set to.  For example, if you have your website on the same port as
WebsitePort property in wix file, all works fine.  But, if you have
default website on port 80 and WebsitePort property is set to 80, but
create another website on another port (say port 81) using the wix
installer.  Then, when you uninstall, the default website will be
removed instead.  This is because default value of WebsitePort is 80 so
that's the what will be removed.

Here's another post that suggests storing the port in registry and
reading that on uninstall.  
http://n2.nabble.com/Default-website-gets-removed-on-Uninstall-td731259.
html

I'm going this route for now, but if anyone has any other ideas or
suggestions, or knows if this is a known bug, I'm all ears.  I'm using
wix 3.0.5217.0, but have seen posts with the same issues running
3.0.5419.0. But, I will also give that a try.

Thx, Craig


-Original Message-
From: Chad Petersen [mailto:chad.peter...@harlandfs.com] 
Sent: Tuesday, September 22, 2009 5:31 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] remove website on uninstall

How about having it write a verbose log during the uninstall and then
look to see if it indicates in the log why it likes that Component so
much? It's helped me over similar hurdles in the past.

-Original Message-
From: Scharp, Craig [mailto:craig.sch...@zytax.com] 
Sent: Tuesday, September 22, 2009 3:25 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] remove website on uninstall

Hi Dominique,

Thanks for the feedback!  I think I already have it in a component (see
snippet below).  Please let me know if this is what you mean, or if you
have any other suggestions.

Thanks in advance for any ideas or suggestions!


  

  
  
  

  
  
  


TARGETMODE = "NewWebsite" AND SCRIPTLANGUAGE =
"ASP"
  
  

  
  



  

TARGETMODE = "ExistingWebsite" AND SCRIPTLANGUAGE =
"ASP"

  

-Original Message-
From: Dominique Louis [mailto:dominique.lo...@amxeurope.com] 
Sent: Tuesday, September 22, 2009 4:53 PM
To: General discussion for Windows Installer XML toolset.;
WiX-users@lists.sourceforge.net
Subject: Re: [WiX-users] remove website on uninstall

If you move the WebSite declaration inside a Component it should delete
it on uninstall.

Be aware though that if your WebSite somehow maps to "Default Web Site"
then it will delete that as well.


Dominique.


-Original Message-
From: Scharp, Craig [mailto:craig.sch...@zytax.com]
Sent: Tue 9/22/2009 7:49 PM
To: WiX-users@lists.sourceforge.net
Subject: [WiX-users] remove website on uninstall
 
Hi,

 

I created an msi install for website and database using wix 3.0.5217.0.
All works great for install.  But, I'm having trouble trying to figure
out how to delete the website on uninstall.  Has anyone done that?  If
so, any suggestions would be greatly appreciated.

 

Thanks, Craig


--
Come build with us! The BlackBerry® 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/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


AMX

AMX UK
Auster Road
Clifton Moor
York, North Yorkshire
United Kingdom
YO30 4GD

+44 (0) 1904 343100 office
+44 (0) 1904 343101 fax

AMX South
6th Floor Salisbury House
London Wall
London
United Kingdom
EC2M 5QQ

+44 (0) 2076 529450 office
+44 (0) 8701 991661 fax

AMX Belgium
Boerenkrijglaan, 96a
B-2260
Westerlo
Belgium


+ 32 (0) 1454 2763  office
+ 32 (0) 1454 2766  fax

##
Attention: 
This e-mail message is privileged and confidential. If you are not the 
intended recipient please delete the message and notify the sender. 
Any views or opinions presented are solely those of the author.

This email was scanned and cleared by NetIQ MailMarshal.
##

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications

Re: [WiX-users] Modular install configurations based on availablefiles

[Brian Rogers]

Hey Nick,

The Burn project is on its way. It would be the solution for the needs you
listed below. The RTM of v1 is schedule for early next year. Depending on
your schedule that may or may not work for you. There will be working drops
before then. Depending on the level of risk you are willing to take you
could work prototype with earlier code.

Hope that helps,

Brian Rogers
"Intelligence removes complexity." - Me
http://blogs.msdn.com/icumove <-- NEW


On Fri, Oct 2, 2009 at 5:46 AM, Nick Ball wrote:

> Brian,
>
> Thanks, I was thinking something along these lines for the future. At
> the moment a simpler request, perhaps. How can I chain two
> installations? For example, most of the time I ship my app and a
> database. If the installers are separate, I would like to install the
> app first, then the database. Of course, I also need .Net, and hence am
> using the bootstrapper in VS via Wix which is perhaps an added
> complication. Any suggestions? This would be a step in the right
> direction for the full modular system.
>
> Cheers,
>
> Nick
>
> -Original Message-
> From: Brian Rogers [mailto:rogers.br...@gmail.com]
> Sent: 30 September 2009 18:32
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Modular install configurations based on
> availablefiles
>
> Hey Nick,
>
> I would look at Burn to help you accomplish some of your goals. You
> could
> make an individual MSI for each database you are shipping. Compile those
> individual MSIs into Burn and then use the search features of Burn to
> determine which databases have already been installed via MSI searches
> and
> choose which to install later. Each MSI would have business logic for
> how to
> install the database. This would help you keep things modular in the
> long
> run. It would also help you with patching and upgrade support. Databases
> are, IMHO, one of the hardest installs to upgrade through MSI (good
> luck).
>
> The cab file approach wouldn't be an MSI/WiX approach in the long run.
>
> Hope that helps,
>
> Brian Rogers
> "Intelligence removes complexity." - Me
> http://blogs.msdn.com/icumove <-- NEW
>
>
> On Wed, Sep 30, 2009 at 9:00 AM, Nick Ball
> wrote:
>
> > Hi All,
> >
> >
> >
> > I have a product that ships with several different databases - or
> > combinations thereof. I would like my installer to show all available
> > databases as features that the user can install - and those that
> didn't
> > get shipped should be greyed out.
> >
> >
> >
> > I'm thinking of one main setup program and each database stored as a
> > feature in separate cab files. I can either then look on the source
> disk
> > for each cab file in turn, or write a small XML file (like office
> seems
> > to do) describing the components and where they are. At the moment,
> I'd
> > like to do everything in WiX.
> >
> >
> >
> > A couple of questions.
> >
> >
> >
> > 1.   Is it easy to look for named cab files? If so how? What are
> the
> > problems with this approach (I'm thinking that a repair would need the
> > source disk for this to work).
> >
> > 2.   If the config was stored in an XML file instead of searching
> > for CABS, how would this get round the repair problem?
> >
> >
> >
> > Any other suggestions that would help me create a modular installation
> > welcome.
> >
> >
> >
> > Regards
> >
> >
> >
> > Nick
> >
> >
> >
> >
> >
> 
> --
> > Come build with us! The BlackBerry® 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/devconf
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
>
>
>
> --
> Come build with us! The BlackBerry® 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/devconf
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
--
Come build with us! The BlackBerry® 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/devconf
___

Re: [WiX-users] How to find the installed path for update

[Wilson, Phil]

If "updatable installation" is referring to the fact that you'll be doing a 
major upgrade with Upgrade elements, why do you need this? An upgrade is a new 
install that users can install to whatever path they want.  It so happens that 
an upgrade can also remove prior versions, but it seems unusual to imply that 
an upgrade needs to go into exactly the same location as the previous product. 

Phil Wilson 

-Original Message-
From: Jiang, Chunyan (GE Healthcare) [mailto:chunyan.ji...@ge.com] 
Sent: Friday, October 02, 2009 6:26 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] How to find the installed path for update

Hi Wix-users,
 
I have developed a wix installer. It is an updatable installation
package. For the path, I set the default path as 
 




 

It will show "D:\ViewPoint6" as the default in InstallDirDlg.wxs:





 

However, if I installed the software in the other path, like
d:\testinatll for the first time. When there is new version avalable, I
want to update it. The InstallDirDlg still shows the path as
"D:\ViewPoint6", instead of "d:\testinatll".

How can I get the path for the update installation and set it to
InstallDirDlg? Probably, I need to have to dialogs, one for new
installation, defaut path is "D:\ViewPoint6", the other one is update
dialog, the path should be set as installed path.

 

Best regards

Chunyan

--
Come build with us! The BlackBerry® 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/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
Come build with us! The BlackBerry® 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/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Problem with storing checkbox state

[Blair]

Amend that. Remove the Value="1" part, not replace the entire line.

-Original Message-
From: Blair [mailto:os...@live.com] 
Sent: Friday, October 02, 2009 6:35 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Problem with storing checkbox state

Remove the "" line.

Add:




NOT
Installed AND NOT OLDERVERSIONDETECTED


NOT
Installed AND NOT OLDERVERSIONDETECTED


What this will do is keep ADDITIONAL_PARAMS as a secure property, but it
won't get a "default" value unless this is a new installation (or major
upgrade). Change OLDERVERSIONDETECTED to be whatever you have in your
Upgrade table for removing older versions.

-Original Message-
From: Igor Lemsky [mailto:igor.lem...@gmail.com] 
Sent: Friday, October 02, 2009 1:11 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Problem with storing checkbox state

In my installer I have checkbox "Add also addiotional parameters" with
property ADDITIONAL_PARAMS. Its value "1" if checkbox is checked, and no
value if unchecked.
Worked perfectly, but there are problems. I store property to the registry,
and use regsearch to restore it during upgrade or reinstall.

.


  


Problem if checkbox was unchecked during first installation. In registry we
see key value of Software\Company\Installation\ADDITIONAL_PARAMS is null. It
is ok: the property value in installer is also null and it is right.
But during reinstall the checkbox become checked! Installer ignored that
ADDITIONAL_PARAMS = null! May be it looks into registry, find no value and
set default value from Property Value attribute?
if I delete this attribute (   ) then it correctly restored checkbox value (property value)
from registry, but then during first install this checkbox become unchecked
for default! But I need it to be checked for default. What can I do?

--
Come build with us! The BlackBerry® 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/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
Come build with us! The BlackBerry® 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/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Come build with us! The BlackBerry® 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/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How to find the installed path for update

[Blair]

What people often do is store APPLICATIONFOLDER to a registry value, and use
a RegistrySearch to populate a secure property by the same name with it.


  


And inside of one of your components (or in a new component created for this
purpose)
  

If the registry key/value doesn't exist, the current logic is used to
calculate the path. If the value does exist, the current logic is ignored
and that path shows up in the UI as well as gets used for installation.

-Original Message-
From: Jiang, Chunyan (GE Healthcare) [mailto:chunyan.ji...@ge.com] 
Sent: Friday, October 02, 2009 6:26 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] How to find the installed path for update

Hi Wix-users,
 
I have developed a wix installer. It is an updatable installation
package. For the path, I set the default path as 
 




 

It will show "D:\ViewPoint6" as the default in InstallDirDlg.wxs:





 

However, if I installed the software in the other path, like
d:\testinatll for the first time. When there is new version avalable, I
want to update it. The InstallDirDlg still shows the path as
"D:\ViewPoint6", instead of "d:\testinatll".

How can I get the path for the update installation and set it to
InstallDirDlg? Probably, I need to have to dialogs, one for new
installation, defaut path is "D:\ViewPoint6", the other one is update
dialog, the path should be set as installed path.

 

Best regards

Chunyan


--
Come build with us! The BlackBerry® 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/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Come build with us! The BlackBerry® 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/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Problem with storing checkbox state

[Blair]

Remove the "" line.

Add:




NOT
Installed AND NOT OLDERVERSIONDETECTED


NOT
Installed AND NOT OLDERVERSIONDETECTED


What this will do is keep ADDITIONAL_PARAMS as a secure property, but it
won't get a "default" value unless this is a new installation (or major
upgrade). Change OLDERVERSIONDETECTED to be whatever you have in your
Upgrade table for removing older versions.

-Original Message-
From: Igor Lemsky [mailto:igor.lem...@gmail.com] 
Sent: Friday, October 02, 2009 1:11 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Problem with storing checkbox state

In my installer I have checkbox "Add also addiotional parameters" with
property ADDITIONAL_PARAMS. Its value "1" if checkbox is checked, and no
value if unchecked.
Worked perfectly, but there are problems. I store property to the registry,
and use regsearch to restore it during upgrade or reinstall.

.


  


Problem if checkbox was unchecked during first installation. In registry we
see key value of Software\Company\Installation\ADDITIONAL_PARAMS is null. It
is ok: the property value in installer is also null and it is right.
But during reinstall the checkbox become checked! Installer ignored that
ADDITIONAL_PARAMS = null! May be it looks into registry, find no value and
set default value from Property Value attribute?
if I delete this attribute (   ) then it correctly restored checkbox value (property value)
from registry, but then during first install this checkbox become unchecked
for default! But I need it to be checked for default. What can I do?

--
Come build with us! The BlackBerry® 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/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Come build with us! The BlackBerry® 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/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] How to find the installed path for update

[Jiang, Chunyan (GE Healthcare)]

Hi Wix-users,
 
I have developed a wix installer. It is an updatable installation
package. For the path, I set the default path as 
 




 

It will show "D:\ViewPoint6" as the default in InstallDirDlg.wxs:





 

However, if I installed the software in the other path, like
d:\testinatll for the first time. When there is new version avalable, I
want to update it. The InstallDirDlg still shows the path as
"D:\ViewPoint6", instead of "d:\testinatll".

How can I get the path for the update installation and set it to
InstallDirDlg? Probably, I need to have to dialogs, one for new
installation, defaut path is "D:\ViewPoint6", the other one is update
dialog, the path should be set as installed path.

 

Best regards

Chunyan

--
Come build with us! The BlackBerry® 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/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] CustomAction : Enumerating SQLServer Instancesacrossthe network using SQLDMO

[Dominique Louis]

Hi Thomas,
  Great to see the WiXRepo is up and running so quickly.

I'm not sure how organized you can make things on codeplex, as I've
never used it, but maybe CustomActions could be grouped per programming
language. So a sub-dir for VB Script and another for C/C++ and C# etc.

How can developers submit things to the project? Do you have to register
to be able to be part of the project?

A more portable solution to this SQLDMO code below would be to use SMO,
as that is supported on SQLServer 2005 and 2008, but VB Script cannot
call static methods, so it seems only a C/C+/C# etc solution would work
for that.

Dominique.

-Original Message-
From: Thomas Due [mailto:thomas@scanvaegt.dk] 
Sent: 02 October 2009 06:47
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] CustomAction : Enumerating SQLServer
Instancesacrossthe network using SQLDMO

This would be perfect for http://wixrepo.codeplex.com/

Also: Looks good, looking forward to playing around with it, although
the company I work for, will have to support 2008 as well in the near
future. 

/Thomas

-Original Message-
From: Dominique Louis [mailto:dominique.lo...@amxeurope.com] 
Sent: 1. oktober 2009 18:16
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] CustomAction : Enumerating SQLServer Instances
acrossthe network using SQLDMO

Hi all,
  I couldn't find all this code in one place so I thought this list
might be a good place to archive it.


  Set sqlApp = CreateObject("SQLDMO.Application") 
  
  If ( Err.Number <> 0 ) Then
  wscript.echo "SQLDMO.Application Not found. Error : " &
Err.Number
  wscript.Quit -1
  End If
 
  Set sqlServer2 = CreateObject("SQLDMO.SQLServer2")
  
  If ( Err.Number <> 0 ) Then
  wscript.echo "SQLDMO.SQLServer2 Not found. Error : " &
Err.Number
  wscript.Quit -1
  End If
 
  Set serverList = sqlApp.ListAvailableSQLServers 
 
  numServers = serverList.Count 
 
  Dim x, y
  
  For x = 1 To numServers  
  
Set instanceList = sqlServer2.ListInstalledInstances(
serverList(x) ) 

if Not ( instanceList is Nothing ) Then

  numInstances = instanceList.Count  

  wscript.echo serverList(x)
  For y = 1 To numInstances
wscript.echo "" & instanceList(y)
  Next
End IF
  Next 
 
  Set sqlServer2 = Nothing 
  Set sqlApp = Nothing


Note SQLDMO only works with SQLServer 2005 and below and is not
installed by default on SQLServer 2008 onwards


Hope this helps someone.


DOMINIQUE LOUIS | IS DEVELOPER, AMX DIGITAL MEDIA GROUP
AMX UK| 6TH FLOOR SALISBURY HOUSE,| LONDON WALL | LONDON | EC2M 5QQ
www.amx.com
AMX

AMX UK
Auster Road
Clifton Moor
York, North Yorkshire
United Kingdom
YO30 4GD

+44 (0) 1904 343100 office
+44 (0) 1904 343101 fax

AMX South
6th Floor Salisbury House
London Wall
London
United Kingdom
EC2M 5QQ

+44 (0) 2076 529450 office
+44 (0) 8701 991661 fax

AMX Belgium
Boerenkrijglaan, 96a
B-2260
Westerlo
Belgium


+ 32 (0) 1454 2763  office
+ 32 (0) 1454 2766  fax

##
Attention: 
This e-mail message is privileged and confidential. If you are not the 
intended recipient please delete the message and notify the sender. 
Any views or opinions presented are solely those of the author.

This email was scanned and cleared by NetIQ MailMarshal.
##

--
Come build with us! The BlackBerry® 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/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Modular install configurations based on availablefiles

[Nick Ball]

Brian, 

Thanks, I was thinking something along these lines for the future. At
the moment a simpler request, perhaps. How can I chain two
installations? For example, most of the time I ship my app and a
database. If the installers are separate, I would like to install the
app first, then the database. Of course, I also need .Net, and hence am
using the bootstrapper in VS via Wix which is perhaps an added
complication. Any suggestions? This would be a step in the right
direction for the full modular system.

Cheers,

Nick

-Original Message-
From: Brian Rogers [mailto:rogers.br...@gmail.com] 
Sent: 30 September 2009 18:32
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Modular install configurations based on
availablefiles

Hey Nick,

I would look at Burn to help you accomplish some of your goals. You
could
make an individual MSI for each database you are shipping. Compile those
individual MSIs into Burn and then use the search features of Burn to
determine which databases have already been installed via MSI searches
and
choose which to install later. Each MSI would have business logic for
how to
install the database. This would help you keep things modular in the
long
run. It would also help you with patching and upgrade support. Databases
are, IMHO, one of the hardest installs to upgrade through MSI (good
luck).

The cab file approach wouldn't be an MSI/WiX approach in the long run.

Hope that helps,

Brian Rogers
"Intelligence removes complexity." - Me
http://blogs.msdn.com/icumove <-- NEW


On Wed, Sep 30, 2009 at 9:00 AM, Nick Ball
wrote:

> Hi All,
>
>
>
> I have a product that ships with several different databases - or
> combinations thereof. I would like my installer to show all available
> databases as features that the user can install - and those that
didn't
> get shipped should be greyed out.
>
>
>
> I'm thinking of one main setup program and each database stored as a
> feature in separate cab files. I can either then look on the source
disk
> for each cab file in turn, or write a small XML file (like office
seems
> to do) describing the components and where they are. At the moment,
I'd
> like to do everything in WiX.
>
>
>
> A couple of questions.
>
>
>
> 1.   Is it easy to look for named cab files? If so how? What are
the
> problems with this approach (I'm thinking that a repair would need the
> source disk for this to work).
>
> 2.   If the config was stored in an XML file instead of searching
> for CABS, how would this get round the repair problem?
>
>
>
> Any other suggestions that would help me create a modular installation
> welcome.
>
>
>
> Regards
>
>
>
> Nick
>
>
>
>
>

--
> Come build with us! The BlackBerry® 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/devconf
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>


--
Come build with us! The BlackBerry® 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/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Uninstalling a web site installled with header inwebaddress

[Peter Shirtcliffe]

I would guess that you arent saving the parameter passed to the MSI. You should 
write it to the registry during installation and retrieve during maintenance 
(repair, uninstallation etc), using a . If you need any more 
details on how to do this, search the list for "persisting properties"

-Original Message-
From: kalepalli uday [mailto:knv_u...@yahoo.com] 
Sent: 01 October 2009 22:26
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Uninstalling a web site installled with header inwebaddress

We have a wix script to create a website on IIS7 and we use the 
IISextensions dll for the wix. We use the iis:webaddress tag with header 
attribute set through a parameter to msi. On installation the site is created 
as expected with specified port and header. But when trying to uninstall, it 
deletes the default web site instead of the site the msi created. How can 
i correct this behaviour to uninstall the correct site not the default site?


  
--
Come build with us! The BlackBerry® 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/devconf ___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

SDL PLC confidential, all rights reserved.
If you are not the intended recipient of this mail SDL requests and requires 
that you delete it without acting upon or copying any of its contents, and we 
further request that you advise us.
SDL PLC is a public limited company registered in England and Wales.  
Registered number: 02675207.  
Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, 
UK.


--
Come build with us! The BlackBerry® 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/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Problem with storing checkbox state

[Igor Lemsky]

In my installer I have checkbox "Add also addiotional parameters" with
property ADDITIONAL_PARAMS. Its value "1" if checkbox is checked, and no
value if unchecked.
Worked perfectly, but there are problems. I store property to the registry,
and use regsearch to restore it during upgrade or reinstall.

.


  


Problem if checkbox was unchecked during first installation. In registry we
see key value of Software\Company\Installation\ADDITIONAL_PARAMS is null. It
is ok: the property value in installer is also null and it is right.
But during reinstall the checkbox become checked! Installer ignored that
ADDITIONAL_PARAMS = null! May be it looks into registry, find no value and
set default value from Property Value attribute?
if I delete this attribute (   ) then it correctly restored checkbox value (property value)
from registry, but then during first install this checkbox become unchecked
for default! But I need it to be checked for default. What can I do?
--
Come build with us! The BlackBerry® 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/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users