[WiX-users] MSI returns 1606 Could not access location

2007-10-30 Thread Davut Karabay

Hi,

I run my insaller (e.g. msiexec /i XYZ.msi). Select a network path to install 
(e.g. \\somecomputer\someshare\installdir). Product is installed with success. 
Now delete the network path. Run the installer again. It returns 1606 saying 
that could not access the network location. Installer is stuck. Can't uninstall 
or repair. Is this by design? Can I handle it differently?

Thanks,
Davut
_
Boo! Scare away worms, viruses and so much more! Try Windows Live OneCare!
http://onecare.live.com/standard/en-us/purchase/trial.aspx?s_cid=wl_hotmailnews
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] adding mimemap to Webvirtualdir

2007-10-30 Thread [EMAIL PROTECTED]
Hi all,

I want to know how the iis:mimemap tag works, it seems to need an id but do not 
know how to add an MIME element although in the helpfile is written that it 
schould be child of Wix tag.

Second thing is that I want to add a wildcard mime (after I know how to add a 
MIME to a webvirtualdir) like 
„*,C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll,0,All or is 
it better to call a vbscript instead?

 

Thanks Peter

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Maintenance modes (Might be related to old UAC Prompt Required thread, April 2007)

2007-10-30 Thread Anthony Wieser
It gets even stranger.

For some reason, it does uninstall properly when I start the msi from an
admin command prompt like this:
msiexec /i setup.msi /l*vx admin.log

but if I start it from a non admin account like this:
msiexec /i setuprip.msi /l*vx nonadmin.log

it leaves behind the items an admin can't remove.

I also notice in the logs, I have these lines in the admin.log file:
MSI (s) (10:1C) [10:47:56:521]: PROPERTY CHANGE: Modifying CostingComplete
property. Its current value is '0'. Its new value: '1'.
MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2:  3: BindImage
MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2:  3: ProgId
MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2:  3: PublishComponent
MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2:  3: SelfReg
MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2:  3: Extension
MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2:  3: Font
MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2:  3: Class
MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2727 2:
MSI (s) (10:1C) [10:47:56:536]: Note: 1: 2727 2:
MSI (s) (10:1C) [10:47:56:536]: PROPERTY CHANGE: Modifying REMOVE property.
Its current value is 'DesktopShortcut,ProductFeature'. Its new value: 'ALL'.
Action ended 10:47:56: InstallValidate. Return value 1.


The non admin log is missing the modify of the remove property.

I'm using an install sequence based on the wix UI specified like this:
  Property Id=WixUI_Mode Value=InstallDir /

I also notice that in the admin log I have this:
MSI (c) (64:0C) [10:47:51:357]: MSI_LUA: Setting AdminUser property to 1
because this is the client or the user has already permitted elevation
MSI (c) (64:0C) [10:47:51:357]: MSI_LUA: Setting MsiRunningElevated property
to 1 because the install is already running elevated.
MSI (c) (64:0C) [10:47:51:357]: PROPERTY CHANGE: Adding MsiRunningElevated
property. Its value is '1'.
MSI (c) (64:0C) [10:47:51:357]: PROPERTY CHANGE: Adding Privileged property.
Its value is '1'.

while in the non-admin it says:
*
MSI (s) (10:3C) [10:33:37:592]: MSI_LUA: Credential prompt is not required
at this point, product is managed and deployment compliant
**
MSI (s) (10:3C) [10:33:37:654]: MSI_LUA: Setting AdminUser property to 1
because the product is already installed managed and per-machine
MSI (s) (10:3C) [10:33:37:654]: PROPERTY CHANGE: Adding AdminUser property.
Its value is '1'.
MSI (s) (10:3C) [10:33:37:654]: MSI_LUA: Setting MsiRunningElevated property
to 1 because the install is already running elevated.
MSI (s) (10:3C) [10:33:37:654]: PROPERTY CHANGE: Adding MsiRunningElevated
property. Its value is '1'.
MSI (s) (10:3C) [10:33:37:654]: PROPERTY CHANGE: Adding Privileged property.
Its value is '1'.

So it looks like it won't do it because it hasn't elevated, which makes
sense, because it's a per machine install.

So, it's looking like it's not really a WiX problem, but more of an MSI
problem.

Any ideas?

Anthony Wieser
Wieser Software Ltd
- Original Message - 
From: Anthony Wieser [EMAIL PROTECTED]
To: wix-users@lists.sourceforge.net
Sent: Tuesday, October 30, 2007 6:47 AM
Subject: Re: [WiX-users] Maintenance modes


 From: Richard [EMAIL PROTECTED]
 Sent: Monday, October 29, 2007 9:40 PM
 Subject: Re: [WiX-users] Maintenance modes



 In article [EMAIL PROTECTED],
Anthony Wieser [EMAIL PROTECTED]  writes:

 For some reason my msi file is bringing up the maintenance mode when I
 double click it.

 This means its already installed.

 1.  How do I make sure that only remove is supported.
 I've already set the property ARPNOMODIFY like this:
   Property Id=ARPNOMODIFY Value=1 /
 but I've done it in a UI block.  Is that wrong?

 Put it inside the Product tag.
 Turns out I got this from the WixUI_InstallDir.wxs file I based it on.
 The
 property seems to be in the right place when I look at the file in Orcas.


 Secondly, if this is expected behavior, any ideas why when I click the
 remove button, everything in my install disappears, except for the
 entries
 under add remove programs?

 It sounds like you've corrupted Add/Remove Programs somehow.  You can
 use the msizap utility to make A/RP forget about your product, but
 use this only as a last resort.

 I don't think that's what's going on, because I can still remove the
 program
 from ARP afterwards, even though most of the install is gone.

 Trawling through the UI sources, I found this in VerifyReadDlg.wxs:
Control Id=Remove Type=PushButton X=236 Y=243
 Width=56 Height=17 Hidden=yes Text=!(loc.VerifyReadyDlgRemove)
Condition Action=showWixUI_InstallMode =
 Remove/Condition
Publish Event=Remove
 Value=All![CDATA[OutOfDiskSpace  1]]/Publish
 [snip...]
/Control

 However, the msi documentation says the argument for remove is:
 A string that is either the name of the feature or ALL.

 Does it matter that the case is wrong?

 It could be a problem, but its hard to say without debugging it myself
 in 

[WiX-users] Install a Font

2007-10-30 Thread Craig0ss

Hi

I need my installer to install the font Wingdings3 on install

Any ideas?

Thanks
-- 
View this message in context: 
http://www.nabble.com/Install-a-Font-tf4717844.html#a13486672
Sent from the wix-users mailing list archive at Nabble.com.


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] WiX Localization - One Installer to support multiple Languages

2007-10-30 Thread Dana Gutride
The recommended way to do this is to create language transforms and then
call the msi from a setup.exe bootstrapper which will pass the correct
transform name along as a command line parameter.  You'd have to add a
dialog in the bootstrapper to choose the language or include the logic to
determine the language of the OS.

There is no supported way to do this without a bootstrapper (or forcing the
user to include the transform name on the command line).  This link
describes an undocumented ability of windows installer that might work for
you:
http://www.installsite.org/pages/en/msi/articles/embeddedlang/index.htm

Dana

On 10/30/07, Sankaranarayanan [EMAIL PROTECTED] wrote:

 Hi,

 Currently I am creating Localized WiX installers based on the steps
 mentioned @ http://www.tramontana.co.hu/wix/lesson2.php#2.4 (WixUI
 Customization and Localization Combined).

 Using those steps - I am able to create one installer for specific
 language.

 Is there a way to link the wixobj files with different localized language
 files in the same installer. I would like to have only one installer and its
 UI should be displayed based on the Language of the Users  Operating System.
 If the Operating System language isn't one of the defeault supported
 language of the MSI - it should fall back to en-US. Can all supported
 languages WixUI_XX-XX.wxl file be integrated into the same installer.

 Thanks,
 Sankaranarayanan MG


   ___
 Yahoo! Answers - Got a question? Someone out there knows the answer. Try
 it
 now.
 http://uk.answers.yahoo.com/

 -
 This SF.net email is sponsored by: Splunk Inc.
 Still grepping through log files to find problems?  Stop.
 Now Search log events and configuration files using AJAX and a browser.
 Download your FREE copy of Splunk now  http://get.splunk.com/
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Checkbox does not recognize when it is checked

2007-10-30 Thread xyavier

No it isn't. It will work if I put the box in the UI during the setup and
have it checked. If it is placed in the uninstall sequence however it will
not acknowledge the box is checked. 



Bob Arnson-6 wrote:
 
 xyavier wrote:
 boB, It does however bring up my UI when someone clicks the change button
 in
 the ARP. My plan was to remove the Remove button so the user would be
 forced to use my UI which gives them the option to either remove or
 repair. 
 So, under this situation is there any way to allow them to check the box
 at
 the time of removal.
   
 
 Sure. Is it not working?
 
 -- 
 sig://boB
 http://joyofsetup.com/
 
 
 
 -
 This SF.net email is sponsored by: Splunk Inc.
 Still grepping through log files to find problems?  Stop.
 Now Search log events and configuration files using AJAX and a browser.
 Download your FREE copy of Splunk now  http://get.splunk.com/
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users
 
 

-- 
View this message in context: 
http://www.nabble.com/Checkbox-does-not-recognize-when-it-is-checked-tf4683976.html#a13488280
Sent from the wix-users mailing list archive at Nabble.com.


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] disabling the features aapeared in the selection tree based on their installation condition.

2007-10-30 Thread shambhu kumar

hi
in my product the installation takes place in many modes.
there z a set of features in this product.
each mode support some mandatory features and some optional fearture.
there are some feartures which are not supported in some mode decided by
their installation condition.
i used absent=disallow to specify mandatory and optional feature.

now i want to disable the showing of fetures in selection tree used in
custom setup if this feature is not supported in tis particular mode(i.e its
installation condition is false).

can u suggest me the way to do this. 
thanx 

-- 
View this message in context: 
http://www.nabble.com/disabling-the-features-aapeared-in-the-selection-tree-based-on-their-installation-condition.-tf4718617.html#a13489176
Sent from the wix-users mailing list archive at Nabble.com.


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Maintenance modes SOLVED!

