Re: [WiX-users] what's wrong with light

[Bob Arnson]

Ziegelwanger, Silvio wrote:


Unhandled Exception: Microsoft.Tools.WindowsInstallerXml.WixException: 
Exception


 of type 'Microsoft.Tools.WindowsInstallerXml.WixException' was thrown.

   at 
Microsoft.Tools.WindowsInstallerXml.ValidatorExtension.Log(String message)


 

   at 
Microsoft.Tools.WindowsInstallerXml.Validator.ValidationUIHandler(IntPtr c


ontext, UInt32 messageType, String message)



Looks like a bug that was fixed in a more recent version of WiX. Try a 
weekly release from http://wix.sourceforge.net/releases/.


--
sig://boB
http://joyofsetup.com/

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Changing an installation in Add/Remove fails if msi is missing

[Bob Arnson]

Geoff Finger wrote:
> If we run our installation and then delete the msi when we're done,
> uninstalling the program through add/remove works but selecting the
> Change option fails. 

MSI caches the .msi database but strips out any embedded cabinets, so a 
Change operation to *add* features will require the original source.

> The person who handles the older InstallAware msi's says that they
> have an "web install" option they can set that will make sure the
> whole msi gets cached in Windows\Installer. Are there any similar
> options in Wix, either for individual components or the whole msi?
>   

Not today. A simple approach is to have a bootstrapper copy the .msi to 
a localappdata location and run the install from the copy. That way, MSI 
will look to the copy if it's needed. The WiX setupexe bootstrapper 
offers that option. Visual Studio copies the .msi into the installation 
directory tree, then uses the MSI APIs to add that copy as a source.

-- 
sig://boB
http://joyofsetup.com/



-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Are conditional service dependencies possible?

[Bob Arnson]

Geoff Finger wrote:
> We're trying to install a service that is dependent on HTTP SSL in XP,
> however that service doesn't exist and isn't needed in Vista. When we
> added another ServiceDependency element to the service for HTTP SSL it
> stopped the errors we were getting in XP, but now it's impossible to
> start the service in Vista where it previously worked fine. Is there
> any sneaky way to give an individual ServiceDependency element a
> condition or am I going to have to create two different Components
> with identically named services but different dependencies?
>   

ServiceDependency elements turn into a single string in the 
ServiceInstall table, so there's no way to condition them. However, 
because the Dependencies column is a formatted value, one way to work 
around it is to use a [PROPERTY] dependency, then use a type-51 custom 
action to set PROPERTY based on whatever conditions you want.

-- 
sig://boB
http://joyofsetup.com/



-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] AppSearch during Maintenance Installation

[Bob Arnson]

Markus Kuehni wrote:
Specifically I need to perform AppSearch in order to locate third 
party paths and registry settings.


AppSearch runs during maintenance mode unless you've added a condition 
to prevent it. Check a verbose log to see what's happening.


--
sig://boB
http://joyofsetup.com/

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] ServiceInstall and ServiceControl

[Bob Arnson]

Christopher Butcher wrote:


The installation runs through fine and installs, the oddity comes 
after uninstalling.


 


The MSI runs fine and says it has uninstalled.

 


But when you check the Services panel, your service is still there.



Create a verbose log and check the InstallValidate logging to make sure 
the service component is being uninstalled.


--
sig://boB
http://joyofsetup.com/

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WiX, MSI checksum and overwrite behaviour

[Alex Shevchuk]

George,

To get behavior you want:

* Make your file a keypath of your component (File/@KeyPath="yes")
* Use /fc option to repair your installation

Alex Shevchuk




On Tue, Mar 25, 2008 at 5:16 PM, Georgi Shopov <[EMAIL PROTECTED]> wrote:

> Hi,
>
> can any body give me suggestion what is the proper combination of MSIEXEC
> fix command options and file (WiX) properties that will ensure that a file
> will be overwritten ONLY in the case it is different or missing;
>
> I have Windows Installer version 3;
> I use the basic SampleFirst.wxs example with a text file;
> The file passes ICE checks in ORCA with no errors/warnings reports;
> Basically it has one feature with one component with one text file;
> The file has checksum attribute set to "yes" and the file hash is present
> in MsiFileHash table;
> I install the packet with "MSIEXEC /i samplefirst.msi" command and it is
> properly installed;
>
> What I need to figure out is how to get this behaviour:
>
>  if a fix/update command is started, if file is not changed, the file NOT
> to be overwritten;
>  if a fix/update command is started, if file is changed, the file to be
> overwritten;
>
> I've tried different combinations of MSIEXEC fix command (/F???) but the
> log file says file is either always overwritten (never-mind if changed) or
> NOT overwritten (although there is info that file has changed)
>
> So,
>
> Thanks,
>  George S.
>
>
>
>
>
>
>
>
>
>
> -
> Спечели 40 литра гориво сега!
> http://www.clubf1.net/shellgame.php
>
> -
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
>
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Problem with Setupbld and localization transforms

[Michael Ballou]

I'm using Wix build 3.0.3907.  I created my English MSI with language
1033 codepage 1252, and a localized Japanese MSI with language 1041
codepage 932.  I then used torch.exe with the -type language option to
create a .mst file.  

I then use this command line to build a setup.exe that will apply the
transform on Japanese systems:

setupbld.exe -out MySetup.exe -ms Setup-en.msi -u 1041 Setup-ja.mst
-setup "C:\Program Files\Windows Installer XML v3\bin\setup.exe"

Everything seems successful, but the transform is never applied
correctly on the target machine so the install still appears in English.
In the temp folder, I see the transform does get extracted, but its not
applied to the temp msi files in there for some reason.  I tried
manually applying the transform to the msi using Orca but it gives me an
error "The specified transform could not be applied."  I wrote my own
C++ app that calls MsiDatabaseApplyTransform so I could get the error
message, but it successfully applied the transform without error.  

Am I doing something wrong?

Thanks,
Mike Ballou

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] WiX, MSI checksum and overwrite behaviour