2007-10-30 Thread Anthony Wieser
It turns out, the problem was because I was installing a component based on 
the existence of a file on the end users computer, like this.
Property Id=DEPFOUND
  DirectorySearch Id=deppath Path=[SystemFolder]
FileSearch Id=depfile Name=depfile.dll /
  /DirectorySearch
/Property

and then later

   Feature Id=SetDEP Title=Enable DEP Level=0
  ComponentRef Id=DepComponent/
  Condition Level=1DEPFOUND/Condition
/Feature

Unfortunately, not marking the property secure caused the behavior shown in 
my previous messages.

Thanks to Bob, for this
http://www.joyofsetup.com/2007/05/30/feature-conditions-and-ui/
which led me in the right direction.

I had been using a similar idiom for desktop shortcuts on a tick box, but 
they didn't seem to need secure.  Perhaps it's because they defaulted to on 
instead of off.

Anthony Wieser
Wieser Software Ltd


- Original Message - 
From: Anthony Wieser [EMAIL PROTECTED]
To: wix-users@lists.sourceforge.net
Sent: Tuesday, October 30, 2007 11:19 AM
Subject: Re: [WiX-users] Maintenance modes (Might be related to old 
UACPrompt Required thread, April 2007)


 It gets even stranger.

 For some reason, it does uninstall properly when I start the msi from an
 admin command prompt like this:
 msiexec /i setup.msi /l*vx admin.log

 but if I start it from a non admin account like this:
 msiexec /i setuprip.msi /l*vx nonadmin.log

 it leaves behind the items an admin can't remove.

 I also notice in the logs, I have these lines in the admin.log file:
 MSI (s) (10:1C) [10:47:56:521]: PROPERTY CHANGE: Modifying CostingComplete
 property. Its current value is '0'. Its new value: '1'.
 MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2:  3: BindImage
 MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2:  3: ProgId
 MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2:  3: PublishComponent
 MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2:  3: SelfReg
 MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2:  3: Extension
 MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2:  3: Font
 MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2:  3: Class
 MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2727 2:
 MSI (s) (10:1C) [10:47:56:536]: Note: 1: 2727 2:
 MSI (s) (10:1C) [10:47:56:536]: PROPERTY CHANGE: Modifying REMOVE 
 property.
 Its current value is 'DesktopShortcut,ProductFeature'. Its new value: 
 'ALL'.
 Action ended 10:47:56: InstallValidate. Return value 1.


 The non admin log is missing the modify of the remove property.

 I'm using an install sequence based on the wix UI specified like this:
  Property Id=WixUI_Mode Value=InstallDir /

 I also notice that in the admin log I have this:
 MSI (c) (64:0C) [10:47:51:357]: MSI_LUA: Setting AdminUser property to 1
 because this is the client or the user has already permitted elevation
 MSI (c) (64:0C) [10:47:51:357]: MSI_LUA: Setting MsiRunningElevated 
 property
 to 1 because the install is already running elevated.
 MSI (c) (64:0C) [10:47:51:357]: PROPERTY CHANGE: Adding MsiRunningElevated
 property. Its value is '1'.
 MSI (c) (64:0C) [10:47:51:357]: PROPERTY CHANGE: Adding Privileged 
 property.
 Its value is '1'.

 while in the non-admin it says:
 *
 MSI (s) (10:3C) [10:33:37:592]: MSI_LUA: Credential prompt is not required
 at this point, product is managed and deployment compliant
 **
 MSI (s) (10:3C) [10:33:37:654]: MSI_LUA: Setting AdminUser property to 1
 because the product is already installed managed and per-machine
 MSI (s) (10:3C) [10:33:37:654]: PROPERTY CHANGE: Adding AdminUser 
 property.
 Its value is '1'.
 MSI (s) (10:3C) [10:33:37:654]: MSI_LUA: Setting MsiRunningElevated 
 property
 to 1 because the install is already running elevated.
 MSI (s) (10:3C) [10:33:37:654]: PROPERTY CHANGE: Adding MsiRunningElevated
 property. Its value is '1'.
 MSI (s) (10:3C) [10:33:37:654]: PROPERTY CHANGE: Adding Privileged 
 property.
 Its value is '1'.

 So it looks like it won't do it because it hasn't elevated, which makes
 sense, because it's a per machine install.

 So, it's looking like it's not really a WiX problem, but more of an MSI
 problem.

 Any ideas?

 Anthony Wieser
 Wieser Software Ltd
 - Original Message - 
 From: Anthony Wieser [EMAIL PROTECTED]
 To: wix-users@lists.sourceforge.net
 Sent: Tuesday, October 30, 2007 6:47 AM
 Subject: Re: [WiX-users] Maintenance modes


 From: Richard [EMAIL PROTECTED]
 Sent: Monday, October 29, 2007 9:40 PM
 Subject: Re: [WiX-users] Maintenance modes



 In article [EMAIL PROTECTED],
Anthony Wieser [EMAIL PROTECTED]  writes:

 For some reason my msi file is bringing up the maintenance mode when I
 double click it.

 This means its already installed.

 1.  How do I make sure that only remove is supported.
 I've already set the property ARPNOMODIFY like this:
   Property Id=ARPNOMODIFY Value=1 /
 but I've done it in a UI block.  Is that wrong?

 Put it inside the Product tag.
 Turns out I got this from the WixUI_InstallDir.wxs file I based it 

Re: [WiX-users] Maintenance modes SOLVED!

2007-10-30 Thread Kelly Leahy
Would adding 'Or Installed' to the condition work as well?  Wouldn't it 
then remove the file if it's there, and leave it if it isn't?

Kelly




Anthony Wieser [EMAIL PROTECTED]

Sent by: [EMAIL PROTECTED]
10/30/2007 08:00 AM

To
wix-users@lists.sourceforge.net
cc

Subject
Re: [WiX-users] Maintenance modes  SOLVED!






It turns out, the problem was because I was installing a component based 
on 
the existence of a file on the end users computer, like this.
Property Id=DEPFOUND
  DirectorySearch Id=deppath Path=[SystemFolder]
FileSearch Id=depfile Name=depfile.dll /
  /DirectorySearch
/Property

and then later

   Feature Id=SetDEP Title=Enable DEP Level=0
  ComponentRef Id=DepComponent/
  Condition Level=1DEPFOUND/Condition
/Feature

Unfortunately, not marking the property secure caused the behavior shown 
in 
my previous messages.

Thanks to Bob, for this
http://www.joyofsetup.com/2007/05/30/feature-conditions-and-ui/
which led me in the right direction.

I had been using a similar idiom for desktop shortcuts on a tick box, but 
they didn't seem to need secure.  Perhaps it's because they defaulted to 
on 
instead of off.

Anthony Wieser
Wieser Software Ltd


- Original Message - 
From: Anthony Wieser [EMAIL PROTECTED]
To: wix-users@lists.sourceforge.net
Sent: Tuesday, October 30, 2007 11:19 AM
Subject: Re: [WiX-users] Maintenance modes (Might be related to old 
UACPrompt Required thread, April 2007)


 It gets even stranger.

 For some reason, it does uninstall properly when I start the msi from an
 admin command prompt like this:
 msiexec /i setup.msi /l*vx admin.log

 but if I start it from a non admin account like this:
 msiexec /i setuprip.msi /l*vx nonadmin.log

 it leaves behind the items an admin can't remove.

 I also notice in the logs, I have these lines in the admin.log file:
 MSI (s) (10:1C) [10:47:56:521]: PROPERTY CHANGE: Modifying 
CostingComplete
 property. Its current value is '0'. Its new value: '1'.
 MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2:  3: BindImage
 MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2:  3: ProgId
 MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2:  3: PublishComponent
 MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2:  3: SelfReg
 MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2:  3: Extension
 MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2:  3: Font
 MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2:  3: Class
 MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2727 2:
 MSI (s) (10:1C) [10:47:56:536]: Note: 1: 2727 2:
 MSI (s) (10:1C) [10:47:56:536]: PROPERTY CHANGE: Modifying REMOVE 
 property.
 Its current value is 'DesktopShortcut,ProductFeature'. Its new value: 
 'ALL'.
 Action ended 10:47:56: InstallValidate. Return value 1.


 The non admin log is missing the modify of the remove property.

 I'm using an install sequence based on the wix UI specified like this:
  Property Id=WixUI_Mode Value=InstallDir /

 I also notice that in the admin log I have this:
 MSI (c) (64:0C) [10:47:51:357]: MSI_LUA: Setting AdminUser property to 1
 because this is the client or the user has already permitted elevation
 MSI (c) (64:0C) [10:47:51:357]: MSI_LUA: Setting MsiRunningElevated 
 property
 to 1 because the install is already running elevated.
 MSI (c) (64:0C) [10:47:51:357]: PROPERTY CHANGE: Adding 
MsiRunningElevated
 property. Its value is '1'.
 MSI (c) (64:0C) [10:47:51:357]: PROPERTY CHANGE: Adding Privileged 
 property.
 Its value is '1'.

 while in the non-admin it says:
 *
 MSI (s) (10:3C) [10:33:37:592]: MSI_LUA: Credential prompt is not 
required
 at this point, product is managed and deployment compliant
 **
 MSI (s) (10:3C) [10:33:37:654]: MSI_LUA: Setting AdminUser property to 1
 because the product is already installed managed and per-machine
 MSI (s) (10:3C) [10:33:37:654]: PROPERTY CHANGE: Adding AdminUser 
 property.
 Its value is '1'.
 MSI (s) (10:3C) [10:33:37:654]: MSI_LUA: Setting MsiRunningElevated 
 property
 to 1 because the install is already running elevated.
 MSI (s) (10:3C) [10:33:37:654]: PROPERTY CHANGE: Adding 
MsiRunningElevated
 property. Its value is '1'.
 MSI (s) (10:3C) [10:33:37:654]: PROPERTY CHANGE: Adding Privileged 
 property.
 Its value is '1'.

 So it looks like it won't do it because it hasn't elevated, which makes
 sense, because it's a per machine install.

 So, it's looking like it's not really a WiX problem, but more of an MSI
 problem.

 Any ideas?

 Anthony Wieser
 Wieser Software Ltd
 - Original Message - 
 From: Anthony Wieser [EMAIL PROTECTED]
 To: wix-users@lists.sourceforge.net
 Sent: Tuesday, October 30, 2007 6:47 AM
 Subject: Re: [WiX-users] Maintenance modes


 From: Richard [EMAIL PROTECTED]
 Sent: Monday, October 29, 2007 9:40 PM
 Subject: Re: [WiX-users] Maintenance modes



 In article [EMAIL PROTECTED],
Anthony Wieser [EMAIL PROTECTED]  writes:

 For some reason my msi file is bringing up the maintenance mode when 
I
 double click it.

 This 

[WiX-users] XmlConfig wix version 2.0.5325.0

2007-10-30 Thread Overlever

If I add the XmlConfig in my wxs my 2 customactions no longer work because
the customaction.Installstate can not be found. When I remove the XmlConfig
element everything is fine.

I need to delete and otherwise manipulate the web config and XmlFile is not
enough.

Here is the element:
XmlConfig Id=someid
 File=[thewebdir]Web.config
 Action=delete
 Sequence=1
 VerifyPath=//configuration/myconfiguration
 Name=myconfiguration
 ElementPath=//configuration/

Any one?

-- 
View this message in context: 
http://www.nabble.com/XmlConfig-wix-version-2.0.5325.0-tf4719153.html#a13490732
Sent from the wix-users mailing list archive at Nabble.com.


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Maintenance modes SOLVED!

2007-10-30 Thread Anthony Wieser
It's not my file.  I'm modifying a registry entry based on whether I find a 
file in the system folder.

Anthony Wieser
Wieser Software Ltd

  - Original Message - 
  From: Kelly Leahy 
  To: Anthony Wieser 
  Cc: wix-users@lists.sourceforge.net ; [EMAIL PROTECTED] 
  Sent: Tuesday, October 30, 2007 3:18 PM
  Subject: Re: [WiX-users] Maintenance modes SOLVED!



  Would adding 'Or Installed' to the condition work as well?  Wouldn't it then 
remove the file if it's there, and leave it if it isn't? 

  Kelly 



Anthony Wieser [EMAIL PROTECTED] 

Sent by: [EMAIL PROTECTED] 
10/30/2007 08:00 AM 
   To wix-users@lists.sourceforge.net  
  cc  
  Subject Re: [WiX-users] Maintenance modes  SOLVED! 

  

   



  It turns out, the problem was because I was installing a component based on 
  the existence of a file on the end users computer, like this.
 Property Id=DEPFOUND
   DirectorySearch Id=deppath Path=[SystemFolder]
 FileSearch Id=depfile Name=depfile.dll /
   /DirectorySearch
 /Property

  and then later

Feature Id=SetDEP Title=Enable DEP Level=0
   ComponentRef Id=DepComponent/
   Condition Level=1DEPFOUND/Condition
 /Feature

  Unfortunately, not marking the property secure caused the behavior shown in 
  my previous messages.

  Thanks to Bob, for this
  http://www.joyofsetup.com/2007/05/30/feature-conditions-and-ui/
  which led me in the right direction.

  I had been using a similar idiom for desktop shortcuts on a tick box, but 
  they didn't seem to need secure.  Perhaps it's because they defaulted to on 
  instead of off.

  Anthony Wieser
  Wieser Software Ltd


  - Original Message - 
  From: Anthony Wieser [EMAIL PROTECTED]
  To: wix-users@lists.sourceforge.net
  Sent: Tuesday, October 30, 2007 11:19 AM
  Subject: Re: [WiX-users] Maintenance modes (Might be related to old 
  UACPrompt Required thread, April 2007)


   It gets even stranger.
  
   For some reason, it does uninstall properly when I start the msi from an
   admin command prompt like this:
   msiexec /i setup.msi /l*vx admin.log
  
   but if I start it from a non admin account like this:
   msiexec /i setuprip.msi /l*vx nonadmin.log
  
   it leaves behind the items an admin can't remove.
  
   I also notice in the logs, I have these lines in the admin.log file:
   MSI (s) (10:1C) [10:47:56:521]: PROPERTY CHANGE: Modifying CostingComplete
   property. Its current value is '0'. Its new value: '1'.
   MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2:  3: BindImage
   MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2:  3: ProgId
   MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2:  3: PublishComponent
   MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2:  3: SelfReg
   MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2:  3: Extension
   MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2:  3: Font
   MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2:  3: Class
   MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2727 2:
   MSI (s) (10:1C) [10:47:56:536]: Note: 1: 2727 2:
   MSI (s) (10:1C) [10:47:56:536]: PROPERTY CHANGE: Modifying REMOVE 
   property.
   Its current value is 'DesktopShortcut,ProductFeature'. Its new value: 
   'ALL'.
   Action ended 10:47:56: InstallValidate. Return value 1.
  
  
   The non admin log is missing the modify of the remove property.
  
   I'm using an install sequence based on the wix UI specified like this:
Property Id=WixUI_Mode Value=InstallDir /
  
   I also notice that in the admin log I have this:
   MSI (c) (64:0C) [10:47:51:357]: MSI_LUA: Setting AdminUser property to 1
   because this is the client or the user has already permitted elevation
   MSI (c) (64:0C) [10:47:51:357]: MSI_LUA: Setting MsiRunningElevated 
   property
   to 1 because the install is already running elevated.
   MSI (c) (64:0C) [10:47:51:357]: PROPERTY CHANGE: Adding MsiRunningElevated
   property. Its value is '1'.
   MSI (c) (64:0C) [10:47:51:357]: PROPERTY CHANGE: Adding Privileged 
   property.
   Its value is '1'.
  
   while in the non-admin it says:
   *
   MSI (s) (10:3C) [10:33:37:592]: MSI_LUA: Credential prompt is not required
   at this point, product is managed and deployment compliant
   **
   MSI (s) (10:3C) [10:33:37:654]: MSI_LUA: Setting AdminUser property to 1
   because the product is already installed managed and per-machine
   MSI (s) (10:3C) [10:33:37:654]: PROPERTY CHANGE: Adding AdminUser 
   property.
   Its value is '1'.
   MSI (s) (10:3C) [10:33:37:654]: MSI_LUA: Setting MsiRunningElevated 
   property
   to 1 because the install is already running elevated.
   MSI (s) (10:3C) [10:33:37:654]: PROPERTY CHANGE: Adding MsiRunningElevated
   property. Its value is '1'.
   MSI (s) (10:3C) [10:33:37:654]: PROPERTY CHANGE: Adding Privileged 
   property.
   Its value is '1'.
  
   So it looks like it won't do it because it hasn't elevated, which makes
   sense, because it's a per 

Re: [WiX-users] Install a Font

2007-10-30 Thread Bob Arnson
Craig0ss wrote:
 I need my installer to install the font Wingdings3 on install
   

Check with its developer to see if they provide a redist: 
http://www.ascendercorp.com/msfonts/wingdings3.html.

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



-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] disabling the features aapeared in the selection tree based on their installation condition.

2007-10-30 Thread Bob Arnson
shambhu kumar wrote:
 now i want to disable the showing of fetures in selection tree used in
 custom setup if this feature is not supported in tis particular mode(i.e its
 installation condition is false).
   

The selection tree control doesn't support that -- features can only be 
hidden, not disabled, in the control.

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



-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Checkbox does not recognize when it is checked

2007-10-30 Thread Bob Arnson
xyavier wrote:
 No it isn't. It will work if I put the box in the UI during the setup and
 have it checked. If it is placed in the uninstall sequence however it will
 not acknowledge the box is checked. 
   

How are you using the check box value?

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



-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Maintenance modes SOLVED!

2007-10-30 Thread Kelly Leahy
I just meant that the component wouldn't be excluded on maintenance if you 
had 'or Installed' regardless of the value of DEPFOUND, but perhaps it 
wouldn't work.

Kelly




Anthony Wieser [EMAIL PROTECTED]

Sent by: [EMAIL PROTECTED]
10/30/2007 08:41 AM

To
wix-users@lists.sourceforge.net
cc

Subject
Re: [WiX-users] Maintenance modes  SOLVED!






It's not my file.  I'm modifying a registry entry based on whether I find 
a file in the system folder.
 
Anthony Wieser
Wieser Software Ltd
 
- Original Message - 
From: Kelly Leahy 
To: Anthony Wieser 
Cc: wix-users@lists.sourceforge.net ; 
[EMAIL PROTECTED] 
Sent: Tuesday, October 30, 2007 3:18 PM
Subject: Re: [WiX-users] Maintenance modes SOLVED!


Would adding 'Or Installed' to the condition work as well?  Wouldn't it 
then remove the file if it's there, and leave it if it isn't? 

Kelly 



Anthony Wieser [EMAIL PROTECTED] 

Sent by: [EMAIL PROTECTED] 
10/30/2007 08:00 AM 


To
wix-users@lists.sourceforge.net 
cc

Subject
Re: [WiX-users] Maintenance modes  SOLVED!








It turns out, the problem was because I was installing a component based 
on 
the existence of a file on the end users computer, like this.
   Property Id=DEPFOUND
 DirectorySearch Id=deppath Path=[SystemFolder]
   FileSearch Id=depfile Name=depfile.dll /
 /DirectorySearch
   /Property

and then later

  Feature Id=SetDEP Title=Enable DEP Level=0
 ComponentRef Id=DepComponent/
 Condition Level=1DEPFOUND/Condition
   /Feature

Unfortunately, not marking the property secure caused the behavior shown 
in 
my previous messages.

Thanks to Bob, for this
http://www.joyofsetup.com/2007/05/30/feature-conditions-and-ui/
which led me in the right direction.

I had been using a similar idiom for desktop shortcuts on a tick box, but 
they didn't seem to need secure.  Perhaps it's because they defaulted to 
on 
instead of off.

Anthony Wieser
Wieser Software Ltd


- Original Message - 
From: Anthony Wieser [EMAIL PROTECTED]
To: wix-users@lists.sourceforge.net
Sent: Tuesday, October 30, 2007 11:19 AM
Subject: Re: [WiX-users] Maintenance modes (Might be related to old 
UACPrompt Required thread, April 2007)


 It gets even stranger.

 For some reason, it does uninstall properly when I start the msi from an
 admin command prompt like this:
 msiexec /i setup.msi /l*vx admin.log

 but if I start it from a non admin account like this:
 msiexec /i setuprip.msi /l*vx nonadmin.log

 it leaves behind the items an admin can't remove.

 I also notice in the logs, I have these lines in the admin.log file:
 MSI (s) (10:1C) [10:47:56:521]: PROPERTY CHANGE: Modifying 