[Georgi Shopov]

Hi,

can any body give me suggestion what is the proper combination of MSIEXEC fix 
command options and file (WiX) properties that will ensure that a file will be 
overwritten ONLY in the case it is different or missing;

I have Windows Installer version 3; 
I use the basic SampleFirst.wxs example with a text file;
The file passes ICE checks in ORCA with no errors/warnings reports;
Basically it has one feature with one component with one text file;
The file has checksum attribute set to "yes" and the file hash is present in 
MsiFileHash table;
I install the packet with "MSIEXEC /i samplefirst.msi" command and it is 
properly installed;

What I need to figure out is how to get this behaviour:

 if a fix/update command is started, if file is not changed, the file NOT to be 
overwritten;
 if a fix/update command is started, if file is changed, the file to be 
overwritten;

I've tried different combinations of MSIEXEC fix command (/F???) but the log 
file says file is either always overwritten (never-mind if changed) or NOT 
overwritten (although there is info that file has changed)

So, 

Thanks,
 George S.



 






-
Спечели 40 литра гориво сега!
http://www.clubf1.net/shellgame.php

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] RemoveExistingProducts placement

[Wilson, Phil]

Assuming I remember all this correctly, then:

Your questions:

1. all files are removed before any new files are copied
2. so no version comparison is done - the REINSTALLMODE flags are irrelevant
3. so even files with Component/@NeverOverwite are newly installed (because any 
existing file was removed)
4. this way I can do consistent downgrades (all components are downgraded to 
the packaged version)
5. on repair, the @NeverOverwite files are safely left alone?

And:

If RemoveExistingProducts is after InstallFinalize:


1)No.

2)REINSTALLMODE is not used during an upgrade, but version comparison is 
used to determine if incoming files should replace existing ones. This is what 
makes it efficient, not that I've ever seen any numbers about the supposed 
improvement.

3)No because of 2).

4)No.

5)Not sure what you're getting at. After the upgrade a repair puts back 
what's supposed to be there as a result of the upgrade.

There can also be some gotchas with component guids because component ref 
counting is used to figure out what to ref count down after the incoming 
install has been done (potentially) all over the existing one, files and all.

I tend to be paranoid about REP after InstallFinalize because of rollback. If 
you install the new product and then the REP uninstall of the previous one 
(outside the transaction) fails then it will rollback and leave both old and 
new products on the system.


If RemoveExistingProducts is immediately after InstallInitialize then:


1)Yes.

2)Yes.

3)Yes.

4)If your REP always uninstalls existing products, yes.

5)Same as before.

Because all files are removed first then nobody cares what the incoming 
component guids are (unless of course you are sharing some other way).

Phil Wilson

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Markus Kuehni
Sent: Tuesday, March 25, 2008 9:00 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] RemoveExistingProducts placement

Hi

On a related note to my previous post (rules on overwriting files), I wonder, 
what exactly the effect of placing the  is.

I'm doing major upgrades only. No shared components.

In order to make the upgrade as efficient as possible, I currently use
  
or
  
in order to make it into one transaction (all or nothing).

See
  http://msdn2.microsoft.com/en-us/library/aa371197(VS.85).aspx

Now I wonder if I should actually use
  

Using this sequence, is it true that
1. all files are removed before any new files are copied
2. so no version comparison is done - the REINSTALLMODE flags are irrelevant
3. so even files with Component/@NeverOverwite are newly installed (because any 
existing file was removed)
4. this way I can do consistent downgrades (all components are downgraded to 
the packaged version)
5. on repair, the @NeverOverwite files are safely left alone?

this would be exactly the way I'd like it to be!

Maybe
6. this is less efficient when a lot of files stay the same (because all these 
files are first deleted, then re-copied)
but that's ok.

Thanks for all help an reassurance,
_Mark



-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Losing property values...

[Alexander Shevchuk]

Custom action is scheduled in InstallExecuteSequence, so it is already server 
side.




-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wilson, Phil
Sent: Tuesday, March 25, 2008 3:43 PM
To: 'nhenny'; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Losing property values...

This might be a SecureCustomProperties issue - VDDIR needs to be in that list.

Phil Wilson

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of nhenny
Sent: Tuesday, March 25, 2008 2:55 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Losing property values...


I have a immediate CA that setups some properties which build path
information for me to use when I setup a virtual directory, for example:





Then I have a the following as my :


  
  
  
  NOT
Installed
  
  NOT
REINSTALL="ALL"
  REMOVE="ALL"
  REMOVE="ALL"
  NEWERFOUND
  



When I get to the "SetupWebSiteDefer" CA (which is a deferred VBScript CA)
it uses Session.Property to get the values for the properties VDDIR and
WEBDIR, however they are blank.  When I look at the verbose log I can see
where the values are being set correctly before the "SetupWebSiteDefer" CA
is being called.  Any suggestions as to what I am doing wrong?  TIA.

Here is the log:

These are listed first in the log

MSI (s) (74:E4) [14:21:28:275]: Doing action: SetVDDIR
MSI (s) (74:E4) [14:21:28:275]: Note: 1: 2205 2:  3: ActionText
Action 14:21:28: SetVDDIR.
Action start 14:21:28: SetVDDIR.
MSI (s) (74:E4) [14:21:28:275]: PROPERTY CHANGE: Adding VDDIR property. Its
value is 'C:\Program Files\web\v2008'.
Action ended 14:21:28: SetVDDIR. Return value 1.
MSI (s) (74:E4) [14:21:28:275]: Doing action: SetWEBDIR
MSI (s) (74:E4) [14:21:28:275]: Note: 1: 2205 2:  3: ActionText
Action 14:21:28: SetWEBDIR.
Action start 14:21:28: SetWEBDIR.
MSI (s) (74:E4) [14:21:28:285]: PROPERTY CHANGE: Adding WEBDIR property. Its
value is 'C:\Program Files\web'.
Action ended 14:21:28: SetWEBDIR. Return value 1.