CostingComplete
 property. Its current value is '0'. Its new value: '1'.
 MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2:  3: BindImage
 MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2:  3: ProgId
 MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2:  3: PublishComponent
 MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2:  3: SelfReg
 MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2:  3: Extension
 MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2:  3: Font
 MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2:  3: Class
 MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2727 2:
 MSI (s) (10:1C) [10:47:56:536]: Note: 1: 2727 2:
 MSI (s) (10:1C) [10:47:56:536]: PROPERTY CHANGE: Modifying REMOVE 
 property.
 Its current value is 'DesktopShortcut,ProductFeature'. Its new value: 
 'ALL'.
 Action ended 10:47:56: InstallValidate. Return value 1.


 The non admin log is missing the modify of the remove property.

 I'm using an install sequence based on the wix UI specified like this:
  Property Id=WixUI_Mode Value=InstallDir /

 I also notice that in the admin log I have this:
 MSI (c) (64:0C) [10:47:51:357]: MSI_LUA: Setting AdminUser property to 1
 because this is the client or the user has already permitted elevation
 MSI (c) (64:0C) [10:47:51:357]: MSI_LUA: Setting MsiRunningElevated 
 property
 to 1 because the install is already running elevated.
 MSI (c) (64:0C) [10:47:51:357]: PROPERTY CHANGE: Adding 
MsiRunningElevated
 property. Its value is '1'.
 MSI (c) (64:0C) [10:47:51:357]: PROPERTY CHANGE: Adding Privileged 
 property.
 Its value is '1'.

 while in the non-admin it says:
 *
 MSI (s) (10:3C) [10:33:37:592]: MSI_LUA: Credential prompt is not 
required
 at this point, product is managed and deployment compliant
 **
 MSI (s) (10:3C) [10:33:37:654]: MSI_LUA: Setting AdminUser property to 1
 because the product is already installed managed and per-machine
 MSI (s) (10:3C) [10:33:37:654]: PROPERTY CHANGE: Adding AdminUser 
 property.
 Its value is '1'.
 MSI (s) (10:3C) [10:33:37:654]: MSI_LUA: Setting MsiRunningElevated 
 property
 to 1 because the install is already running elevated.
 MSI (s) (10:3C) [10:33:37:654]: PROPERTY CHANGE: Adding 
MsiRunningElevated
 property. Its value is '1'.
 MSI (s) (10:3C) [10:33:37:654]: PROPERTY CHANGE: Adding Privileged 
 property.
 Its value is '1'.

 So it looks like it won't do 

Re: [WiX-users] MMC Snapin

2007-10-30 Thread Levon Levonian
Hi. Thanks for the reply.

But isn't it true that the DLL itself should be registered, since the
.MSC acts as a configuration/shortcut to the actual snap-in, which
resides in a DLL. I deployed the MSC, but I am just getting Snap-in
failed to initialize and Snap-in creation failed messages when I run
it.
Anyway, I tried to register the DLL manually with RegAsm mySnapIn.dll
/codebase, but I am getting an Action canceled page in the area where
snap-in should be displayed.

Any comments are appreciated.


-Original Message-
From: Chad Petersen [mailto:[EMAIL PROTECTED] 
Sent: Monday, October 29, 2007 9:36
To: Levon Levonian; Rob Mensching
Cc: wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] MMC Snapin

We use an MMC snap-in in one of our applications. I may be simplifying
this too much, but entry point to a Snap-In is the .MSC file. We deposit
the .MSC in the Deploy directory of choice and create a shortcut to the
.MSC.

Component Id=DeployMSCComp
Guid=1ED23462-B5B7-42af-B86A-BF4CB1E86BB6
File Id=DeployMSC Name=INTERL~1.MSC
LongName=Interlinq E3 Deployment Manager.msc src=.\Data\Interlinq E3
Deployment Manager 2.6.msc Vital=yes KeyPath=yes DiskId=1
Shortcut Id=DeployMSCShortCut
Directory=MENUINTERLINQ Name=E3Depl~2 LongName=Interlinq E3
Deployment Manager Icon=DEPLOYICON IconIndex=0 Show=normal
WorkingDirectory=DEPLOYDIR /
/File
/Component

The rest of the supporting DLLs and scripts, etc. that are needed by the
Snap-In also go in the same folder and a registry key association is
made to the resource dll that references the MSC file.

File Id=E3DeployManagerResources_Dll Name=E3R~1.dll
LongName=E3DeployManagerResource.dll
src=.\Data\E3DeployManagerResource.dll Vital=yes DiskId=1/
Registry Id=DeployLocationKey Root=HKCU
Key=Software\HarlandFS\E3Deploy Name=MSC Value=[#DeployMSC]
Type=string/

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Levon
Levonian
Sent: Friday, October 26, 2007 4:31 PM
To: Rob Mensching
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] MMC Snapin

OK, I got the extension name, but:
None of the WiX v3 packages contains WixMMCExtension, I only found it in
v2, but v3 does not load v2 extensions (Error   The extension
'C:\Program Files\Windows Installer XML v3\bin\WixMMCExtension.dll'
could not be loaded.candle.exe)

Anybody has a working example for Snap-in deployment?

Thanks!


-Original Message-
From: Rob Mensching [mailto:[EMAIL PROTECTED] 
Sent: Thursday, October 25, 2007 19:57
To: Levon Levonian
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] MMC Snapin

There is an extension in WiX v3 that handles much of the authoring work 
for you.

Levon Levonian wrote:

 Hi All,

  

 Is there a (easy) way to deploy an MMC Snap-in?


**
READER BEWARE: Unencrypted, unsigned Internet e-mail is inherently insecure.

Internet messages may be corrupted, incomplete, misdirected or may
incorrectly identify the sender. Therefore, nothing in this message or
attachments may be considered legally binding.

THIS MESSAGE IS ONLY INTENDED FOR THE USE OF THE INDIVIDUAL
OR ENTITY TO WHICH IT IS ADDRESSED AND MAY BE PRIVILEGED.

If you are not the intended recipient or their authorized agent, you
may not forward or copy this information and must delete or destroy all
copies of this message and attachments received.

If you have received this communication in error, please notify
Matrikon Inc. by telephone at (780) 448-1010.
**



-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Checkbox does not recognize when it is checked

2007-10-30 Thread Richard

In article [EMAIL PROTECTED],
xyavier [EMAIL PROTECTED]  writes:

 No it isn't. It will work if I put the box in the UI during the setup and
 have it checked. If it is placed in the uninstall sequence however it will
 not acknowledge the box is checked. 

OK, you know there's no such thing as the uninstall sequence, right?
There's a UI sequence that is used when a full UI is shown and there's
an execute sequence that is always used.

Changes to properties are not stored in the MSI during installation;
you have to persist properties elsewhere if you want them to
remember the changed value set during installation at the time of
uninstallation.  A common way to do this is to persist properties into
the registry and use AppSearch to get them back out of the registry
and into a property.

CheckBoxes toggle a property's value between empty and the value
listed in the CheckBox table.  Are you trying to set your property to
something *other* than what's in the CheckBox table?
-- 
The Direct3D Graphics Pipeline -- DirectX 9 draft available for download
  http://www.xmission.com/~legalize/book/download/index.html

Legalize Adulthood! http://blogs.xmission.com/legalize/

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Managed Custom Action using InstallUtilLib.dll

2007-10-30 Thread Richard

In article [EMAIL PROTECTED],
Sankaranarayanan [EMAIL PROTECTED]  writes:

 I am using Managed Custom Action [...]

What is your custom action doing?  The MSDN documentation leads people
to believe that they need managed custom actions for all sorts of
things that the standard actions and tables already cover.
-- 
The Direct3D Graphics Pipeline -- DirectX 9 draft available for download
  http://www.xmission.com/~legalize/book/download/index.html

Legalize Adulthood! http://blogs.xmission.com/legalize/

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Checkbox does not recognize when it is checked

2007-10-30 Thread xyavier

This is how it is set up 

--
Control Id='All_Files' Type='CheckBox' X='10' Y='30' Width='400'
Height='18' Property='DELALL' CheckBoxValue=1 
TextCheck the box to Delete extensibility.dll/Text
/Control

Control Id='RemoveNow' Type='PushButton' X='276' Y='210' Width='90'
Height='18' Default='yes'
Text![CDATA[{\Tahoma10}Remove Now]]/Text
/Control

---

Component Id='MyComponent' Guid='BLah BLah BLah-123456789012'
Condition
   DELALL = 1
/Condition

RemoveFile Id='LogFile' On='uninstall' Name='*.*' /
RemoveFolder Id='TheDir' On='uninstall'/
   
/Component
-


Mark




xyavier wrote:
 
 No it isn't. It will work if I put the box in the UI during the setup and
 have it checked. If it is placed in the uninstall sequence however it will
 not acknowledge the box is checked. 
 
 
 
 Bob Arnson-6 wrote:
 
 xyavier wrote:
 boB, It does however bring up my UI when someone clicks the change
 button in
 the ARP. My plan was to remove the Remove button so the user would be
 forced to use my UI which gives them the option to either remove or
 repair. 
 So, under this situation is there any way to allow them to check the box
 at
 the time of removal.
   
 
 Sure. Is it not working?
 
 -- 
 sig://boB
 http://joyofsetup.com/
 
 
 
 -
 This SF.net email is sponsored by: Splunk Inc.
 Still grepping through log files to find problems?  Stop.
 Now Search log events and configuration files using AJAX and a browser.
 Download your FREE copy of Splunk now  http://get.splunk.com/
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users
 
 
 
 

-- 
View this message in context: 
http://www.nabble.com/Checkbox-does-not-recognize-when-it-is-checked-tf4683976.html#a13491613
Sent from the wix-users mailing list archive at Nabble.com.


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Checkbox does not recognize when it is checked

2007-10-30 Thread xyavier

This is how it is set up

--
Control Id='All_Files' Type='CheckBox' X='10' Y='30' Width='400'
Height='18' Property='DELALL' CheckBoxValue=1 
TextCheck the box to Delete extensibility.dll/Text
/Control