Then this is below the previous snippet above


MSI (s) (74:E4) [14:21:58:950]: Executing op:
ActionStart(Name=SetupWebSiteDefer,,)
Action 14:21:58: SetupWebSiteDefer.
MSI (s) (74:E4) [14:21:58:950]: Executing op:
CustomActionSchedule(Action=SetupWebSiteDefer,ActionType=3078,Source='
MSI (s) (74:A4) [14:21:58:970]: Generating random cookie.
MSI (s) (74:A4) [14:21:59:000]: Created Custom Action Server with PID 2648
(0xA58).
MSI (s) (74:90) [14:21:59:580]: Running as a service.
MSI (s) (74:90) [14:21:59:580]: Hello, I'm your 32bit Elevated custom action
server.
MSI (s) (74:F4) [14:21:59:630]: Note: 1: 2205 2:  3: Error
MSI (s) (74:F4) [14:21:59:630]: Note: 1: 2228 2:  3: Error 4: SELECT
`Message` FROM `Error` WHERE `Error` = 1720
Error 1720. There is a problem with this Windows Installer package. A script
required for this install to complete could not be run. Contact your support
personnel or package vendor.  Custom action SetupWebSiteDefer script error
-2146828235, Microsoft VBScript runtime error: File not found Line 326,
Column 5,
MSI (s) (74:F4) [14:22:57:660]: Note: 1: 2205 2:  3: Error
MSI (s) (74:F4) [14:22:57:660]: Note: 1: 2228 2:  3: Error 4: SELECT
`Message` FROM `Error` WHERE `Error` = 1709
MSI (s) (74:F4) [14:22:57:660]: Product: Web 2008.0 -- Error 1720. There is
a problem with this Windows Installer package. A script required for this
install to complete could not be run. Contact your support personnel or
package vendor.  Custom action SetupWebSiteDefer script error -2146828235,
Microsoft VBScript runtime error: File not found Line 326, Column 5,


The script that blew up is trying to find the web.config file in the VDDIR
path and the vbscript thinks that Session.Property("VDDIR") = "" so it looks
for the file in the following path "\web.config" which of course does not
exist.



--
View this message in context: 
http://www.nabble.com/Losing-property-values...-tp16289577p16289577.html
Sent from the wix-users mailing list archive at Nabble.com.


-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge

[WiX-users] Are conditional service dependencies possible?

[Geoff Finger]

We're trying to install a service that is dependent on HTTP SSL in XP,
however that service doesn't exist and isn't needed in Vista. When we
added another ServiceDependency element to the service for HTTP SSL it
stopped the errors we were getting in XP, but now it's impossible to
start the service in Vista where it previously worked fine. Is there
any sneaky way to give an individual ServiceDependency element a
condition or am I going to have to create two different Components
with identically named services but different dependencies?

Thanks!

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Losing property values...

[Wilson, Phil]

This might be a SecureCustomProperties issue - VDDIR needs to be in that list.

Phil Wilson

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of nhenny
Sent: Tuesday, March 25, 2008 2:55 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Losing property values...


I have a immediate CA that setups some properties which build path
information for me to use when I setup a virtual directory, for example:





Then I have a the following as my :


  
  
  
  NOT
Installed
  
  NOT
REINSTALL="ALL"
  REMOVE="ALL"
  REMOVE="ALL"
  NEWERFOUND
  



When I get to the "SetupWebSiteDefer" CA (which is a deferred VBScript CA)
it uses Session.Property to get the values for the properties VDDIR and
WEBDIR, however they are blank.  When I look at the verbose log I can see
where the values are being set correctly before the "SetupWebSiteDefer" CA
is being called.  Any suggestions as to what I am doing wrong?  TIA.

Here is the log:

These are listed first in the log

MSI (s) (74:E4) [14:21:28:275]: Doing action: SetVDDIR
MSI (s) (74:E4) [14:21:28:275]: Note: 1: 2205 2:  3: ActionText
Action 14:21:28: SetVDDIR.
Action start 14:21:28: SetVDDIR.
MSI (s) (74:E4) [14:21:28:275]: PROPERTY CHANGE: Adding VDDIR property. Its
value is 'C:\Program Files\web\v2008'.
Action ended 14:21:28: SetVDDIR. Return value 1.
MSI (s) (74:E4) [14:21:28:275]: Doing action: SetWEBDIR
MSI (s) (74:E4) [14:21:28:275]: Note: 1: 2205 2:  3: ActionText
Action 14:21:28: SetWEBDIR.
Action start 14:21:28: SetWEBDIR.
MSI (s) (74:E4) [14:21:28:285]: PROPERTY CHANGE: Adding WEBDIR property. Its
value is 'C:\Program Files\web'.
Action ended 14:21:28: SetWEBDIR. Return value 1.



Then this is below the previous snippet above


MSI (s) (74:E4) [14:21:58:950]: Executing op:
ActionStart(Name=SetupWebSiteDefer,,)
Action 14:21:58: SetupWebSiteDefer.
MSI (s) (74:E4) [14:21:58:950]: Executing op:
CustomActionSchedule(Action=SetupWebSiteDefer,ActionType=3078,Source='
MSI (s) (74:A4) [14:21:58:970]: Generating random cookie.
MSI (s) (74:A4) [14:21:59:000]: Created Custom Action Server with PID 2648
(0xA58).
MSI (s) (74:90) [14:21:59:580]: Running as a service.
MSI (s) (74:90) [14:21:59:580]: Hello, I'm your 32bit Elevated custom action
server.
MSI (s) (74:F4) [14:21:59:630]: Note: 1: 2205 2:  3: Error
MSI (s) (74:F4) [14:21:59:630]: Note: 1: 2228 2:  3: Error 4: SELECT
`Message` FROM `Error` WHERE `Error` = 1720
Error 1720. There is a problem with this Windows Installer package. A script
required for this install to complete could not be run. Contact your support
personnel or package vendor.  Custom action SetupWebSiteDefer script error
-2146828235, Microsoft VBScript runtime error: File not found Line 326,
Column 5,
MSI (s) (74:F4) [14:22:57:660]: Note: 1: 2205 2:  3: Error
MSI (s) (74:F4) [14:22:57:660]: Note: 1: 2228 2:  3: Error 4: SELECT
`Message` FROM `Error` WHERE `Error` = 1709
MSI (s) (74:F4) [14:22:57:660]: Product: Web 2008.0 -- Error 1720. There is
a problem with this Windows Installer package. A script required for this
install to complete could not be run. Contact your support personnel or
package vendor.  Custom action SetupWebSiteDefer script error -2146828235,
Microsoft VBScript runtime error: File not found Line 326, Column 5,


The script that blew up is trying to find the web.config file in the VDDIR
path and the vbscript thinks that Session.Property("VDDIR") = "" so it looks
for the file in the following path "\web.config" which of course does not
exist.



--
View this message in context: 
http://www.nabble.com/Losing-property-values...-tp16289577p16289577.html
Sent from the wix-users mailing list archive at Nabble.com.


-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Losing property values...

[Alexander Shevchuk]

>From http://msdn2.microsoft.com/en-us/library/aa370543(VS.85).aspx:

"Property values that are set at the time the installation sequence is 
processed into script may be unavailable at the time of script execution. Only 
the following limited set of properties is always accessible to custom actions 
during script execution.

- CustomActionData: Value at time custom action is processed in sequence table. 
The CustomActionData property is only available to deferred execution custom 
actions. Immediate custom actions do not have access to this property.
- ProductCode Unique code for the product, a GUID string.
- UserSID Set by the installer to the user's security identifier (SID)."


For deferred custom action to be able to get the value of a property, the value 
of property must be saved in the CustomActionData property.  Here is the sample 
on how to do that: http://www.tramontana.co.hu/wix/lesson3.php#3.6.


Alex




-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of nhenny
Sent: Tuesday, March 25, 2008 2:55 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Losing property values...


I have a immediate CA that setups some properties which build path
information for me to use when I setup a virtual directory, for example:





Then I have a the following as my :


  
  
  
  NOT
Installed
  
  NOT
REINSTALL="ALL"
  REMOVE="ALL"
  REMOVE="ALL"
  NEWERFOUND
  



When I get to the "SetupWebSiteDefer" CA (which is a deferred VBScript CA)
it uses Session.Property to get the values for the properties VDDIR and
WEBDIR, however they are blank.  When I look at the verbose log I can see
where the values are being set correctly before the "SetupWebSiteDefer" CA
is being called.  Any suggestions as to what I am doing wrong?  TIA.

Here is the log:

These are listed first in the log

MSI (s) (74:E4) [14:21:28:275]: Doing action: SetVDDIR
MSI (s) (74:E4) [14:21:28:275]: Note: 1: 2205 2:  3: ActionText
Action 14:21:28: SetVDDIR.
Action start 14:21:28: SetVDDIR.
MSI (s) (74:E4) [14:21:28:275]: PROPERTY CHANGE: Adding VDDIR property. Its
value is 'C:\Program Files\web\v2008'.
Action ended 14:21:28: SetVDDIR. Return value 1.
MSI (s) (74:E4) [14:21:28:275]: Doing action: SetWEBDIR
MSI (s) (74:E4) [14:21:28:275]: Note: 1: 2205 2:  3: ActionText
Action 14:21:28: SetWEBDIR.
Action start 14:21:28: SetWEBDIR.
MSI (s) (74:E4) [14:21:28:285]: PROPERTY CHANGE: Adding WEBDIR property. Its
value is 'C:\Program Files\web'.
Action ended 14:21:28: SetWEBDIR. Return value 1.



Then this is below the previous snippet above


MSI (s) (74:E4) [14:21:58:950]: Executing op:
ActionStart(Name=SetupWebSiteDefer,,)
Action 14:21:58: SetupWebSiteDefer.
MSI (s) (74:E4) [14:21:58:950]: Executing op:
CustomActionSchedule(Action=SetupWebSiteDefer,ActionType=3078,Source='
MSI (s) (74:A4) [14:21:58:970]: Generating random cookie.
MSI (s) (74:A4) [14:21:59:000]: Created Custom Action Server with PID 2648
(0xA58).
MSI (s) (74:90) [14:21:59:580]: Running as a service.
MSI (s) (74:90) [14:21:59:580]: Hello, I'm your 32bit Elevated custom action
server.
MSI (s) (74:F4) [14:21:59:630]: Note: 1: 2205 2:  3: Error
MSI (s) (74:F4) [14:21:59:630]: Note: 1: 2228 2:  3: Error 4: SELECT
`Message` FROM `Error` WHERE `Error` = 1720
Error 1720. There is a problem with this Windows Installer package. A script
required for this install to complete could not be run. Contact your support
personnel or package vendor.  Custom action SetupWebSiteDefer script error
-2146828235, Microsoft VBScript runtime error: File not found Line 326,
Column 5,
MSI (s) (74:F4) [14:22:57:660]: Note: 1: 2205 2:  3: Error
MSI (s) (74:F4) [14:22:57:660]: Note: 1: 2228 2:  3: Error 4: SELECT
`Message` FROM `Error` WHERE `Error` = 1709
MSI (s) (74:F4) [14:22:57:660]: Product: Web 2008.0 -- Error 1720. There is
a problem with this Windows Installer package. A script required for this
install to complete could not be run. Contact your support personnel or
package vendor.  Custom action SetupWebSiteDefer script error -2146828235,
Microsoft VBScript runtime error: File not found Line 326, Column 5,


The script that blew up is trying to find the web.config file in the VDDIR
path and the vbscript thinks that Session.Property("VDDIR") = "" so it looks
for the file in the following path "\web.config" which of course does not
exist.



--
View this message in context: 
http://www.nabble.com/Losing-property-values...-tp16289577p16289577.html
Sent from the wix-users mailing list archive at Nabble.com.


-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
WiX-users

[WiX-users] Losing property values...

[nhenny]

I have a immediate CA that setups some properties which build path
information for me to use when I setup a virtual directory, for example:





Then I have a the following as my :


  
  
  
  NOT
Installed
  
  NOT
REINSTALL="ALL"
  REMOVE="ALL"
  REMOVE="ALL"
  NEWERFOUND
  



When I get to the "SetupWebSiteDefer" CA (which is a deferred VBScript CA)
it uses Session.Property to get the values for the properties VDDIR and
WEBDIR, however they are blank.  When I look at the verbose log I can see
where the values are being set correctly before the "SetupWebSiteDefer" CA
is being called.  Any suggestions as to what I am doing wrong?  TIA.

Here is the log:

These are listed first in the log

MSI (s) (74:E4) [14:21:28:275]: Doing action: SetVDDIR
MSI (s) (74:E4) [14:21:28:275]: Note: 1: 2205 2:  3: ActionText 
Action 14:21:28: SetVDDIR. 
Action start 14:21:28: SetVDDIR.
MSI (s) (74:E4) [14:21:28:275]: PROPERTY CHANGE: Adding VDDIR property. Its
value is 'C:\Program Files\web\v2008'.
Action ended 14:21:28: SetVDDIR. Return value 1.
MSI (s) (74:E4) [14:21:28:275]: Doing action: SetWEBDIR
MSI (s) (74:E4) [14:21:28:275]: Note: 1: 2205 2:  3: ActionText 
Action 14:21:28: SetWEBDIR. 
Action start 14:21:28: SetWEBDIR.
MSI (s) (74:E4) [14:21:28:285]: PROPERTY CHANGE: Adding WEBDIR property. Its
value is 'C:\Program Files\web'.
Action ended 14:21:28: SetWEBDIR. Return value 1.



Then this is below the previous snippet above


MSI (s) (74:E4) [14:21:58:950]: Executing op:
ActionStart(Name=SetupWebSiteDefer,,)
Action 14:21:58: SetupWebSiteDefer. 
MSI (s) (74:E4) [14:21:58:950]: Executing op:
CustomActionSchedule(Action=SetupWebSiteDefer,ActionType=3078,Source='
 
MSI (s) (74:A4) [14:21:58:970]: Generating random cookie.
MSI (s) (74:A4) [14:21:59:000]: Created Custom Action Server with PID 2648
(0xA58).
MSI (s) (74:90) [14:21:59:580]: Running as a service.
MSI (s) (74:90) [14:21:59:580]: Hello, I'm your 32bit Elevated custom action
server.
MSI (s) (74:F4) [14:21:59:630]: Note: 1: 2205 2:  3: Error 
MSI (s) (74:F4) [14:21:59:630]: Note: 1: 2228 2:  3: Error 4: SELECT
`Message` FROM `Error` WHERE `Error` = 1720 
Error 1720. There is a problem with this Windows Installer package. A script
required for this install to complete could not be run. Contact your support
personnel or package vendor.  Custom action SetupWebSiteDefer script error
-2146828235, Microsoft VBScript runtime error: File not found Line 326,
Column 5,  
MSI (s) (74:F4) [14:22:57:660]: Note: 1: 2205 2:  3: Error 
MSI (s) (74:F4) [14:22:57:660]: Note: 1: 2228 2:  3: Error 4: SELECT
`Message` FROM `Error` WHERE `Error` = 1709 
MSI (s) (74:F4) [14:22:57:660]: Product: Web 2008.0 -- Error 1720. There is
a problem with this Windows Installer package. A script required for this
install to complete could not be run. Contact your support personnel or
package vendor.  Custom action SetupWebSiteDefer script error -2146828235,
Microsoft VBScript runtime error: File not found Line 326, Column 5,  


The script that blew up is trying to find the web.config file in the VDDIR
path and the vbscript thinks that Session.Property("VDDIR") = "" so it looks
for the file in the following path "\web.config" which of course does not
exist.



-- 
View this message in context: 
http://www.nabble.com/Losing-property-values...-tp16289577p16289577.html
Sent from the wix-users mailing list archive at Nabble.com.


-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] [Personal note: goodbye to Wix-Users, and thanks]

[Daryn Mitchell]

I'm changing jobs in two weeks, and with the change in responsibility
I'll be leaving the Wix-users community. I subscribed to the list last
year and was able to successfully - and relatively painlessly - change
our products from InstallShield to Wix. Almost all of that invaluable
knowledge came from the 9000 messages (not including spam) from the list
in the past year, with assistance from the list archives too.

I just wanted to say thanks to the list contributors for all your
helpful help on Wix and Windows Installer.

Daryn.

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Changing an installation in Add/Remove fails if msi is missing

[Geoff Finger]

If we run our installation and then delete the msi when we're done,
uninstalling the program through add/remove works but selecting the
Change option fails. First it pops up the "The feature you are trying
to use is on a network resource that is unavailable" dialog, and if we
cancel out of that it generates a 1706 error.

I turned on automatic logging but don't see any obvious problems. I'm
not sure what's triggering the ResolveSource action that causes the
problem. Unless there's some specific error that's causing the problem
I need a way to make sure the msi is always available even if the user
gets rid of the original copy.

The person who handles the older InstallAware msi's says that they
have an "web install" option they can set that will make sure the
whole msi gets cached in Windows\Installer. Are there any similar
options in Wix, either for individual components or the whole msi?

The other alternative I'm considering is copying the entire msi to the
target folder during installation, but that seems rather awkward and I
haven't figure out what registry setting I'd need to fix to get
Add/Remove Programs to look for the msi in the new location.

The relevant section from the automatic log (as best as I can tell anyways):

Action ended 13:23:44: CostFinalize. Return value 1.
MSI (c) (58:4C) [13:23:44:451]: Doing action: setUserProfileNT
Action 13:23:44: setUserProfileNT.
Action start 13:23:44: setUserProfileNT.
MSI (c) (58:4C) [13:23:44:451]: PROPERTY CHANGE: Modifying USERPROFILE
property. Its current value is 'C:\Program Files
(x86)\Laserfiche\Server\'. Its new value: 'C:\Documents and
Settings\gfinger'.
Action ended 13:23:44: setUserProfileNT. Return value 1.
MSI (c) (58:4C) [13:23:44:451]: Skipping action: SetAllUsersProfileNT
(condition is false)
MSI (c) (58:4C) [13:23:44:451]: Doing action: setAllUsersProfile2K
Action 13:23:44: setAllUsersProfile2K.
Action start 13:23:44: setAllUsersProfile2K.
MSI (c) (58:4C) [13:23:44:451]: PROPERTY CHANGE: Modifying
ALLUSERSPROFILE property. Its current value is 'C:\Program Files
(x86)\Laserfiche\Server\'. Its new value: 'C:\Documents and
Settings\All Users'.
Action ended 13:23:44: setAllUsersProfile2K. Return value 1.
MSI (c) (58:4C) [13:23:44:451]: Doing action: ResolveSource
Action 13:23:44: ResolveSource.
Action start 13:23:44: ResolveSource.
MSI (c) (58:4C) [13:23:44:451]: Resolving source.
MSI (c) (58:4C) [13:23:44:451]: User policy value 'SearchOrder' is 'nmu'
MSI (c) (58:4C) [13:23:44:451]: User policy value 'DisableMedia' is 0
MSI (c) (58:4C) [13:23:44:451]: Machine policy value 'AllowLockdownMedia' is 0
MSI (c) (58:4C) [13:23:44:451]: SOURCEMGMT: Media enabled only if
package is safe.
MSI (c) (58:4C) [13:23:44:451]: SOURCEMGMT: Looking for sourcelist for
product {Product-ID}
MSI (c) (58:4C) [13:23:44:451]: SOURCEMGMT: Adding {Product-ID}; to
potential sourcelist list (pcode;disk;relpath).
MSI (c) (58:4C) [13:23:44:451]: SOURCEMGMT: Now checking product {Product-ID}
MSI (c) (58:4C) [13:23:44:451]: SOURCEMGMT: Media is enabled for product.
MSI (c) (58:4C) [13:23:44:451]: SOURCEMGMT: Attempting to use
LastUsedSource from source list.
MSI (c) (58:4C) [13:23:44:451]: SOURCEMGMT: Trying source C:\Install\Server\.
MSI (c) (58:4C) [13:23:44:467]: Note: 1: 2203 2:
C:\Install\Server\server.msi 3: -2147287038
MSI (c) (58:4C) [13:23:44:467]: SOURCEMGMT: Source is invalid due to
missing/inaccessible package.
MSI (c) (58:4C) [13:23:44:467]: Note: 1: 1706 2: -2147483647 3: server.msi

Thanks!

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] AppSearch during Maintenance Installation

[Markus Kuehni]

Hi
 
How can I schedule actions during a Maintenance Installation?
 
Specifically I need to perform AppSearch in order to locate third party
paths and registry settings.
 
Background: our application provides interfaces to several third party
software solutions. At the time of install, some may not be present, and
some features may be disabled accordingly. However the user may install a
third party solution later and then revisit our setup in maintenance mode to
add the feature. 
 
Furthermore I am surprised, that [public] properties seem not to be
persistet accross to maintenance mode. How does one propagate the settings
the installer collected in the initial install? If via registry, then how,
without AppSearch? 
 
Thanks for all help,
Mark
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] IIS Reconfiguration Creating an Unininstall issue

[Brian Rogers]

It is valid to ask for a "fail quite" on uninstall feature to the IIS
settings custom action. This would definitely be needed for client
installations where the environment cannot be controlled.

However, I would imagine in a production environment that proper
configuration and release management would dictate that a sysadmin should
not be allowed to change the names of directories manually. Either a patch
which modifies the MSI database to show this change should be made, or a
re-release of the package as an upgraded version. It does not sound like the
sysadmin's have either been made aware of the impact or have proper
discipline to wait for CM/RM do their jobs.

After all, CM is just as much a part of the product version release to a
production environment as binaries themselves.


On Tue, Mar 25, 2008 at 12:39 PM, Karthik Krishnan <[EMAIL PROTECTED]>
wrote:

> I am running into an uninstall issue with IIS.
>
> The scenario is:
> -We use the IIS extension to create a vdir upon install.
> -After install and before uninstall, an admin changes the name of the
> vdir.
> -From then on, uninstalls fail (presumably since they can no longer find
> the vdir in the IIS metabase).
>
> Note that if the admin does not rename the vdir, then the uninstall
> succeeds fine.
>
> Also note that I have tried conditioning the IIS component with a command
> line property, and while the MSI log does show the correct property value
> (from the command line), the IIS component's condition does not appear to be
> evaluated on uninstall.  Instead, the uninstall still fails when it doesn't
> find the metabase entry for the original, installed vdir name.
>
> It would be ideal to implement an IIS uninstall override mechanism
> triggered by, for instance a command line argument, to bypass the IIS part
> of the uninstall while still continuing the rest of the uninstall.  Even
> though reconfiguring existing IIS settings may be a debatably invalid
> action, IIS Manager is still available.  A bypass approach would at least
> allow for the software to be uninstalled.
>
> Is there a way to do this?
>
> -
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>


-- 
Brian Rogers
"Intelligence removes complexity." - BR
http://www.codeplex.com/wixml/
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] IIS Reconfiguration Creating an Unininstall issue

[Karthik Krishnan]

 I am running into an uninstall issue with IIS.

The scenario is:
-We use the IIS extension to create a vdir upon install.
-After install and before uninstall, an admin changes the name of the vdir.
-From then on, uninstalls fail (presumably since they can no longer find the
vdir in the IIS metabase).

Note that if the admin does not rename the vdir, then the uninstall succeeds
fine.

Also note that I have tried conditioning the IIS component with a command
line property, and while the MSI log does show the correct property value
(from the command line), the IIS component's condition does not appear to be
evaluated on uninstall.  Instead, the uninstall still fails when it doesn't
find the metabase entry for the original, installed vdir name.

It would be ideal to implement an IIS uninstall override mechanism triggered
by, for instance a command line argument, to bypass the IIS part of the
uninstall while still continuing the rest of the uninstall.  Even though
reconfiguring existing IIS settings may be a debatably invalid action, IIS
Manager is still available.  A bypass approach would at least allow for the
software to be uninstalled.

Is there a way to do this?
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] ModuleInstallExecuteSequence not being merged into msi

[Geoff Finger]

That was in fact the problem, thanks!

On Sat, Mar 22, 2008 at 11:42 AM, Bob Arnson <[EMAIL PROTECTED]> wrote:
> Geoff Finger wrote:
>  > In the ModuleInstallExecuteSequence table of the msm files we have rows 
> such as:
>  >
>  > Action: RemoveOldDriver.B391C18A_6953_11D4_82CB_00D0B72E1DB9
>  > Sequence:
>  > BaseAction: CostInitialize
>  > After: 0
>  > Condition: INSTALLCONDITION=1
>  >
>
>  Does the ModuleInstallExecuteSequence table in the .msm also have a row
>  for CostInitialize? Mergemod.dll requires merge modules to be
>  "self-contained" in how they schedule actions. See the
>  ModuleInstallExecuteSequence table doc in the MSI SDK for an explanation
>  -- even if it's a lame one. Try using smoke.exe to run validation on
>  the merge module; it might provide details about problems that lead to a
>  fix.
>
>  --
>  sig://boB
>  http://joyofsetup.com/
>
>
>

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] what's wrong with light