Control Id='RemoveNow' Type='PushButton' X='276' Y='210' Width='90'
Height='18' Default='yes'
Text![CDATA[{\Tahoma10}Remove Now]]/Text
/Control

---

Component Id='MyComponent' Guid='BLah BLah BLah-123456789012'
Condition
   DELALL = 1
/Condition

RemoveFile Id='LogFile' On='uninstall' Name='*.*' /
RemoveFolder Id='TheDir' On='uninstall'/
   
/Component
-


Mark





Bob Arnson-6 wrote:
 
 xyavier wrote:
 No it isn't. It will work if I put the box in the UI during the setup and
 have it checked. If it is placed in the uninstall sequence however it
 will
 not acknowledge the box is checked. 
   
 
 How are you using the check box value?
 
 -- 
 sig://boB
 http://joyofsetup.com/
 
 
 
 -
 This SF.net email is sponsored by: Splunk Inc.
 Still grepping through log files to find problems?  Stop.
 Now Search log events and configuration files using AJAX and a browser.
 Download your FREE copy of Splunk now  http://get.splunk.com/
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users
 
 

-- 
View this message in context: 
http://www.nabble.com/Checkbox-does-not-recognize-when-it-is-checked-tf4683976.html#a13492385
Sent from the wix-users mailing list archive at Nabble.com.


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Managed Custom Action using InstallUtilLib.dll

2007-10-30 Thread Sankaranarayanan
I use custom action for the following operations

1) Read XML Config file and set installer properties
2) Install Device Drivers
3) Loading MOF
4) Setting Windows Service privileges
5) Installing .NET Perf Counters.

etc...

WiX doesn't support these actions by default.

Please let know if you have any approach for the following issue :

I am using Managed Custom Action as details in 
http://blogs.msdn.com/josealmeida/archive/2004/11/08/253831.aspx
This approach works like a charm but I didn't quite like the idea of packaging 
InstallUtilLib.dll file in MSI.

Is there a way to use the InstallUtilLib.dll present in the client machine 
instead of packing it in MSI Binary table as follows
Binary Id=InstallUtil src=$(var.FrameworkPath)\InstallUtilLib.dll /.
(I have a Lauch Condition to check for .NET Framework presence in the client 
machine).

Thanks,
Sankaranarayanan MG

- Original Message 
From: Richard [EMAIL PROTECTED]
To: WiX Users wix-users@lists.sourceforge.net
Cc: [EMAIL PROTECTED]
Sent: Tuesday, 30 October, 2007 10:03:10 AM
Subject: Re: [WiX-users] Managed Custom Action using InstallUtilLib.dll


In article [EMAIL PROTECTED],
Sankaranarayanan [EMAIL PROTECTED]  writes:

 I am using Managed Custom Action [...]

What is your custom action doing?  The MSDN documentation leads people
to believe that they need managed custom actions for all sorts of
things that the standard actions and tables already cover.
-- 
The Direct3D Graphics Pipeline -- DirectX 9 draft available for download
  http://www.xmission.com/~legalize/book/download/index.html

Legalize Adulthood! http://blogs.xmission.com/legalize/


  ___ 
Want ideas for reducing your carbon footprint? Visit Yahoo! For Good  
http://uk.promotions.yahoo.com/forgood/environment.html

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Help with Major Upgrade

2007-10-30 Thread Ted Berg
I am packaging an MSI that I would like to have perform a Major Upgrade
when deployed on a machine with an older version of said package already
installed.

My setup:
* Product Id is set to ----
* Upgrade Code is set to some GUID which does not change
* The Upgrade clause is set to
Upgrade Id=some GUID
UpgradeVersion
  Minimum=$(var.VERSION)
  OnlyDetect=yes
  Property=NEWERVERSIONDETECTED /
UpgradeVersion
  Minimum=1.0.0.0
  IncludeMinimum=yes
  Maximum=$(var.VERSION)
  IncludeMaximum=no
  Property=OLDERVERSIONBEINGUPGRADED /
  /Upgrade

Where var.VERSION is our major.minor.micro.build version number.
* InstallExecuteSequence contains the following entries:
RemoveExistingProducts After=InstallFinalize/

* The package launches an application upon installation.

Scenarios:
* Install version 1 of package, Install version 2 of package.  Version 2
install notices that version 1 is running and asks for it to be shut
down.  User complies and the install completes normally.  Version 2 is
the only package that appears in Add/Remove Programs.
* Install version 1 of package, Install version 2 of package.  When
asked to shut down running copy of version 1, User hits the Exit button.
   Install informs user that their system was not modified and exits.
Both  versions now appear in Add/Remove Programs.  When the application
is next launched it is version 2.

In the second scenario the install of Version 2 should roll back and
exit as the UI implies.  What do I need to do for this to happen?
Failing that how can I prevent scenario 2?

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Sharing a folder with group permissions

2007-10-30 Thread OneReallyCoolApplication

I am trying to share a directory to a group of users rather than a particular
user, i.e. the Administrators group on the local machine
([ComputerName]\Administrators). However, the Permission element within a
FileShare must point to a User. From the Tramontana tutorial, you can set
the User's Name property = Everyone and it'll share the folder under the
Everyone group, but I can't get it to share under any other group (I get a
error saying user not found):

 Component Id=SharedComponent ...
FileShare Id=SharedFileShare Name=MyFolder
Description=MyFolder
   Permission User=sharedusers GenericAll=yes /
/FileShare
User Id=sharedusers CreateUser=yes Name=Administrators
Domain=[ComputerName] FailIfExists=no
   GroupRef Id=AdminGroup /
/User
 /Component
...
  Group Id=AdminGroup Name=Administrators Domain=[ComputerName]
/

Any help would be appreciated, thanks. 
-- 
View this message in context: 
http://www.nabble.com/Sharing-a-folder-with-group-permissions-tf4719928.html#a13493201
Sent from the wix-users mailing list archive at Nabble.com.


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Wix v3 certificate installation bug?

2007-10-30 Thread John Hancock (HSG)
It appears that the Wix Certificate file-based installation and the Overwrite 
option are currently incompatible. If a Certificate element is configured with 
Request=no and Overwrite=yes and CertificatePath=PathToCertificateFile, 
installation will fail. The error logged is Invalid Certificate.Attributes

Is this intentional and simply undocumented that the Overwrite and file-based 
options are incompatible, or is this a bug?

Thanks,

John Hancock


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Help with Major Upgrade

2007-10-30 Thread Kelly Leahy
The problem is the sequencing.  By the time InstallFinalize has happened, 
the install is already committed, so you can't roll back the install of 
version 2, at least if I'm understanding it correctly.  You probably want 
your RemoveExistingProducts to be somewhere earlier in the sequence, so 
that it can cause a rollback of version 2's install if version 1's 
uninstall fails.

There are problems with all placements of this action, however, so you 
should decide what is the worst of your evils.  If you have Phil Wilson's 
book, it describes the pros and cons of the different placements of 
RemoveExistingProducts.  I don't have it here at work with me - it's 
sitting on my desk at home - otherwise I'd look it up and recommend 
alternatives for you.

Kelly




Ted Berg [EMAIL PROTECTED]

Sent by: [EMAIL PROTECTED]
10/30/2007 11:50 AM

To
wix-users@lists.sourceforge.net
cc

Subject
[WiX-users] Help with Major Upgrade






I am packaging an MSI that I would like to have perform a Major Upgrade
when deployed on a machine with an older version of said package already
installed.

My setup:
* Product Id is set to ----
* Upgrade Code is set to some GUID which does not change
* The Upgrade clause is set to
Upgrade Id=some GUID
UpgradeVersion
  Minimum=$(var.VERSION)
  OnlyDetect=yes
  Property=NEWERVERSIONDETECTED /
UpgradeVersion
  Minimum=1.0.0.0
  IncludeMinimum=yes
  Maximum=$(var.VERSION)
  IncludeMaximum=no
  Property=OLDERVERSIONBEINGUPGRADED /
  /Upgrade

Where var.VERSION is our major.minor.micro.build version number.
* InstallExecuteSequence contains the following entries:
RemoveExistingProducts After=InstallFinalize/

* The package launches an application upon installation.

Scenarios:
* Install version 1 of package, Install version 2 of package.  Version 2
install notices that version 1 is running and asks for it to be shut
down.  User complies and the install completes normally.  Version 2 is
the only package that appears in Add/Remove Programs.
* Install version 1 of package, Install version 2 of package.  When
asked to shut down running copy of version 1, User hits the Exit button.
   Install informs user that their system was not modified and exits.
Both  versions now appear in Add/Remove Programs.  When the application
is next launched it is version 2.

In the second scenario the install of Version 2 should roll back and
exit as the UI implies.  What do I need to do for this to happen?
Failing that how can I prevent scenario 2?

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users




**
This communication is intended solely for the addressee and is
confidential. If you are not the intended recipient, any disclosure, 
copying, distribution or any action taken or omitted to be taken in
reliance on it, is prohibited and may be unlawful.  Unless indicated
to the contrary: it does not constitute professional advice or 
opinions upon which reliance may be made by the addressee or any 
other party, and it should be considered to be a work in progress.
Unless stated otherwise, this communication does not form a prescribed
statement of actuarial opinion under American Academy of Actuaries 
guidelines.
**-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] start and stop services

2007-10-30 Thread shapla

I have used the ServiceControl element as below:

ServiceControl Id='ADService' Name='XYZ AdminConsole' Start='both'
Stop='uninstall'/

I have logged on as Administrator and XYZ AdminConsole is running.

Now if I run my MSI package, it is failing and showing: Service 'XYZ
AdminConsole'(XYZ AdminConsole) failed to start. Verify that you have
sufficient preveledges to start system services.

Do you have any idea about? 

Thanks!


Richard-45 wrote:
 
 
 In article [EMAIL PROTECTED],
 shapla [EMAIL PROTECTED]  writes:
 
 1. Restart this service after installing my MSI
 2. My MSI will remove some files during uninstall and I want to:
2.1 Stop this service before removing the files and 
2.2 Start it again after removing the files.
 
 How can I do this? Please let me know if you have any idea.
 
 Look at the ServiceControl element.
 -- 
 The Direct3D Graphics Pipeline -- DirectX 9 draft available for download
   http://www.xmission.com/~legalize/book/download/index.html
 
 Legalize Adulthood! http://blogs.xmission.com/legalize/
 
 -
 This SF.net email is sponsored by: Splunk Inc.
 Still grepping through log files to find problems?  Stop.
 Now Search log events and configuration files using AJAX and a browser.
 Download your FREE copy of Splunk now  http://get.splunk.com/
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users
 
 