[Ziegelwanger, Silvio]

Hi all,

 

 

What is wrong with my light.exe? 

Any ideas from the developers?

 

Here is the output:

 

 

C:\Program Files\Windows Installer XML v3\bin>light.exe -culture:en-US
-out c:\a

pplstrudl.msi c:\appl.strudl\install.wixobj

Microsoft (R) Windows Installer Xml Linker version 3.0.2925.0

Copyright (C) Microsoft Corporation 2003. All rights reserved.

 

 

Unhandled Exception: Microsoft.Tools.WindowsInstallerXml.WixException:
Exception

 of type 'Microsoft.Tools.WindowsInstallerXml.WixException' was thrown.

   at Microsoft.Tools.WindowsInstallerXml.ValidatorExtension.Log(String
message)

 

   at
Microsoft.Tools.WindowsInstallerXml.Validator.ValidationUIHandler(IntPtr
c

ontext, UInt32 messageType, String message)

 

 

The candle.exe runs with this two warnings:

 

c:\appl.strudl\install.wxs(38) : warning CNDL1069 : The
FileSearch/@LongName att

ribute has been deprecated.  Since WiX now has the ability to generate
short fil

e/directory names, the desired name should be specified in the Name
attribute in

stead.  If the name specified in the Name attribute is a short name,
then WiX wi