-- 
View this message in context: 
http://www.nabble.com/start-and-stop-services-tf4715721.html#a13494802
Sent from the wix-users mailing list archive at Nabble.com.


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] WiX 3.0 post 3304 working for anyone?

2007-10-30 Thread Mike Dimmick
Whenever I run a tool in version 3307, 3328 or 3419 builds obtained from
wix.sourceforge.net/releases, I get a System.IO.FileLoadException
(0x80131040) saying that the wix assembly could not be loaded. Turning on
the binding logging gives this information:

=== Pre-bind state information ===
LOG: User = ***removed***
LOG: DisplayName = wix, Version=3.0.3328.0, Culture=neutral,
PublicKeyToken=ce35f76fcda82bad
 (Fully-specified)
LOG: Appbase = file:///C:/Tools/wix3-binaries3328/
LOG: Initial PrivatePath = NULL
Calling assembly : candle, Version=3.0.3328.0, Culture=neutral,
PublicKeyToken=ce35f76fcda82bad.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file:
C:\Tools\wix3-binaries3328\candle.exe.Config
LOG: Using machine configuration file from
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\config\machine.config.
LOG: Post-policy reference: wix, Version=3.0.3328.0, Culture=neutral,
PublicKeyToken=ce35f76fcda82bad
LOG: Attempting download of new URL
file:///C:/Tools/wix3-binaries3328/wix.DLL.
WRN: Comparing the assembly name resulted in the mismatch: PUBLIC KEY TOKEN
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing
terminated.

This suggests that the public key token of wix.dll isn't what candle.exe is
asking for. Loading the files into Reflector (www.aisto.com/roeder/dotnet)
shows that wix.dll has a public key token of 9f4be179981a58d1.

Is this working for anyone else? I can't imagine how it could be, but before
I put a bug in the tracker I wanted to be sure.

-- 
Mike Dimmick


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] MMC Snapin

2007-10-30 Thread Mike Dimmick
I thought I'd sent a message on this one but must have deleted a draft.

There are two sorts of MMC snap-in:

MMC 3.0 only: .NET 2.0 classes which inherit
Microsoft.ManagementConsole.SnapIn

All versions: COM objects which implement IComponent and IcomponentData (not
to be confused, in .NET, with System.ComponentModel.IComponent).

The former sort can be registered with registry keys under
HKLM\Software\Microsoft\MMC\SnapIns. The documentation tells you to use a
.NET Installer class but that's a bad plan - managed custom actions are
officially not supported (I wish the Framework team would just mark the
damned thing Deprecated and work out a way to achieve their install tasks
WITHOUT doing something unsupported by Windows Installer). 

WixMMCExtension in v2 handles only MMC 3.0 .NET snap-ins. It is a pure
extension in that it only generates Registry rows, rather than requiring any
custom actions. It could be ported to WiX v3 fairly easily, I think.

The latter sort are simply COM objects and should be registered in the same
way as any other .NET objects registered for COM interop, if you have
written it using .NET. Heat is able to handle this (if you're running as an
administrator, anyway - if not, it just generates the File element in
3.0.3304.0).

However Heat will only generate the COM registration - it won't generate the
snap-in registration. You'll need to add your own Registry elements to do
this. The registry entries you need to create can be found at
http://msdn2.microsoft.com/en-us/library/aa815156.aspx.

Adding the snap-in to a console (.msc) file is then straightforwardly done
through the MMC user interface.

-- 
Mike Dimmick

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Levon Levonian
Sent: 30 October 2007 16:15
To: Chad Petersen; Rob Mensching
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] MMC Snapin

Hi. Thanks for the reply.

But isn't it true that the DLL itself should be registered, since the
.MSC acts as a configuration/shortcut to the actual snap-in, which
resides in a DLL. I deployed the MSC, but I am just getting Snap-in
failed to initialize and Snap-in creation failed messages when I run
it.
Anyway, I tried to register the DLL manually with RegAsm mySnapIn.dll
/codebase, but I am getting an Action canceled page in the area where
snap-in should be displayed.

Any comments are appreciated.


-Original Message-
From: Chad Petersen [mailto:[EMAIL PROTECTED] 
Sent: Monday, October 29, 2007 9:36
To: Levon Levonian; Rob Mensching
Cc: wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] MMC Snapin

We use an MMC snap-in in one of our applications. I may be simplifying
this too much, but entry point to a Snap-In is the .MSC file. We deposit
the .MSC in the Deploy directory of choice and create a shortcut to the
.MSC.

Component Id=DeployMSCComp
Guid=1ED23462-B5B7-42af-B86A-BF4CB1E86BB6
File Id=DeployMSC Name=INTERL~1.MSC
LongName=Interlinq E3 Deployment Manager.msc src=.\Data\Interlinq E3
Deployment Manager 2.6.msc Vital=yes KeyPath=yes DiskId=1
Shortcut Id=DeployMSCShortCut
Directory=MENUINTERLINQ Name=E3Depl~2 LongName=Interlinq E3
Deployment Manager Icon=DEPLOYICON IconIndex=0 Show=normal
WorkingDirectory=DEPLOYDIR /
/File
/Component

The rest of the supporting DLLs and scripts, etc. that are needed by the
Snap-In also go in the same folder and a registry key association is
made to the resource dll that references the MSC file.

File Id=E3DeployManagerResources_Dll Name=E3R~1.dll
LongName=E3DeployManagerResource.dll
src=.\Data\E3DeployManagerResource.dll Vital=yes DiskId=1/
Registry Id=DeployLocationKey Root=HKCU
Key=Software\HarlandFS\E3Deploy Name=MSC Value=[#DeployMSC]
Type=string/

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Levon
Levonian
Sent: Friday, October 26, 2007 4:31 PM
To: Rob Mensching
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] MMC Snapin

OK, I got the extension name, but:
None of the WiX v3 packages contains WixMMCExtension, I only found it in
v2, but v3 does not load v2 extensions (Error   The extension
'C:\Program Files\Windows Installer XML v3\bin\WixMMCExtension.dll'
could not be loaded.candle.exe)

Anybody has a working example for Snap-in deployment?

Thanks!


-Original Message-
From: Rob Mensching [mailto:[EMAIL PROTECTED] 
Sent: Thursday, October 25, 2007 19:57
To: Levon Levonian
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] MMC Snapin

There is an extension in WiX v3 that handles much of the authoring work 
for you.

Levon Levonian wrote:

 Hi All,

  

 Is there a (easy) way to deploy an MMC Snap-in?


**
READER BEWARE: Unencrypted, unsigned Internet e-mail is inherently insecure.

Internet messages may be 

Re: [WiX-users] Managed Custom Action using InstallUtilLib.dll

2007-10-30 Thread Mike Dimmick
Managed custom actions are officially unsupported by Windows Installer
because of the way that the CLR 'taints' the process it loads into. You
cannot reliably ensure that the correct CLR version is loaded at the correct
time. See Rob's blog post
http://robmensching.com/blog/archive/2007/04/19/Managed-Code-CustomActions-n
o-support-on-the-way-and-heres.aspx.

Yes, it's seriously annoying that the .NET Framework and Visual Studio guide
you in the direction of a bad design. The whole Installer hierarchy (and
especially ServiceInstaller which duplicates Windows Installer
functionality) should be marked Deprecated in my view.

What can you do? Unfortunately, the most reliable form of custom actions are
native C/C++ DLLs. However, if you can write device drivers I would have
thought you could write custom action DLLs.

WiX does have support for .NET performance counters in v3 using the
PerformanceCategory and PerformanceCounter elements in the Util schema. This
is certainly present in build 3304. For v2 you will have to write an
appropriate .h and .ini file and use the PerfCounter element. You can use
the code for the ParsePerformanceCategoryElement method in v3 - which
basically generates the .h and .ini files and dumps them into a custom table
- as a template. See src\ext\UtilExtension\UtilCompiler.cs in the source
distribution. .NET Framework doesn't provide a way to do this (well, it
does, but only if you're prepared to use reflection to invoke it because the
members are private).

Wix's support currently won't work on NT 4.0 because the APIs
LoadPerfCounterTextStrings and UnLoadPerCounterTextStrings are used, not the
lodctr.exe program. The APIs were added in Windows 2000.

-- 
Mike Dimmick

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Sankaranarayanan
Sent: 30 October 2007 18:36
To: Richard; WiX Users
Subject: Re: [WiX-users] Managed Custom Action using InstallUtilLib.dll

I use custom action for the following operations

1) Read XML Config file and set installer properties
2) Install Device Drivers
3) Loading MOF
4) Setting Windows Service privileges
5) Installing .NET Perf Counters.

etc...

WiX doesn't support these actions by default.

Please let know if you have any approach for the following issue :

I am using Managed Custom Action as details in
http://blogs.msdn.com/josealmeida/archive/2004/11/08/253831.aspx
This approach works like a charm but I didn't quite like the idea of
packaging InstallUtilLib.dll file in MSI.

Is there a way to use the InstallUtilLib.dll present in the client machine
instead of packing it in MSI Binary table as follows
Binary Id=InstallUtil src=$(var.FrameworkPath)\InstallUtilLib.dll /.
(I have a Lauch Condition to check for .NET Framework presence in the client
machine).

Thanks,
Sankaranarayanan MG

- Original Message 
From: Richard [EMAIL PROTECTED]
To: WiX Users wix-users@lists.sourceforge.net
Cc: [EMAIL PROTECTED]
Sent: Tuesday, 30 October, 2007 10:03:10 AM
Subject: Re: [WiX-users] Managed Custom Action using InstallUtilLib.dll


In article [EMAIL PROTECTED],
Sankaranarayanan [EMAIL PROTECTED]  writes:

 I am using Managed Custom Action [...]

What is your custom action doing?  The MSDN documentation leads people
to believe that they need managed custom actions for all sorts of
things that the standard actions and tables already cover.
-- 
The Direct3D Graphics Pipeline -- DirectX 9 draft available for download
  http://www.xmission.com/~legalize/book/download/index.html