ll not generate a short name.  If the name specified in the Name
attribute is a

long name and you want to manually specify the short name, please set
the short

name value in the ShortName attribute.

c:\appl.strudl\install.wxs(230) : warning CNDL1083 : The 'ProductID'
property sh

ould not be directly authored because it will prevent the
ValidateProductID stan

dard action from performing any validation during the installation.
This proper

ty will be set by the ValidateProductID standard action or control
event.

 

 

Best regards,

 

Silvio

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Upgrade basis on installdir

[Alexander Shevchuk]

Properly implemented major upgrade requires the following:

-  Same UpgradeCode (Product/@UpgradeCode);

-  Different ProductCode(Product/@Id);

-  Different PackageCode (Package/@Id);

-  Different version (Product/@Version);

-  Records in the Upgrade table and few standard and custom actions 
(see http://msdn2.microsoft.com/en-us/library/aa369786(VS.85).aspx for more 
detail).

As you can see, major upgrade does not care about installation directory and 
during major upgrade product will be reinstalled in the previously selected 
installation directory.
For a situation you described, it seems like you need either small update or 
minor upgrade, but not major upgrade.
For example, you need an installer for version 1.0.  You also need a separate 
installer for version 1.5 and an upgrade for 1.0 to upgrade it to 1.5 and so on.


Alex



From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of puyo puy
Sent: Tuesday, March 25, 2008 12:19 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Upgrade basis on installdir

Hello everyone,

As I know if I want to create a MSI setup file to check for existing installed 
product from the system and upgrade to the new installer.  I need to keep the 
UpgradeCode and change the ProductCode.  Every time when user run the latest 
installer, MSI will uninstall the old one and install the new version and you 
will only find one entry in Add/Remove program.

How can I create an MSI that will check the current installed product's 
location, when the new version going to install the same location as existing 
path, I will treat as upgrade(uninstall then install the new one with the 
existing path).  But if it install different location and I will treat as new 
install.

Example.

MyProduct Version1.0 installed in c:\PathA.  MyProduct Version1.5 installed in 
c:\PathB.  For my new installer MyProduct Version 2.0, if user going to install 
it in c:\PathA or c:\PathB, my new installer should treat as upgrade and it 
will uninstall c:\PathA(or c:\PathB, depend on where the new installdir).  And 
user should see 2 entries in Add/Remove Program.  If user install Version 2.0 
in c:\PathC, the new installer should treat it as new install and he/she should 
see 3 entries in Add/Remove Program.

Any help is much appreciated.
Puyopuy


Get the name you always wanted with the new y7mail email 
address.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] RemoveExistingProducts placement

[Markus Kuehni]

Hi
 
On a related note to my previous post (rules on overwriting files), I
wonder, what exactly the effect of placing the  is.
 