Legalize Adulthood! http://blogs.xmission.com/legalize/


  ___ 
Want ideas for reducing your carbon footprint? Visit Yahoo! For Good
http://uk.promotions.yahoo.com/forgood/environment.html

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Help with Major Upgrade

2007-10-30 Thread Richard

In article [EMAIL PROTECTED],
Kelly Leahy [EMAIL PROTECTED]  writes:

 The problem is the sequencing.  By the time InstallFinalize has happened, 
 the install is already committed, so you can't roll back the install of 
 version 2, at least if I'm understanding it correctly.  You probably want 
 your RemoveExistingProducts to be somewhere earlier in the sequence, so 
 that it can cause a rollback of version 2's install if version 1's 
 uninstall fails.

I always recommend putting RemoveExistingProducts right after
InstallInitialize.  This wraps the entire upgrade in a transaction.
If the transaction fails, then the new version is removed and the old
version is restored.  This requires that you author appropriate
rollback support in your custom actions, but you should be doing that
anyway.
-- 
The Direct3D Graphics Pipeline -- DirectX 9 draft available for download
  http://www.xmission.com/~legalize/book/download/index.html

Legalize Adulthood! http://blogs.xmission.com/legalize/

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] start and stop services

2007-10-30 Thread Richard

In article [EMAIL PROTECTED],
shapla [EMAIL PROTECTED]  writes:

 I have used the ServiceControl element as below:
 
 ServiceControl Id='ADService' Name='XYZ AdminConsole' Start='both'
 Stop='uninstall'/

But didn't you say you wanted to *restart* the service?  The calls for
a stop and a start.

 I have logged on as Administrator and XYZ AdminConsole is running.
 
 Now if I run my MSI package, it is failing and showing: Service 'XYZ
 AdminConsole'(XYZ AdminConsole) failed to start. Verify that you have
 sufficient preveledges to start system services.
 
 Do you have any idea about? 

Windows Installer is essentially just doing a net stop svc to stop
a service and a net start svc to start a service.  It uses a
default timeout of 30 seconds, IIRC.  You can adjust the timeout if a
service is particularly slow to start.

Basically, Windows Installer is just doing what you asked of it here;
it doesn't know why a service didn't start.  You'll have to look more
into the service itself to identify why it didn't start.  The Verify
that... message is just a catch all warning for the common problem of
not having sufficient privileges to control the service.
-- 
The Direct3D Graphics Pipeline -- DirectX 9 draft available for download
  http://www.xmission.com/~legalize/book/download/index.html

Legalize Adulthood! http://blogs.xmission.com/legalize/

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Install a Font

2007-10-30 Thread Mike Dimmick
See
http://www.microsoft.com/typography/fonts/font.aspx?FID=39FNAME=Wingdings%2
03FVER=1.55 for a list of Microsoft products that this font ships with. If
you can rely on one of these being installed, you won't need to ship it
yourself. This table doesn't appear to have been updated for the 2007
products (Windows Vista, Office 2007).

If installing your own font, you simply set the FontTitle attribute of the
File element that carries the font file. See Font Table in the SDK for
more information (http://msdn2.microsoft.com/en-us/library/aa368606.aspx).
The normal rules apply - if there is a known component GUID for this file,
you should use that (typically with a merge module or the third party's own
installer), if not, I would set SharedDllRefCount to ensure that it's not
removed prematurely.

-- 
Mike Dimmick

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson
Sent: 30 October 2007 16:19
To: Craig0ss
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Install a Font

Craig0ss wrote:
 I need my installer to install the font Wingdings3 on install
   

Check with its developer to see if they provide a redist: 
http://www.ascendercorp.com/msfonts/wingdings3.html.

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



-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Checkbox does not recognize when it is checked

2007-10-30 Thread Richard

In article [EMAIL PROTECTED],
xyavier [EMAIL PROTECTED]  writes:

 This is how it is set up 

Well, I think you're going to have to dig into log files and your MSI
with Orca instead of just relying upon inspection of WiX fragments to
debug this problem.

Have you tried that?
-- 
The Direct3D Graphics Pipeline -- DirectX 9 draft available for download
  http://www.xmission.com/~legalize/book/download/index.html

Legalize Adulthood! http://blogs.xmission.com/legalize/

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] adding mimemap to Webvirtualdir

2007-10-30 Thread Mike Dimmick
iis:MimeMap is only for setting the MIME type for a given file extension.
This governs what IIS will send in the Content-Type header for static web
content. It sounds like you need to add an ISAPI filter and as far as I can
see, you need to do this with a WebApplicationExtension element.

 

I'm no expert on website configuration, though.

 

-- 

Mike Dimmick

 

  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: 30 October 2007 10:38
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] adding mimemap to Webvirtualdir

 

Hi all,

I want to know how the iis:mimemap tag works, it seems to need an id but do
not know how to add an MIME element although in the helpfile is written that
it schould be child of Wix tag.

Second thing is that I want to add a wildcard mime (after I know how to add
a MIME to a webvirtualdir) like
*,C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll,0,All or
is it better to call a vbscript instead?

 

Thanks Peter

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] WiX Localization - One Installer to support multipleLanguages

2007-10-30 Thread Mike Dimmick
A given package can only be localized into one language. One approach that
you can take to save space is to ship the package in one language with a
number of transforms (.mst) which, when applied, translate the package into
other languages. Microsoft have used this approach before and it's the
recommended one in the SDK. See Localizing a Windows Installer Package at
http://msdn2.microsoft.com/en-us/library/aa369769.aspx.

-- 
Mike Dimmick

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Sankaranarayanan
Sent: 30 October 2007 06:16
To: wix-users@lists.sourceforge.net
Cc: [EMAIL PROTECTED]
Subject: [WiX-users] WiX Localization - One Installer to support
multipleLanguages

Hi,

Currently I am creating Localized WiX installers based on the steps
mentioned @ http://www.tramontana.co.hu/wix/lesson2.php#2.4 (WixUI
Customization and Localization Combined).

Using those steps - I am able to create one installer for specific language.


Is there a way to link the wixobj files with different localized language
files in the same installer. I would like to have only one installer and its
UI should be displayed based on the Language of the Users  Operating System.
If the Operating System language isn't one of the defeault supported
language of the MSI - it should fall back to en-US. Can all supported
languages WixUI_XX-XX.wxl file be integrated into the same installer.

Thanks,
Sankaranarayanan MG


  ___
Yahoo! Answers - Got a question? Someone out there knows the answer. Try it
now.
http://uk.answers.yahoo.com/

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] WiX Localization - One Installer to support multipleLanguages

2007-10-30 Thread Richard

In article [EMAIL PROTECTED],
Mike Dimmick [EMAIL PROTECTED]  writes:

 [...] Microsoft have used this approach before and it's the
 recommended one in the SDK. See Localizing a Windows Installer Package at
 http://msdn2.microsoft.com/en-us/library/aa369769.aspx.

This thread had me looking at localization support in Windows
Installer again and I can't find on this page where it talks about
transforms or recommends using a bootstrapper with transforms as the
way to localize a package.  I know InstallSUCK does it this way, but I
thought that Windows Installer allowed you to embed multiple language
transforms into the package and apply one based on the system
language?  Someone (you, perhaps?) referenced an InstallSite article
that described this process but noted that it was unsupported.

This seems the reverse of what I remember reading in the SDK
documentation, but I'm getting old now :-).
-- 
The Direct3D Graphics Pipeline -- DirectX 9 draft available for download
  http://www.xmission.com/~legalize/book/download/index.html

Legalize Adulthood! http://blogs.xmission.com/legalize/

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Custom actions launched from .MSM files

2007-10-30 Thread Mike Dimmick
The INSTALLDIR property will be modularized by WiX when building the MSM, so
when the final package is executed, [INSTALLDIR] will not evaluate to the
place you thought it would.

 