I'm doing major upgrades only. No shared components.
 
In order to make the upgrade as efficient as possible, I currently use
  
or 
  
in order to make it into one transaction (all or nothing). 
 
See
  http://msdn2.microsoft.com/en-us/library/aa371197(VS.85).aspx
 
Now I wonder if I should actually use 
  
 
Using this sequence, is it true that 
1. all files are removed before any new files are copied
2. so no version comparison is done - the REINSTALLMODE flags are irrelevant
3. so even files with Component/@NeverOverwite are newly installed (because
any existing file was removed)
4. this way I can do consistent downgrades (all components are downgraded to
the packaged version)
5. on repair, the @NeverOverwite files are safely left alone?
 
this would be exactly the way I'd like it to be! 
 
Maybe
6. this is less efficient when a lot of files stay the same (because all
these files are first deleted, then re-copied)
but that's ok.
 
Thanks for all help an reassurance,
_Mark
 
 
 
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] ServiceInstall and ServiceControl

[Christopher Butcher]

Hi Guys

 

I'm experiencing an odd behaviour when using ServiceInstall and
ServiceControl.

 

  









  

 

The installation runs through fine and installs, the oddity comes after
uninstalling.

 

The MSI runs fine and says it has uninstalled.

 

But when you check the Services panel, your service is still there.

 

Checking REGEDIT, you can still see the entries in
HKLM\SYSTEM\CurrentControlSet\Services.

 

Has anyone experienced this, and found a solution?

 

Krs

Chris

 

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] what is the difference between "" and "1"

[Bob Arnson]

Xu nanxuan wrote:
Thanks.Btw: what do "Not Installed" and "Installed", which are also 
located in the middle of <>, mean?


They're Windows Installer properties. See "Property Reference" in the 
MSI SDK for a complete list.


--
sig://boB
http://joyofsetup.com/

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Re compiling WiX C++ libs for 64-bit

[Bob Arnson]

Sanin wrote:
> 1. Do I have to recompile my shim (i.e. C++ custom action) to 64-bit?
>   

Probably not. The WiX custom actions are currently 32-bit because we 
were able to work on 64-bit portions of the file system by disabling 
file-system redirection when necessary. It's available in wcautil.lib; 
see the source code in src/ca/wcautil/wcawow64.cpp.

> 2. If so, here is the problem:
>   - existing WiX C++ libraries (wcautil.lib and dutil.lib) are 32-bit.
>   

That will be changing soon. The file-system redirection API doesn't 
solve problems with the registry, so we're adding support for 64-bit 
custom action builds. That will probably appear in the next couple of weeks.

-- 
sig://boB
http://joyofsetup.com/



-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] RegisterProduct Action

[Arthur Curvello]

I`m having problems with regOwner and regCompany, these are not been added by 
msi installer automatically. What should I do?
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Documenting Wix Code

[dB.]

We use doxygen to document source code. We treat wix installers as any
other source code. Hence we'd like to generate some form of HTML
documentation out of it. It could be Features and Components to start
with comments, descriptions, etc. Maybe just generate standard VS xml
documentation?

 

Anyone is already doing this? 

 

Thx

dB.

 

-dB.

dblock.org   / foodcandy.com
 

 

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] File overwriting rules

[Markus Kuehni]

Hi
 
I'm currently strugling to understand file overwriting rules in different
scenarios. (I know this is somewhat off WiX topic and more general MSI
knowledge - but then what isn't? :) 
 
I understand the REINSTALLMODE property controls when components do
overwrite one another or not.  
http://msdn2.microsoft.com/en-us/library/aa371182.aspx
 
So if I want to be able do do 'copy&paste' installs (allowing downgrades!)
I'd probably include 
 

 
But I can only do so globally, right?! 
 
Except for Component/@NeverOverwrite I habe no means to control this on
individual components, right?
 
Another big question: what happens during repair? 
 
On the above link it says /f has a default mode of 'pecms', but to my
understanding 'e' includes 'p' so this makes no sense. And on the following
page (which is linked from the above) it says /f has 'omus' as the default -
???
http://msdn2.microsoft.com/en-us/library/aa367988(VS.85).aspx
 
Very confused.
 
Background: 
I have a database file, that on install must be copied over an existing one,
even if this is newer.
On the other hand, the same database file must never be overwritten during
repairs, as it now contains user data.
 
Background to the background: 
Prior to an upgrade, the data from the installed db file is dumped (in a
version independant form). 
The presence and "freshness" of the dump is checked using a selfmade custom
action / launch condition. 
The dumped data is later reloaded into the freshly installed database file. 
 
 
Thanks for all help,
Mark
 
 
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Upgrade basis on installdir

[puyo puy]

Hello everyone,
 
As I know if I want to create a MSI setup file to check for existing installed 
product from the system and upgrade to the new installer.  I need to keep the 
UpgradeCode and change the ProductCode.  Every time when user run the latest 
installer, MSI will uninstall the old one and install the new version and you 
will only find one entry in Add/Remove program.
 
How can I create an MSI that will check the current installed product's 
location, when the new version going to install the same location as existing 
path, I will treat as upgrade(uninstall then install the new one with the 
existing path).  But if it install different location and I will treat as new 
install.
 
Example.
 
MyProduct Version1.0 installed in c:\PathA.  MyProduct Version1.5 installed in 
c:\PathB.  For my new installer MyProduct Version 2.0, if user going to install 
it in c:\PathA or c:\PathB, my new installer should treat as upgrade and it 
will uninstall c:\PathA(or c:\PathB, depend on where the new installdir).  And 
user should see 2 entries in Add/Remove Program.  If user install Version 2.0 
in c:\PathC, the new installer should treat it as new install and he/she should 
see 3 entries in Add/Remove Program.
 
Any help is much appreciated.
Puyopuy


  Get the name you always wanted with the new y7mail email address.
www.yahoo7.com.au/y7mail

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users