If it's a file you're installing, using [#fileid] is a better option than
forming the path yourself. See the documentation for the Formatted data type
(at http://msdn2.microsoft.com/en-us/library/aa368609.aspx).

 

Generally you should keep all your components in a merge module in a
hierarchy under TARGETDIR. When the merge occurs, this is rewritten to be
the Directory the Merge element appears under.

 

Finally, if both producer (MSM) and consumer (MSI) are WiX projects you may
find Fragments easier to handle. WiX is like C++ in that it has a compiler
(candle) and a linker (light). Candle checks syntax and flattens your XML
into tables (the output is still XML but in a flattened form), light links
up the rows from multiple inputs into complete tables and resolves
references from one fragment to another.

 

-- 

Mike Dimmick

 

  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Elena Diaconu
Sent: 29 October 2007 22:17
To: 'Mike Dimmick'; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Custom actions launched from .MSM files

 

Hi Mike,

Thank you for the answer; but I think the property is in the same file; this
is the XML sequence which works fine in the .MSI:

 

CustomAction Id=CAPCInstall.Command  Property=QtExecCmdLine
Value=quot;[INSTALLDIR]AppSecInc.Performance.CAInstaller.exequot;/

CustomAction Id=CAPCInstall BinaryKey=wixca DllEntry=CAQuietExec
Execute=immediate Return=check /

Binary Id=wixca SourceFile=$(var.WIX_DIR)\wixca.dll /

CustomAction Id=CAPCUnInstall.Command Property=QtExecCmdLine
Value=quot;[INSTALLDIR]AppSecInc.Performance.CAInstaller.exequot; 1/

CustomAction Id=CAPCUnInstall BinaryKey=wixca DllEntry=CAQuietExec
Execute=immediate Return=check/

InstallExecuteSequence

  Custom Action=CAPCInstall.Command
After=RegisterProduct/Custom

  Custom Action=CAPCInstall
After=CAPCInstall.Command/Custom

  Custom Action=CAPCUnInstall.Command
Before=RegisterProductInstalled/Custom

  Custom Action=CAPCUnInstall
After=CAPCUnInstall.CommandInstalled/Custom

 /InstallExecuteSequence

 

Do you think I forgot to add something, or is there anything to do with
[INSTALLDIR], and how the WIX replaces the [INSTALLDIR] string?

I also hardcoded the EXE path in the .MSM file (in Value) and I am getting
the same error. My WIX version is 3.0.

Thank you,

Elena

 

 

  _  

From: Mike Dimmick [mailto:[EMAIL PROTECTED] 
Sent: 2007-Oct-29 Mon 5:57 PM
To: 'Elena Diaconu'; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] Custom actions launched from .MSM files

 

Deferred custom actions get their instructions on what to do from a property
named the same as the custom action itself, which in the CA code itself is
the CustomActionData property.

 

When you include something in a module, by default its identifier is
modularized, that is, a GUID is added after the identifier you specify. This
is to prevent name clashes between different modules and between a module
and the installer.

 

I'm guessing that the custom action itself is being modularized - you can
see this below - but the property isn't, or the property is in a different
module to the CA.

 

-- 

Mike Dimmick

 

  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Elena Diaconu
Sent: 29 October 2007 16:05
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Custom actions launched from .MSM files

 

Dear WIX users,

 

I have a problem when I am trying to launch an executable through a Custom
Action  from an .MSM file: the WIX installation fails.

When the executable is launched from an .MSI file everything works fine. So
is launching executables through Custom Actions from .MSM files supposed to
work or not?

 

Below it is the errors log sequence:

MSI (s) (1C:58) [18:03:58:968]: Doing action:

QtExec.412198FF_0AE9_4CB8_889D_53756DDAC731

Action 18:03:58: QtExec.412198FF_0AE9_4CB8_889D_53756DDAC731. 

Action start 18:03:58: QtExec.412198FF_0AE9_4CB8_889D_53756DDAC731.

MSI (s) (1C:A0) [18:03:58:984]: Invoking remote custom action. DLL:

C:\WINDOWS\Installer\MSIADF.tmp, Entrypoint: CAQuietExec

CAQuietExec:  Error 0x80070057: failed to get command line data

CAQuietExec:  Error 0x80070057: failed to get Command Line

Action ended 18:03:59: QtExec.412198FF_0AE9_4CB8_889D_53756DDAC731. Return

value 3.

Action ended 18:03:59: INSTALL. Return value 3.

 

Thank you, I appreciate your answer(s),

Elena 

 

Elena Diaconu

Sr. Software Engineer,

Application Security Inc.

appsecinc.com http://www.appsecinc.com/ 

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration 

Re: [WiX-users] start and stop services

2007-10-30 Thread shapla

I have tried like below just to stop a service:

ServiceControl Id='PMService' Name='XYZ AdminConsole' Stop='install'
Wait='yes'/

  Installation goes on without any error, but the service is not stopped. I
can stop the same service from command prompt(net stop XYZ AdminConsole)

Any idea?

Thanks!


Richard-45 wrote:
 
 
 In article [EMAIL PROTECTED],
 shapla [EMAIL PROTECTED]  writes:
 
 I have used the ServiceControl element as below:
 
 ServiceControl Id='ADService' Name='XYZ AdminConsole' Start='both'
 Stop='uninstall'/
 
 But didn't you say you wanted to *restart* the service?  The calls for
 a stop and a start.
 
 I have logged on as Administrator and XYZ AdminConsole is running.
 
 Now if I run my MSI package, it is failing and showing: Service 'XYZ
 AdminConsole'(XYZ AdminConsole) failed to start. Verify that you have
 sufficient preveledges to start system services.
 
 Do you have any idea about? 
 
 Windows Installer is essentially just doing a net stop svc to stop
 a service and a net start svc to start a service.  It uses a
 default timeout of 30 seconds, IIRC.  You can adjust the timeout if a
 service is particularly slow to start.
 
 Basically, Windows Installer is just doing what you asked of it here;
 it doesn't know why a service didn't start.  You'll have to look more
 into the service itself to identify why it didn't start.  The Verify
 that... message is just a catch all warning for the common problem of
 not having sufficient privileges to control the service.
 -- 
 The Direct3D Graphics Pipeline -- DirectX 9 draft available for download
   http://www.xmission.com/~legalize/book/download/index.html
 
 Legalize Adulthood! http://blogs.xmission.com/legalize/
 
 -
 This SF.net email is sponsored by: Splunk Inc.
 Still grepping through log files to find problems?  Stop.
 Now Search log events and configuration files using AJAX and a browser.
 Download your FREE copy of Splunk now  http://get.splunk.com/
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users
 
 

-- 
View this message in context: 
http://www.nabble.com/start-and-stop-services-tf4715721.html#a13501470
Sent from the wix-users mailing list archive at Nabble.com.


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] start and stop services

2007-10-30 Thread Richard

In article [EMAIL PROTECTED],
shapla [EMAIL PROTECTED]  writes:

 Any idea?

What does the log say?
-- 
The Direct3D Graphics Pipeline -- DirectX 9 draft available for download
  http://www.xmission.com/~legalize/book/download/index.html

Legalize Adulthood! http://blogs.xmission.com/legalize/

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Managed Custom Action using InstallUtilLib.dll

2007-10-30 Thread Richard

In article [EMAIL PROTECTED],
Aris Green [EMAIL PROTECTED]  writes:

 I have been using managec C++ CA's coded in Visual Studio 2003 for
 installs.

IMO, you might as well just use native C++ at that point.

 Well, you get the picture.  One wrinkle, the VC 2005 requires linking to the
 C++ CRT as a DLL when using .NET.  You have to use a manifest when linking
 to the CRT, so if the same exact version that you built against in your CA
 is not on the target machine, BAM!.

You still tattoo your process using this technique, though.
-- 
The Direct3D Graphics Pipeline -- DirectX 9 draft available for download
  http://www.xmission.com/~legalize/book/download/index.html

Legalize Adulthood! http://blogs.xmission.com/legalize/

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Wix v3 certificate installation bug?

2007-10-30 Thread Bob Arnson

[dropping wix-devs]

John Hancock (HSG) wrote:


It appears that the Wix Certificate file-based installation and the 
Overwrite option are currently incompatible. If a Certificate element 
is configured with Request=no and Overwrite=yes and 
CertificatePath=PathToCertificateFile, installation will fail. The 
error logged is Invalid Certificate.Attributes


 

Is this intentional and simply undocumented that the Overwrite and 
file-based options are incompatible, or is this a bug?




There's a bug there, but also a missing implementation: Overwrite 
currently does nothing. (Its only mention is commented out in scacert.cpp.)


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

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Managed Custom Action using InstallUtilLib.dll

2007-10-30 Thread Aris Green
I have been using managec C++ CA's coded in Visual Studio 2003 for
installs.  You create a .NET dll and use unmanaged exports .e.g
__declspec(dllexport) int __stdcall MyCustomAction(MSIHANDLE hInstall);
All your logic is in the installation package and you don't have to leave a
carcass behind with the installed product as you do when using installutil.

Well, you get the picture.  One wrinkle, the VC 2005 requires linking to the
C++ CRT as a DLL when using .NET.  You have to use a manifest when linking
to the CRT, so if the same exact version that you built against in your CA
is not on the target machine, BAM!.

You might try writing the CA code in VB .NET,  or C#, decompile to IL,
augment your class with a static method using an unmanaged export in pure
IL, and recompile.  I have played around with this a bit in .NET 1.1.  Since
I am upgrading an installed product for 1.1 to 2.0, I am seriously going to
consider this as the C++ CRT DLL with its manifests is one strapping
headache, or I might just try to do everything in native code.

One thing you can do, which I've done before, is to create a native DLL that
embeds the managed assembly as a resource.  Extract the assembly, host the
CLR in native code, and run your CA.
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Checkbox does not recognize when it is checked

2007-10-30 Thread Bob Arnson
xyavier wrote:
 Component Id='MyComponent' Guid='BLah BLah BLah-123456789012'
 Condition
DELALL = 1
 /Condition

 RemoveFile Id='LogFile' On='uninstall' Name='*.*' /
 RemoveFolder Id='TheDir' On='uninstall'/

 /Component
   

That's not going to work the way you want. RemoveFile and RemoveFolder 
work on uninstall when the component itself is being uninstalled. That 
means it has to be installed in the first place, which it won't be, 
because you have a condition on it that won't be true during install.

The easiest way to get what you want is probably via a custom action 
that adds temporary rows to the RemoveFile table. I blogged about that 
kind of CA a few months ago: 
http://www.joyofsetup.com/2007/07/01/semi-custom-actions/.

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



-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] What is WixV3 Toolset Output MSI Version?

2007-10-30 Thread Laxmi Narsimha Rao Oruganti (SQL CE)
Hey WiX Folks,

If I am not wrong, WIXv3 Toolset produces Windows Install v3.1 MSI.  I also 
remember some blogs where WIX Team have met with MSI Team to do the 
enhancements to WIX Toolset to use new features of MSI 4.0.

Can you answer the following?

1)WIXv3 Current Build produces MSI v3.1.  Does WIXv3 in future produce MSI 
v4.0?  OR WIXv4 produces MSI v4.0?

2)When will WIXv3 development completes?  When is it going to release 
candidate phase only very few fixes are taken?

Thanks,
Laxmi

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] What is WixV3 Toolset Output MSI Version?

2007-10-30 Thread Bob Arnson

Laxmi Narsimha Rao Oruganti (SQL CE) wrote:


If I am not wrong, WIXv3 Toolset produces Windows Install v3.1 MSI.  I 
also remember some blogs where WIX Team have met with MSI Team to do 
the enhancements to WIX Toolset to use new features of MSI 4.0. 

 


Can you answer the following?

1)WIXv3 Current Build produces MSI v3.1.  Does WIXv3 in future 
produce MSI v4.0?  OR WIXv4 produces MSI v4.0?




WiX lets you target whatever version of MSI you're interested in, down 
to MSI 1.0. See Package/@InstallerVersion.


2)When will WIXv3 development completes?  When is it going to 
release candidate phase only very few fixes are taken?




It will likely reach that stage sometime in 2008. There are no more 
breaking changes planned, but they are possible.


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

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] WiX 3.0 post 3304 working for anyone?

2007-10-30 Thread Bob Arnson
Mike Dimmick wrote:
 Whenever I run a tool in version 3307, 3328 or 3419 builds obtained from
 wix.sourceforge.net/releases, I get a System.IO.FileLoadException
 (0x80131040) saying that the wix assembly could not be loaded. 

It's a known issue and the WiX buildmeisters are working on the fix 
(which is needed after we moved the WiX build to a new machine). But 
feel free to file a bug -- I don't see one at first glance and everyone 
loves to close bugs...g

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


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users