[WiX-users] Problems with Merge Modules on Wix 3.7/VS2010/Windows 8 and 8.1
I’ve been trying to track down why my Wix Project is being relinked every single time I do a build even though nothing’s changed. Eventually, I’ve tracked it down to the MFC100 merge modules. I have wxs file in my project: MFCMerge.wxs that contains this: ?xml version=1.0 encoding=UTF-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; ?define MergeLoc=..\Merge Modules ? Fragment EnsureTable Id=Verb/ EnsureTable Id=ProgId/ EnsureTable Id=MIME/ EnsureTable Id=Extension/ EnsureTable Id=Class/ EnsureTable Id=TypeLib/ DirectoryRef Id=INSTALLLOCATION Merge Id=atl DiskId=1 SourceFile=$(var.MergeLoc)\Microsoft_VC100_ATL_x86.msm Language=0/ Merge Id=crt DiskId=1 SourceFile=$(var.MergeLoc)\Microsoft_VC100_CRT_x86.msm Language=0 / Merge Id=mfc DiskId=1 SourceFile=$(var.MergeLoc)\Microsoft_VC100_MFC_x86.msm Language=0 / Merge Id=mfcloc DiskId=1 SourceFile=$(var.MergeLoc)\Microsoft_VC100_MFCLOC_x86.msm Language=0 / /DirectoryRef FeatureGroup Id=MFCDep MergeRef Id=atl / MergeRef Id=crt/ MergeRef Id=mfc/ MergeRef Id=mfcloc/ /FeatureGroup /Fragment /Wix I then have this in my main.wxs file: Feature Id=MFCSupport Level=1 FeatureGroupRef Id=MFCDep/ /Feature If I comment the above lines out in main.wxs I don’t see the rebuild every time, but if I do, I get a message in the build output mode with diagnostics switched on that says: 1Building target Link completely. 1Input file C:\Users\Tony\AppData\Local\Temp\xy3bc3ot\MergeId.634601\F_CENTRAL_atl100_x86.AFA96EB4_FA9F_335C_A7CB_36079407553D does not exist. The above file appears to be mentioned in C:\(...)\XXX.wixproj.BindContentsFileListen-US.txt Maybe this rebuild often works because the temp files are not cleaned up, but this now causes problems as for some reason, the above temp folder disappears immediately after the build. Is this a known problem? Anthony Wieser Wieser Software Ltd -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] ICE Validation and MSI failure 2738
Further to my original post: I've also tried running in an admin account on Vista, which didn't help. I can run .vbs scripts by double clicking them. The problem also shows up if I load an MSI in orca, and try to run ICE08. I also tried while running ProcessMonitor from sysinternals, but didn't spot anything. I've tried to register and unregister msiexec, to no avail. My version of msiexec on my machine appears to be 4.5.6002.18005. I'm really hoping I don't have to reinstall everything on this PC! Anthony Wieser Wieser Software Ltd -- From: Anthony Wieser wix-l...@wieser-software.com Sent: Wednesday, September 15, 2010 11:47 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] ICE Validation and MSI failure 2738 I've been through aaron and heath's fixes, for the vbscript problem, that occurs with ICE 08, etc, but unfortunately, my Vista machine is no longer running the VB Script validations. I tried reregistering vbscript and jscript, but to no avail. I'm running on 32 bit vista business, and am in a limited user account. Any suggestions what to try next? Anthony Wieser Wieser Software Ltd -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] ICE Validation and MSI failure 2738
I've been through aaron and heath's fixes, for the vbscript problem, that occurs with ICE 08, etc, but unfortunately, my Vista machine is no longer running the VB Script validations. I tried reregistering vbscript and jscript, but to no avail. I'm running on 32 bit vista business, and am in a limited user account. Any suggestions what to try next? Anthony Wieser Wieser Software Ltd -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Is there a bug handling VSTEMPLATE files for WiX?
I've created a Wix project, and set up some additional items for my project. Included is a folder named bitmaps, containing banner.jpg and dialog.jpg when I then export a vstemplate file, and add it as a user item, when I create a new project based on the template the bitmaps are corrupted (getting UTF-8 ified), replacing all non-ansi characters with something else, as described here: http://social.msdn.microsoft.com/Forums/en-US/vsx/thread/0316b38f-b78f-4b31-b667-d2b189b3dbfb I'm using the very latest build of Wix 3.5 The problem doesn't occur on the last version of WiX 3.0 on a different machine. Any idea why? Anthony Wieser Wieser Software Ltd -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] What keeps borking my ICE validation by registering VBScript and JScript under HKCU?
Heath Stewart reports the solution here, but I find this frustrating that
every now and then, I go to build and suddenly I can't, getting light.exe
errors. As I don't build every day, I'm not sure what's registering these
under HKCU, but something is.
I don't remember installing anything but windows updates, and it looks like
a Java update.
Oh, and I did see an installshield update thing run too.
Is anyone else seeing this occasionally? Anyone figured out who the bad guy
is?
http://blogs.msdn.com/heaths/archive/2007/05/31/windows-installer-errors-2738-and-2739-with-script-custom-actions.aspx
Check that vbscript.dll and jscript.dll aren't registered in
HKEY_CURRENT_USER (HKCU), checking for the registry keys below.
VBScript, HKCU\SOFTWARE\Classes\CLSID\{
B54F3741-5B07-11CF-A4B0-00AA004A55E8}
JScript, HKCU\SOFTWARE\Classes\CLSID\{ F414C260-6AC0-11CF-B6D1-00AA0058}
Anthony Wieser
Wieser Software Ltd
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] What keeps borking my ICE validation by registering VBScript and JScript under HKCU?
Bummer. So these installers just decide to re-register the DLLs to be sure
that they're registered, and as a result probably break their own
functionality.
Thanks for the response, Rob.
Anthony Wieser
Wieser Software Ltd
- Original Message -
From: Rob Mensching r...@wixtoolset.org
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
Sent: Wednesday, February 18, 2009 4:51 AM
Subject: Re: [WiX-users] What keeps borking my ICE validation by registering
VBScript and JScript under HKCU?
My understanding was that there are many bad guys.
Anthony Wieser wrote:
Heath Stewart reports the solution here, but I find this frustrating that
every now and then, I go to build and suddenly I can't, getting light.exe
errors. As I don't build every day, I'm not sure what's registering
these
under HKCU, but something is.
I don't remember installing anything but windows updates, and it looks
like
a Java update.
Oh, and I did see an installshield update thing run too.
Is anyone else seeing this occasionally? Anyone figured out who the bad
guy
is?
http://blogs.msdn.com/heaths/archive/2007/05/31/windows-installer-errors-2738-and-2739-with-script-custom-actions.aspx
Check that vbscript.dll and jscript.dll aren't registered in
HKEY_CURRENT_USER (HKCU), checking for the registry keys below.
VBScript, HKCU\SOFTWARE\Classes\CLSID\{
B54F3741-5B07-11CF-A4B0-00AA004A55E8}
JScript, HKCU\SOFTWARE\Classes\CLSID\{
F414C260-6AC0-11CF-B6D1-00AA0058}
Anthony Wieser
Wieser Software Ltd
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco,
CA
-OSBC tackles the biggest issue in open source: Open Sourcing the
Enterprise
-Strategies to boost innovation and cut costs with open source
participation
-Receive a $600 discount off the registration fee with the source code:
SFAD
http://p.sf.net/sfu/XcvMzF8H
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco,
CA
-OSBC tackles the biggest issue in open source: Open Sourcing the
Enterprise
-Strategies to boost innovation and cut costs with open source
participation
-Receive a $600 discount off the registration fee with the source code:
SFAD
http://p.sf.net/sfu/XcvMzF8H
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Custom Action Woes -- I must be doing something stupid, but can't see it.
I'm trying to run an exe I installed in my script at the end of the install. I've done the following: CustomAction Id=SetAgentNstPath Value=[#AgentInst] Property=AgentInstallerPath/CustomAction CustomAction Id=AgentInstallerAction Property=AgentInstallerPath Return=ignore ExeCommand =agent sapi peedy UK registry exit / I've also schedule the custom actions thus: Custom Action=SetAgentNstPath After=CostFinalize / and Publish Dialog=ExitDialog Control=Finish Event=DoAction Value=AgentInstallerAction ![CDATA[(InstallModeRemove) AND (InstallModeRepair) AND (InstallModeChange)]] /Publish Looking through my install log I see these relevant items: MSI (s) (FC:F4) [07:08:38:238]: Doing action: SetAgentNstPath Action start 07:08:38: SetAgentNstPath. MSI (s) (FC:F4) [07:08:38:243]: PROPERTY CHANGE: Adding AgentInstallerPath property. Its value is 'C:\Program Files\Wieser Software Ltd\Articulate Spelling\agentnst.exe'. Action ended 07:08:38: SetAgentNstPath. Return value 1. ... MSI (c) (0C:9C) [07:08:43:378]: Doing action: ExitDialog Action start 07:08:43: ExitDialog. MSI (c) (0C:74) [07:08:45:442]: Doing action: AgentInstallerAction Action start 07:08:45: AgentInstallerAction. MSI (c) (0C:74) [07:08:45:513]: Note: 1: 1721 2: AgentInstallerAction 3: 4: agent sapi peedy UK registry exit Info 1721. There is a problem with this Windows Installer package. A program required for this install to complete could not be run. Contact your support personnel or package vendor. Action: AgentInstallerAction, location: , command: agent sapi peedy UK registry exit Action ended 07:08:45: AgentInstallerAction. Return value 1. So clearly somethings happened to the AgentInstallerPath property, but it isn't mentioned anywhere else in the log. What have I done wrong? Anthony Wieser Wieser Software Ltd -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Can't build after upgrade
That did the trick. Thanks. Anthony Wieser Wieser Software Ltd - Original Message - From: Simon Dahlbacka [EMAIL PROTECTED] To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Wednesday, November 26, 2008 4:02 PM Subject: Re: [WiX-users] Can't build after upgrade See http://blogs.msdn.com/jasongin/archive/2008/07/09/votive-project-platform-configurations.aspx On Wed, Nov 26, 2008 at 5:53 PM, Anthony Wieser [EMAIL PROTECTED] wrote: I just upgraded from 3.0.3704.0 to 3.0.4721.0 but now I can no longer build my project which is part of my solution in VS2005. When I do a build, it just says skipped on the wixproj - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] WixFirewallExtension outbound connections and McAfee
I see that recent builds of Wix now allow us to set a firewall exception. Am I right in concluding that it only affects inbound connections, and only works with the Windows Firewall? Is there any way to configure an outbound connection (NET_FW_RULE_DIR_OUT) with the current extension? Is there any way to do this with other firewall providers, or are they all different? Anthony Wieser Wieser Software Ltd - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Please help me understand SelfReg and GAC librarydependencies
Oops. The error was the way I was trying to unregister the DLL. - Original Message - From: Anthony Wieser [EMAIL PROTECTED] To: wix-users@lists.sourceforge.net Sent: Tuesday, May 20, 2008 5:24 PM Subject: [WiX-users] Please help me understand SelfReg and GAC librarydependencies OK, I know it's not the best way to install things with WiX, but my product includes a DirectShow filter, and they create some random binary registry entry on selfRegistration, so I have little choice but to register it as self reg. CustomAction Id=regGrabber Execute=commit Directory=INSTALLLOCATION ExeCommand='[SystemFolder]msiexec /y [#axgrab]' Impersonate='no' / CustomAction Id=unregGrabber Execute=commit Directory=INSTALLLOCATION ExeCommand='[SystemFolder]msiexec /x [#axgrab]' Impersonate='no' / CustomAction Id=rollbackGrabber Execute=rollback Directory=INSTALLLOCATION ExeCommand='[SystemFolder]msiexec /x [#axgrab]' Impersonate='no' / It should have been /z not /x! Anthony Wieser Wieser Software Ltd - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Please help me understand SelfReg and GAC library dependencies
OK, I know it's not the best way to install things with WiX, but my product
includes a DirectShow filter, and they create some random binary registry
entry on selfRegistration, so I have little choice but to register it as
self reg.
unfortunatley, because it depends on the DirectShow samples in the SDK, it
also ends up depending on the latest version of the run time libraries (at
least I couldn't get it to build without them being dynamically linked).
So, I'm stuck.
I've authored the following to selfreg after I've installed the msm's for
vs2005:
Component Id=AxGrab Guid={MYGUIDS}
File Id=axgrab Name=grabber.ax
Source=..\Grabber\Release\grabber.ax /
/Component
then to declare the custom actions, I add:
CustomAction Id=regGrabber Execute=commit
Directory=INSTALLLOCATION ExeCommand='[SystemFolder]msiexec /y
[#axgrab]' Impersonate='no' /
CustomAction Id=unregGrabber Execute=commit
Directory=INSTALLLOCATION ExeCommand='[SystemFolder]msiexec /x
[#axgrab]' Impersonate='no' /
CustomAction Id=rollbackGrabber Execute=rollback
Directory=INSTALLLOCATION ExeCommand='[SystemFolder]msiexec /x
[#axgrab]' Impersonate='no' /
finally, in the install execute sequence I add:
InstallExecuteSequence
...
Custom Action=unregGrabber
Before=SelfUnregModules$AxGrab=2/Custom
Custom Action=regGrabber Before=InstallFinalize
$AxGrab2/Custom
Custom Action=rollbackGrabber After=regGrabber
$AxGrab2/Custom
...
/InstallExecuteSequence
I haven't checked my logs yet as I've had to do a full restore to get back
to a known state, but while uninstalling, I got the message are you sure
you wan't to uninstall, and regardless of how i answer, the uninstall rolls
back and says there's some error. That may not be to do with this though,
as some other weirdness is also going on calling DPInst.exe to install a
device driver.
Does the above sequence look like the right sequencing and conditions for
the CustomActions?
Should I be ignoring the return codes using Return=ignore
Anthony Wieser
Wieser Software Ltd
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Output Window bugs with latest versions of Wix?
I couldn't find it in the bug database. And it looks like you meant the Error List window in VS2005, not the Task Pane. I can confirm that the messages show up in the Error List though, so thanks for the workaround. Anthony Wieser Wieser Software Ltd - Original Message - From: Justin Rockwood [EMAIL PROTECTED] To: 'Anthony Wieser' [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Sent: Wednesday, December 05, 2007 4:24 PM Subject: RE: [WiX-users] Output Window bugs with latest versions of Wix? This is a known bug and we're working on a fix. It's actually a bug in Visual Studio 2005 and not in our stuff, but we're working to get a fix for it. It works fine in Visual Studio 2008. Also, the task pane should show the errors in the correct format in both versions as a workaround. Thanks, Justin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anthony Wieser Sent: Wednesday, December 05, 2007 5:15 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Output Window bugs with latest versions of Wix? Has the output format changed. The latest versions of Wix I have (3.0.3530.0, and 3.0.3526.0, 3.0.3509.0, and 3.0,3502.0) aren't setting the output for error messages correctly in my copy of Visual Studio 2005. - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ 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)
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
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 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
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 it because it hasn't elevated, which makes sense, because it's a per
[WiX-users] Maintenance modes
For some reason my msi file is bringing up the maintenance mode when I double click it. So, now I have two questions. 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? I notice that the change button on the dialog is disabled, and that it doesn't appear on the add remove programs applet either. 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? Looking through my log for the reinstall, it appears that Remove isn't set to ALL. Could that be the problem? Is there something special that needs to be done when using the WiX UI libraries? I'm running on vista by the way; haven't had the chance to check if this is a problem on XP or earlier yet. Anthony Wieser Wieser Software Ltd - 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
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 front of your computer. (And no, that's not an invitation for free consulting :-). I wouldn't expect that. Anthony Wieser Wieser Software Ltd - 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] File Associations
I've just released a product, and added the file associations to the registry so that the shell can auto-open my files. However, I found this on MSDN: Note Any time a file association is created or changed, notify the system that a change has been made by calling SHChangeNotify, specifying the SHCNE_ASSOCCHANGED event. If this is not done, the Shell might not recognize any changes made until the system restarts. Is there any way to generate this from WiX, apart from a custom action? Anthony Wieser Wieser Software Ltd - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] VC8 runtime redistribution best practice. Should I usemerge modules or bootstrapper with vcredist_x86.exe?
Hmm. I just spotted this on the microsoft.public.platformsdk.msi newsgroup Subject: GAC files mistakenly removed on upgrade with a link to this KB article: http://support.microsoft.com/kb/905238/en-us Basically it says that if you schedule RemoveExistingProducts too early, the GAC items will be removed. Currently, I'm using this: RemoveExistingProducts After='InstallInitialize'OLDERFULLVERSIONFOUND OR OLDERDEMOFOUND/RemoveExistingProducts Does this mean that I'm vulnerable to this bug if I choose to use merge modules instead of vcredist_x86.exe? Secondly, Is there anyway to do several passes of RemoveExistingProducts? I installed a platform SDK today, and it seemed to remove items in several passes. Anthony Wieser Wieser Software Ltd - Original Message - From: Mike Dimmick [EMAIL PROTECTED] To: 'Anthony Wieser' [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Sent: Friday, June 01, 2007 7:26 PM Subject: RE: [WiX-users] VC8 runtime redistribution best practice. Should I usemerge modules or bootstrapper with vcredist_x86.exe? You should use the merge modules, IMO. Unfortunately DevDiv has been historically bad at generating good merge modules. You'll have to ignore the warnings. They're only warning that a column's declared length was exceeded, I don't think any actual harm occurs (since the files are actually installed by a package that has had this module merged in). Yes, if you use vcredist_x86.exe, the user can uninstall the runtimes out from under you. You can't do anything about this - packages are meant to be self-contained and independent of each other, not requiring other packages to be installed first, so there's no way to add a reference to another package. -- Mike Dimmick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anthony Wieser Sent: 01 June 2007 11:33 To: wix-users@lists.sourceforge.net Subject: [WiX-users] VC8 runtime redistribution best practice. Should I usemerge modules or bootstrapper with vcredist_x86.exe? I'm starting to get paranoid now, having been bitten so many times along the MSI journey. Currently I link most of my applications statically to the VC runtimes, but in the case where I want to redistribute the MFC/VC runtimes, which is the best way? I've looked through the latest vcredist package, and found that the files in it weren't marked as permanent. As I only install vcredist.exe if it's product code isn't present in my custom bootstrapper, it seems to me it will only be installed with the first product I install. After that, it's on the system. That makes sense, but what happens if after you install my product, someone uninstalls vcredist.exe. Will all of my required DLL's be uninstalled out from under me if the files weren't already installed on the computer from another component? I can't see how to add a reference to a component that I didn't install. I leaned toward the vcredist method, because it makes for smaller installs, as you don't need to ship the contents to everyone, and also because the merge modules generated so many warnings. But on further investigation, it appears that the vcredist packages aren't properly signed either. The external package is signed on the new redist, but after hitting the license agreement page, you're presented with the UAC dialog, saying that: VCREDI~3.EXE from an unknown publisher wants to access your computer. That's maybe a little too scary for my users. Anthony Wieser Wieser Software Ltd - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Launching Web Page After Finish Dialog
I've seen ShellExecute recommended as the way to do this, but what's wrong with doing it like this instead? Property Id=SURVEYURLexplorer/Property CustomAction Id=TakeSurvey Property=SURVEYURL Return=asyncNoWait ExeCommand=$(var.SurveyURL)/CustomAction where $(var.SurveyURL) has been set to your http://www.example.com/pagetoshow.htm Anthony Wieser Wieser Software Ltd - Original Message - From: Bob Arnson To: Steve Bush ; wix-users@lists.sourceforge.net Sent: Friday, June 22, 2007 6:22 PM Subject: Re: [WiX-users] Launching Web Page After Finish Dialog If you're using WiX v3, see ShellExecute CustomAction in WiX.chm. It contains a sample showing how to use the WixShellExec custom action to do just that. If you're using WiX v2, you either need to do a custom UI or you can try scheduling your CA in InstallUISequence after ExecuteAction. I'm not sure the latter will work but it's worth a shot. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Bush Sent: Friday, 22 June, 2007 10:15 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Launching Web Page After Finish Dialog Ideally, I would like to launch a web page when the user hits the Finish button on the last dialog. The code below works but the web page is launched after InstallFinalize instead of when the user clicks the Finish button. Also, I want to only show the web page if we're not doing a silent install or upgrade. Thanks. Steve Snippets of Relevant Code: Property Id=BROWSER RegistrySearch Id=IEXPLORE_SEARCH Root=HKLM Key=SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\IEXPLORE.EXE Type=raw / /Property CustomAction Id=LaunchBrowser Property=BROWSER Execute=immediate ExeCommand=$(var.WelcomeURL) Return=asyncNoWait / UI UIRef Id=WixUI_Minimal / UIRef Id=WixUI_ErrorProgressText / /UI InstallExecuteSequence FindRelatedProducts Before=LaunchConditions / RemoveExistingProducts After=InstallValidate / Custom Action=LaunchBrowser After=InstallFinalize![CDATA[UILevel 2 AND NOT Installed]]/Custom /InstallExecuteSequence InstallUISequence FindRelatedProducts Before=LaunchConditions / /InstallUISequence -- - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Sanity Check: Shortcuts and HKCU for a per machine install
Many of the examples I've seen show an idiom that has a component containing a registry key and a shortcut. Supposedly, the reason is that this supports user roaming profiles somehow, which I don't quite understand. However, on Vista, the HKCU this will be installed into is the local system account I assume. My question is, if I create a shortcut on the desktop for my per machine install, should I really be using an HKCU registry path as the keypath? Or should I be using HKLM as the root instead? Anthony Wieser Wieser Software Ltd - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Sanity Check: Shortcuts and HKCU for a per machine install. Should it be HKMU?
That's where I got the original idiom from, but it feels wrong for an all users install. Yes, doing it this way gives no errors, but it doesn't make sense (to me at least). Any chance one of you guys inside Microsoft could get a comment out of the Windows Installer team, or can you suggest how I could raise it with them, for the benefit of all of us? Anthony Wieser Wieser Software Ltd Oh, and ICE57's message is actually an error, not a warning, strangely. - Original Message - From: Rob Hamflett [EMAIL PROTECTED] To: wix-users@lists.sourceforge.net Sent: Thursday, June 07, 2007 1:19 PM Subject: Re: [WiX-users] Sanity Check: Shortcuts and HKCU for a per machine install. Should it be HKMU? D'oh! Including the link might have helped. Here it is. http://robmensching.com/blog/archive/2007/04/27/How-to-create-an-uninstall-shortcut-and-pass-all-the.aspx Rob Rob Hamflett wrote: Rob has a blog post on how to create a shortcut that passes validation. Personally I stopped paying attention to those warnings long ago. Rob Tony Hoyle wrote: Anthony Wieser wrote: Looking into this further, HKLM doesn't work, however reading the ICE43 documenation, it says: Yes, ICE43 is wrong in this respect. It should read ALLUSERS and check (using HKMU is an interesting workaround though). That almost works, but then you get an ICE57 error instead, that says: Component 'DesktopShortcut' has both per-user data and a keypath that can be either per-user or per-machine. So you worked around the ICE43 error and ended up with an ICE57 error :p The documentation on the Desktop Folder indicates that it changes based on the ALLUSERS property, so is it my INSTALLLOCATION causing this, or something else (like ICE57 coded incorrectly)? Sounds like it. Pick which ICE you're going to ignore basically.. in your case it sounds like ICE57 is the one. Tony - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Are ICE45 warnings expectedwith ElevationShield=yes?
I've added a minimal sample to the bug database, as an msi file that installs the files required to build itself. I haven't bundled the various darice.cub's that I tested with originally, but I still get the errors. Could you send me your darice.cub that you use off list please Bob, so that I can see if I still get the errors? Anthony Wieser Wieser Software Ltd - Original Message - From: Bob Arnson [EMAIL PROTECTED] To: Anthony Wieser [EMAIL PROTECTED] Cc: wix-users@lists.sourceforge.net Sent: Monday, May 28, 2007 10:59 PM Subject: Re: [WiX-users] Are ICE45 warnings expectedwith ElevationShield=yes? Anthony Wieser wrote: First there seem to be quite a few exceptions thrown. Can you enter a bug with these details and a repro case? You should be able to produce an uncompressed MSI with no files that's small enough to attach (and without giving away any softwareg). -- sig://boB http://joyofsetup.com/ - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] VC8 runtime redistribution best practice. Should I use merge modules or bootstrapper with vcredist_x86.exe?
I'm starting to get paranoid now, having been bitten so many times along the MSI journey. Currently I link most of my applications statically to the VC runtimes, but in the case where I want to redistribute the MFC/VC runtimes, which is the best way? I've looked through the latest vcredist package, and found that the files in it weren't marked as permanent. As I only install vcredist.exe if it's product code isn't present in my custom bootstrapper, it seems to me it will only be installed with the first product I install. After that, it's on the system. That makes sense, but what happens if after you install my product, someone uninstalls vcredist.exe. Will all of my required DLL's be uninstalled out from under me if the files weren't already installed on the computer from another component? I can't see how to add a reference to a component that I didn't install. I leaned toward the vcredist method, because it makes for smaller installs, as you don't need to ship the contents to everyone, and also because the merge modules generated so many warnings. But on further investigation, it appears that the vcredist packages aren't properly signed either. The external package is signed on the new redist, but after hitting the license agreement page, you're presented with the UAC dialog, saying that: VCREDI~3.EXE from an unknown publisher wants to access your computer. That's maybe a little too scary for my users. Anthony Wieser Wieser Software Ltd - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] v3 Simple Custom Action?
I'm doing it like this: Property Id=SURVEYURLexplorer/Property CustomAction Id=TakeSurvey Property=SURVEYURL Return=asyncNoWait ExeCommand=$(var.SurveyURL)/CustomAction InstallExecuteSequence Custom Action=TakeSurvey Sequence=101REMOVE=ALL AND NOT UPGRADINGPRODUCTCODE/Custom /InstallExecuteSequence But this runs before a successful uninstallation that isn't an upgrade Anthony Wieser Wieser Software ltd Pulling my hair out on this one... Can anyone show a simple set of snippets that would allow a custom action (launching the default web browser to go to 'http://localhost/test/page.html') to run after successful installation? I thought this would be straightforward, but for some reason it's just not. Help? - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Are ICE45 warnings expectedwith ElevationShield=yes?
doesn't like the shield attribute being set. The date on the vista version is: darice.cub 02/02/2006 644 KB (659,968 bytes) I'm also a little worried about the shortcut table message. I assume WiX 3.0 is putting in entries that work on v4, but that no harm will come of this. Running the file from 120 from the vista sdk under smoke gives: WebGalleryWx.msi smoke.exe : error SMOK0216 : An unexpected Win32 exception with error code 0xEA occurred: More data is available Anthony Wieser Wieser Software Ltd - Original Message - From: Mike Dimmick [EMAIL PROTECTED] To: 'Anthony Wieser' [EMAIL PROTECTED] Sent: Thursday, May 24, 2007 11:43 PM Subject: RE: [WiX-users] Are ICE45 warnings expectedwith ElevationShield=yes? Find Win32Exception under the Debug/Exceptions dialog and set it to break when the exception is thrown, then run it under the debugger. Then see the Debug/Windows/Call Stack window! At least we'll be able to see if WiX did something strange, or whether the error is actually in the ICEs. If the latter all you can really do is report it to the Platform SDK team - hmm, not sure how to do that actually. Probably call developer support (at worst, leave a comment on the Windows SDK blog at http://blogs.msdn.com/windowssdk/). An alternative is to suppress validation in WiX (pass -sval to light) and run the validation through Orca, but Orca doesn't give you the option to suppress particular ICEs, so you may well see some complaints about not using the Class table if you're registering COM classes. Another route is to see if you get different results with smoke.exe. If you felt really advanced you could use WinDbg but that's not much fun. -- Mike Dimmick -Original Message- From: Anthony Wieser [mailto:[EMAIL PROTECTED] Sent: 24 May 2007 23:04 To: Mike Dimmick Subject: Re: [WiX-users] Are ICE45 warnings expectedwith ElevationShield=yes? No, no other information given, unfortunately, although I'm running it in MSDEV under VS2005 on a limited user account. Where might I find the call stack, or shall I try to run it under the debugger to see what happens? Anthony Wieser Wieser Software Ltd - Original Message - From: Mike Dimmick [EMAIL PROTECTED] To: 'Anthony Wieser' [EMAIL PROTECTED]; 'Bob Arnson' [EMAIL PROTECTED] Cc: wix-users@lists.sourceforge.net Sent: Thursday, May 24, 2007 7:47 PM Subject: RE: [WiX-users] Are ICE45 warnings expectedwith ElevationShield=yes? ERROR_MORE_DATA (error number 234, hex 0xEA) indicates that the buffer you supplied was too small but that the function returned some data. MsiRecordGetString returns this value, for example, if the buffer is too small. This may well be a coding error in one of the ICEs. Does Light give a call stack? -- Mike Dimmick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anthony Wieser Sent: 24 May 2007 17:27 To: Bob Arnson Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Are ICE45 warnings expectedwith ElevationShield=yes? Hmm. I copied the one from my 120 folder from the Vista SDK, which has the same size but a different date, and now I get a crash from light: Error LGHT0216: An unexpected Win32 exception with error code 0xEA occurred: More data is available I guess I'll live with the earlier warning instead. Anthony Wieser Wieser Software Ltd - Original Message - From: Bob Arnson [EMAIL PROTECTED] To: Anthony Wieser [EMAIL PROTECTED] Cc: wix-users@lists.sourceforge.net Sent: Wednesday, May 23, 2007 2:43 PM Subject: Re: [WiX-users] Are ICE45 warnings expected with ElevationShield=yes? Anthony Wieser wrote: I'm a bit puzzled as to which one to move to the WiX folder. I used the copy from March CTP in Bin\msitools\Schemas\MSI\120\: 24-01-2007 10:44 482,816 ___A_ darice.cub -- sig://boB http://joyofsetup.com/ - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Are ICE45 warnings expected with ElevationShield=yes?
Hmm. I copied the one from my 120 folder from the Vista SDK, which has the same size but a different date, and now I get a crash from light: Error LGHT0216: An unexpected Win32 exception with error code 0xEA occurred: More data is available I guess I'll live with the earlier warning instead. Anthony Wieser Wieser Software Ltd - Original Message - From: Bob Arnson [EMAIL PROTECTED] To: Anthony Wieser [EMAIL PROTECTED] Cc: wix-users@lists.sourceforge.net Sent: Wednesday, May 23, 2007 2:43 PM Subject: Re: [WiX-users] Are ICE45 warnings expected with ElevationShield=yes? Anthony Wieser wrote: I'm a bit puzzled as to which one to move to the WiX folder. I used the copy from March CTP in Bin\msitools\Schemas\MSI\120\: 24-01-2007 10:44 482,816 ___A_ darice.cub -- sig://boB http://joyofsetup.com/ - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Are ICE45 warnings expected with ElevationShield=yes?
I'm a bit puzzled as to which one to move to the WiX folder. The one that I currently have is dated: 8/12/2006 and is 632 KB. The platform SDK for vista has two copies. One at: C:\Program Files\Microsoft SDKs\Windows\v6.0\Bin\msitools\Schemas\MSI\120 and one at C:\Program Files\Microsoft SDKs\Windows\v6.0\Bin\msitools\Schemas\MSI\110 but both of these files are smaller, and older than the one I currently have. Is the correct file located somewhere else, or is it one of these two? Anthony Wieser Wieser Software Ltd - Original Message - From: Bob Arnson [EMAIL PROTECTED] To: Anthony Wieser [EMAIL PROTECTED] Cc: wix-users@lists.sourceforge.net Sent: Tuesday, May 22, 2007 3:15 PM Subject: Re: [WiX-users] Are ICE45 warnings expected with ElevationShield=yes? Anthony Wieser wrote: Unfortunately, ICE45 gives an error once you've added ElevationShield=yes to the Pushbutton control. Is this because ICE45 is out of date? Yes. You can update darice.cub from the Vista SDK to get the latest ICEs. -- sig://boB http://joyofsetup.com/ - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Registry Cleanup at uninstall
Reading over the documentation for MSI, it appears that you can have a registry key and all subkeys removed at uninstall if you include a name of '-' instead of an acutal name. I can see how that would work with HKLM entries, but under UAC with Vista, it probably will only uninstall from the user whose credentials were used. Is there any way to remove all HKCU items for all of the users on a machine created in the registry on uninstall, or are people stuck with having to clean it up manually themselves. Anthony Wieser Wieser Software Ltd - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Registry Cleanup at uninstall
Thanks Rob, I was leaning toward that solution anyway, and now I can stop worrying, and learn to love the registry. It's a pity places like tucows don't understand this and still award points as follows: Uninstall process: There are three possible points for this criterion divided into two separate categories. Uninstall mechanism: This criterion refers to items left behind in the installation directory or start menu program group. This item does not refer to registry keys needed to determine trial expiration and use of your product. If you are attempting to not cause a loss of data for saved information or application preferences, provide a clear note within the uninstall or provide a custom uninstall for the user to save the data. If you don't employ an uninstall mechanism, your application will receive zero points. (traces = 1 point, complete = 2 points) Anthony Wieser Wieser Software Ltd - Original Message - From: Rob Mensching [EMAIL PROTECTED] To: Anthony Wieser [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Sent: Wednesday, May 23, 2007 5:24 PM Subject: RE: [WiX-users] Registry Cleanup at uninstall There is nothing in Windows (the operating system) to really help you remove registry keys from all user profiles. There are a few things (in particular, roaming profiles) that make it impossible to correctly handle this problem. I generally suggest, leave the stuff behind... and if the user upgrades to a new version of your application, use that data during migration. That's what Office does to great success, IMHO. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Debug CRT merge module
Like this, from my previous example: ?define SampDir=C:\projects\business\artgallery\sample_src\? ?define SampDiskId=1? ?define SampParentDir=INSTALLLOCATION? Anthony Wieser Wieser Software Ltd - Original Message - From: Harry Liljeström [EMAIL PROTECTED] To: wix-users@lists.sourceforge.net Sent: Tuesday, May 22, 2007 8:03 AM Subject: [WiX-users] Debug CRT merge module Hi, I have WiX source code, which contains debug version of an executable. Also, in WiX I have included CRT merge module (debug version): Merge Id=VC8Runtime SourceFile=C:\Program Files\Common Files\Merge Modules\Microsoft_VC80_DebugCRT_x86.msm Language=1033 DiskId=1/ The MSI package is created successfully and it is also installed correctly on the target system. The CRT dll:s are installed in: C:\WINDOWS\WinSxS\x86_Microsoft.VC80.DebugCRT_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_f75eb16c Trying to launch the executable gives me following error: 'The system cannot execute the specified program.' Can someone explain to me why the debug version of the executable cannot be executed in the target system? Thanks, Harry -- View this message in context: http://www.nabble.com/Debug-CRT-merge-module-tf3794591.html#a10732487 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Using heat.exe as part of an automated build process
Thanks for the heads up. I'll bear that in mind. Presumably, changing the root folder for the files each time would solve this problem then. so sample-v1 sample-v2, etc would fix it as the root of the installed pieces. Anthony Wieser Wieser Software Ltd - Original Message - From: Mike Dimmick [EMAIL PROTECTED] To: 'Anthony Wieser' [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Sent: Tuesday, May 22, 2007 12:17 AM Subject: RE: [WiX-users] Using heat.exe as part of an automated build process Yes, you're breaking rule 1 of the component rules: a file installed to the same location must always belong to the same component and have the same GUID. Change the GUID, it's a new component; change the component, you must change the final path name of the file. If you don't, you mess up Windows Installer's reference counting and it may either remove files prematurely or not remove them when it should. At the very least you restrict where you can schedule the RemoveExistingProducts action when performing an upgrade (if you do it after InstallFiles in the new product, Windows Installer will happily remove all the old components - and the files it's just installed). -- Mike Dimmick - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Is there a WiX element that will perform a FindWindow?
Has anyone else noticed a pattern of emails getting marked as spam by Windows Mail on vista. Does gmail always look like spam to source forge? This message was one of the messages marked as spam, presumably due to these headers: X-Spam-Score: 0.5 (/) X-Spam-Report: Spam Filtering performed by sourceforge.net. See http://spamassassin.org/tag/ for more details. Report problems to http://sf.net/tracker/?func=addgroup_id=1atid=21 0.0 RCVD_BY_IP Received by mail server with no name 0.0 HTML_MESSAGE BODY: HTML included in message 0.5 HTML_20_30 BODY: Message is 20% to 30% HTML - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Variables
Sorry, somehow managed to respond in the wrong thread: Variables can be set like this, from my previous example: ?define SampDir=C:\projects\business\artgallery\sample_src\? ?define SampDiskId=1? ?define SampParentDir=INSTALLLOCATION? Anthony Wieser Wieser Software Ltd - Original Message - From: Wik Carl-Johan To: wix-users@lists.sourceforge.net Sent: Tuesday, May 22, 2007 7:47 AM Subject: [WiX-users] Variables Hi! I have found things like this, in example: $(var.SampParentDir) But I haven't been successful in finding information about it. Can anyone point me in the direction where to read up about this or explain it please. How do I declare it, init it .. Regards -- - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] More Questions on Component Rules
OK, I have to admit, I still can't fathom all of the implicit rules going on here. On Rob's blog, he shows a way of installing shortcuts, and shows us an example that hangs them here: RegistryKey Root=HKCU Key=Software\My Application\Uninstall But, what I'd like to do, is create my values in this way instead: RegistryKey Root=HKCU Key=Software\My Company\My Application\Uninstall I have a similar desire to create application folders on the system like this: Directory Id=TARGETDIR Name=SourceDir Directory Id=CommonAppDataFolder Directory Id=companyCAD Name=Company Name Here !-- Does a component need to go here? -- Directory Id=productCAD Name=Product Name here Component Id=PersistentDataFolder Guid=GUID-HERE CreateFolder Permission GenericAll=yes User=Administrators / Permission ReadPermission=yes Synchronize =yes Read=yes ReadAttributes=yes ReadExtendedAttributes=yes CreateFile=yes WriteAttributes=yes WriteExtendedAttributes=yes CreateChild=yes GenericWrite=yes User=Users/ /CreateFolder /Component /Directory !-- End component here? -- /Directory /Directory more stuff /Directory Should I be creating components for the inner empty folders, and registry keys? I can't seem to find an explicit answer in the MSI or WiX documentation. Maybe that's because there's no right answer, so if I did do it, I presume the component GUID would need to be constant across all of my installs, because of the component rules discussed earlier today. I also presume that this would allow the node to be removed when there are no longer any users of the component. What happens if I leave it the way it is? I would have guessed that the key's above Uninstalled in Rob's example would be orphaned, but it seems that they're removed. Is it just that empty keys are removed, if not marked permanent on an uninstall? Anthony Wieser Wieser Software Ltd - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Using heat.exe as part of an automated build process
I've just built a similar tool today, to help me copy a set of sample files to the installation, because I never want to do that by hand, and heat's output was just too messy for my liking. What I've done is taken all of the files in a tree, and created a component for each file, with a unique GUID, automatically generated. In addition, the files are relative to a folder elsewhere. The file looks more or less like this: ?xml version=1.0 encoding=utf-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; ?define SampDir=C:\projects\business\artgallery\sample_src\? ?define SampDiskId=1? ?define SampParentDir=INSTALLLOCATION? Fragment DirectoryRef Id=$(var.SampParentDir) Directory Id=D0 Name=sample !-- more directories nest here, containing file/component groups as below-- Component Id=C00 Guid=81f9ff04-e26a-45e6-ba24-6cd1466b4f3f File Id=F00 Name=404.htm KeyPath=yes Source=$(var.SampDir)\sample\templates\404.htm DiskId=$(var.SampDiskId) / /Component !-- lots more components go here for each file in the folder-- /Directory /DirectoryRef ComponentGroup Id=CGSamp ComponentRef Id=C / /ComponentGroup /Fragment /Wix As you can see, I've marked each of the files as KeyPath=yes and also automatically generated ID's for each file, component and folder. Then I've wrapped the whole lot up inside a fragment, which also contains a component group, so I can link the whole file into my build, and then just add a simple Feature that uses a ComponentGroupRef. My intention was to build this as the initial listing of all of the files in my folder, and then manually add any additions, but your post made me question whether that was necessary. Is there a downside of just redoing all of the GUID's each time I do an update, apart from installation speed? Anthony Wieser Wieser Software ltd - Original Message - From: Yexley, Robert (LNG-CON) To: Rob Mensching ; Scott Palmer Cc: wix-users@lists.sourceforge.net Sent: Monday, May 21, 2007 8:21 PM Subject: Re: [WiX-users] Using heat.exe as part of an automated build process Thanks Rob. But the code divination that you speak of is not really what I'm looking for. I'm not looking for some voodoo that will get me out of doing my job, I'm just looking for a way to do it more efficiently and effectively. The *actual* situation that I have is that the files that make up the web application that I'm trying to create an installer for change, at least slightly, from week-to-week. ASPX pages get added, js files get removed, etc. The file system is a moving target. I've discussed the maintenance of .wxs files with the development team and the general consensus seems to be that having to update/change a .wxs file to add or remove a component whenever a file is added or removed from the codebase is not really feasible. The hope, then, was that there might be some way, some tool that I could use, to automatically generate a .wxs source file with all of the components needed by simply pointing it at a given directory. I can setup my automated build process to take the raw code directory and copy only the files needed to a staging directory (remove all files with the following extensions: .cs, .csproj, etc)...that directory then becomes a mirror image of what I want the target machine to look like after having run the installer. I have no problem with creating a main .wxs source file with all of the custom UI logic and stuff like that in it, but having to manually maintain files for each and every single file that makes up an application is tedious at best (more colorful ways of describing that process come to mind as well). The other major consideration here is the fact that I don't really have a requirement to deploy to a large user base, nor is there a requirement for component upgrades either. We're developing an installer to simplify the process of internal deployment. Within the company that I work, there is a completely separate organization that maintains our server environments, and the deployment of applications to those servers. The idea of simplifying that process for them by creating a simple installer is very appealing to everyone. So, for our purposes, an upgrade would really just be a matter of checking to see if the application is already installed and if it is, uninstall it before continuing with the current installation. There are a few custom actions that I would want to perform as part of the process, but again, I can write that into the installer source and handle that myself. I simply want something that is capable of looking at a directory and generating a source file with a component for each of the files and directory structures in the given directory. I hope that clears some things up. I also hope that makes what I'm wanting/hoping/trying to do fairly easy. I just need some guidance as to how to do that, whether it involves the use of heat.exe or something else. If nothing else exists, fine...I'll
[WiX-users] Defining Installer Components; what is best practice for a large set of sample files?
Onto my second WiX conversion, and yet another set of questions arises. I have a program that has a sample project distributed with it. The sample project consists of two folders each containing more folders and a set of about 10 files, for a total of about 100 files. Reading through the Windows Installer recommendations here: http://msdn2.microsoft.com/en-us/library/aa368269.aspx It appears that this case falls under case 6, which implies that I should put all of my files in each folder in a group. By doing this, I presumably install the set if the folder exists or not, which isn't too terrible, and as it says, this will improve performance. However, now when I come to do a major upgrade, I now have a problem if I want to add any files, do I need to create a new component ID? If so, doesn't the key path still match, and therefore the component won't be installed? And if that's the case, it appears that I need to cost the installation of each file separately, create a GUID for each file, and install them all, right? Finally, just to make it painfully obvious what I need to do, if I want to only install files if they don't already exist, I also need to add search for each file, and then conditionally add the component with a condition, if the file is found. Have I correctly understood how this all works? Anthony Wieser Wieser Software Ltd - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Pass variable's value using MSBuild
I'm had problems with this too. I've had the following line in my .wixproj file: WixVariablesConfig=demo.wxi/WixVariables Then in my .wxs file, I'd like to include the file specified as config. I tried this in my .wxs file, ?include $(var.Config) ? but I get this error: Error CNDL0150: Undefined preprocessor variable '$(var.Config)'. Then I looked around, and discovered, that this passes a LINKER variable. To pass a compiler variable I need to do this instead: DefineConstantsConfig=demo.wxi/DefineConstants Now it works as expected. Anthony Wieser Wieser Software Ltd - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Cancel during Uninstall
I feel like I'm missing something here. Two things actually. First, regarding rollback: I want have a custom action in my installation that modifies the system in some way that can't be handled another way. The documentation Rollback Custom Actions implies that I need to schedule a rollback custom action before my deferred custom action, but also includes this paragraph: The complement to a rollback custom action is a commit custom action. The installer executes a commit custom action during the installation sequence, copies the custom action into the rollback script, but does not execute the action during rollback. Later, the same document says: Commit custom actions are the first actions to run in the rollback script. If a commit custom action fails, the installer initiates rollback but can only rollback those operations already written to the rollback script. This means that depending on the commit custom action, a rollback may not be able to undo the changes made by the action. You can ignore failures in commit custom actions by authoring the custom action to ignore return codes. What does the copies the custom action into the rollback script, but does not execute in the first quote actually mean? Do they execute or not? I assume that they do actually execute first, when a rollback occurs. Also, as I understand it Commit items are done in the user context, rather than under the system local account. Which implies that I had better not try to modify things which aren't accessible in the wrong context in a custom action. Now the other thing I don't understand is uninstall. Presumably, for my custom action I need to come up with a condition that runs when I remove if relevant, and checks to see if my action (or a different one) needs to run. Presumably, that means the condition on the action is something like REMOVE=ALL OR REMOVE MYCOMPONENT Is that right? Do I also need to do a rollback, incase the uninstall cancels or fails with the same conditions immediately before? Anthony Wieser Wieser Software ltd - Original Message - From: Bob Arnson [EMAIL PROTECTED] To: Anton Tkachev [EMAIL PROTECTED] Cc: WiX-users@lists.sourceforge.net Sent: Wednesday, April 25, 2007 4:55 PM Subject: Re: [WiX-users] Cancel during Uninstall Anton Tkachev wrote: Yea, I agree that in the Internet we have plenty amount of rollback examples. But these examples show how to rolback INSTALATION process. And it is clear for me. This point is also described in the link that you received. But I need to rollback a custom action during UNinstallation process. And this is what I asked in the first post. Did you see such examples? From the MSI perspective, there's very little difference between installation and uninstallation. Rollback works the same way for both: Schedule your uninstall rollback CA just before your uninstall CA. -- sig://boB http://bobs.org - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Problems overriding dialog sequence
- Original Message - From: Rennie Petersen [EMAIL PROTECTED] To: Anthony Wieser [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Sent: Friday, April 20, 2007 12:20 PM Subject: RE: [WiX-users] Problems overriding dialog sequence You need to change some things in the WixUI_InstallDir.wxs file to change the sequencing of dialog boxes. Rennie I subsequently found this: http://www.wixwiki.com/index.php?title=WixUI_Custom It states that you cannot insert a custom dialog. You must duplicate the relevant contents of the WixUI_InstallDir.wxs or whichever you're trying to modify, and include UIRef Id=WixUI_Common / instead. Unfortunately, the help file distributed with WiX isn't clear on this point. Anthony Wieser Wieser Software Ltd - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Type 51 Custom Actions not run? [SOLVED]
Duh! If you're trying to make changes to the UI, don't add it to the InstallExecuteSequence! Add it to the InstallUISequence instead! Once I did that, it all started working. Maybe posting this will save someone else some time before they make the same dumb mistake. Anthony Wieser Wieser Software Ltd and then add this in the sequence table: InstallExecuteSequence Custom Action=setUserProductID After=AppSearchPIDKEY = /Custom Custom Action=setMachineProductID After=setUserProductIDPIDKEY = /Custom /InstallExecuteSequence - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Type 51 Custom Actions not run?
I'm trying to read some data out of the registry using
Property Id=MACHINEKEY
RegistrySearch Id=RMK Root=HKLM Type=raw
Key=SOFTWARE\MyKeyPath Name=LicenseKey
/RegistrySearch
/Property
Property Id=USERKEY
RegistrySearch Id=RUMK Root=HKCU Type=raw
Key=SOFTWARE\MyKeyPath Name=LicenseKey
/RegistrySearch
/Property
That works fine, and both items are correctly set to the values in the
registry.
Then, I'd like to set PIDKEY (if it isn't already set) to MACHINEKEY if
that's set, or USERKEY if it's not.
Unfortunately, I've spent the last 5 hours trying unsuccessfully to figure
this one out.
It seems I'm stuck even at the first hurdle. Ideally, I'd like to do this:
CustomAction Id=setMachineProductID Property=PIDKEY
Value=[MACHINEKEY] /
CustomAction Id=setUserProductID Property=PIDKEY Value=[USERKEY]
/
and then add this in the sequence table:
InstallExecuteSequence
Custom Action=setUserProductID After=AppSearchPIDKEY =
/Custom
Custom Action=setMachineProductID After=setUserProductIDPIDKEY
= /Custom
/InstallExecuteSequence
I expected that this would set PIDKEY to one of the values if it wasn't
already set.
I then add this line to one of my dialogs:
Control Id=CDKeyEdit Type=Edit X=45 Y=159 Width=250
Height=16 Property=PIDKEY Text={12}
to try to display the value.
Well, examining the logs, I get this:
Action start 15:42:10: AppSearch.
MSI (c) (20:B8) [15:42:10:257]: Note: 1: 2262 2: Signature 3: -2147287038
MSI (c) (20:B8) [15:42:10:257]: PROPERTY CHANGE: Adding MACHINEKEY property.
Its value is 'bogusmachine'.
MSI (c) (20:B8) [15:42:10:259]: Note: 1: 2262 2: Signature 3: -2147287038
MSI (c) (20:B8) [15:42:10:259]: PROPERTY CHANGE: Adding USERKEY property.
Its value is 'bogususer'.
Action ended 15:42:10: AppSearch. Return value 1.
MSI (c) (20:B8) [15:42:10:260]: Doing action: ValidateProductID
Action start 15:42:10: ValidateProductID.
Action ended 15:42:10: ValidateProductID. Return value 1.
MSI (c) (20:B8) [15:42:10:262]: Doing action: CostInitialize
Action start 15:42:10: CostInitialize.
As you can see my custom action isn't scheduled.
so, I remove the conditions, and rewrite as:
InstallExecuteSequence
Custom Action=setUserProductID After=AppSearch /
Custom Action=setMachineProductID After=setUserProductID /
/InstallExecuteSequence
which gives the same results.
Strangely, even if I try to set the PIDKEY on the command line of msiexec, I
still don't get anything in the dialog.
When I replace PIDKEY with a WORKINGKEY and make the following changes I get
the same results:
Property Id=WORKINGKEY Value=1234 /
CustomAction Id=setMachineProductID Property=WORKINGKEY
Value=[MACHINEKEY] /
CustomAction Id=setUserProductID Property=WORKINGKEY
Value=[USERKEY] /
only now 1234 shows up on my UI as the key in the dialog, but there's still
no evidence of running the custom actions in the log.
Any ideas where I've screwed up this time?
Anthony Wieser
Wieser Software Ltd
I've tried to set up a custom action to just copy one of the properties to
another, but it's not being run.
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Dialog Editor
I thought I once saw a tool that could decompile .rc or .res files from visual studio, and produce WiX dialogs. However, I can't find any information on where this was. Was I imagining it, or could one of you kind people point me in the right direction. Thanks. Anthony Wieser Wieser Software Ltd - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Dialog Editor
It looks like it was a tool called Tallow, which was in Wix 2.0, but not 3.0. Is there a plan to put it back into 3.0? Anthony Wieser Wieser Software Ltd - Original Message - From: Anthony Wieser [EMAIL PROTECTED] To: wix-users@lists.sourceforge.net Sent: Thursday, April 19, 2007 10:26 AM Subject: [WiX-users] Dialog Editor I thought I once saw a tool that could decompile .rc or .res files from visual studio, and produce WiX dialogs. However, I can't find any information on where this was. Was I imagining it, or could one of you kind people point me in the right direction. Thanks. Anthony Wieser Wieser Software Ltd - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Dialog Editor
From: Anthony Wieser [EMAIL PROTECTED] To: wix-users@lists.sourceforge.net Sent: Thursday, April 19, 2007 11:28 PM Subject: Re: [WiX-users] Dialog Editor It looks like it was a tool called Tallow, which was in Wix 2.0, but not 3.0. Is there a plan to put it back into 3.0? Anthony Wieser Wieser Software Ltd Apparently heat.exe now subsumes tallow functionality, however I can't find the equivalent to the -r command to decompile a .rc file. Has anyone got this to work? Anthony wieser Wieser Software Ltd - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Problems with MFC and CRT 8 Merge Modules
I added this to my project file: Merge Id='CRT80' Language='1033' SourceFile='c:\program files\common files\merge modules\Microsoft_VC80_CRT_x86.msm' DiskId='1' / Merge Id='MFC80' Language='1033' SourceFile='c:\program files\common files\merge modules\Microsoft_VC80_MFC_x86.msm' DiskId='1' / and then added this to my main feature: MergeRef Id=CRT80 / MergeRef Id=MFC80 / When I built with WiX, I got tons of ICE warnings as shown below. Is this expected? Microsoft claim in msdn that you should do this: From the Project menu, point to Add and click Merge Module. Select Microsoft_VC80_CRT_x86.msm and Microsoft_VC80_MFC_x86.msm, and click OK. Anthony Wieser Wieser Software Ltd I:\2005\CPP\NDS\HexagonWx\HexagonWx.wxs(55,0): Warning LGHT1055: The InstallExecuteSequence table contains an action 'SxsInstallCA' which cannot be merged from the merge module 'c:\program files\common files\merge modules\Microsoft_VC80_MFC_x86.msm'. This action is likely colliding with an action in the database that is being created. The colliding action may have been authored in the database or merged in from another merge module. If this is a standard action, it is likely colliding due to a difference in the condition for the action in the database and merge module. If this is a custom action, it should only be declared in the database or one merge module. I:\2005\CPP\NDS\HexagonWx\HexagonWx.wxs(55,0): Warning LGHT1055: The InstallExecuteSequence table contains an action 'SxsUninstallCA' which cannot be merged from the merge module 'c:\program files\common files\merge modules\Microsoft_VC80_MFC_x86.msm'. This action is likely colliding with an action in the database that is being created. The colliding action may have been authored in the database or merged in from another merge module. If this is a standard action, it is likely colliding due to a difference in the condition for the action in the database and merge module. If this is a custom action, it should only be declared in the database or one merge module. light.exe(0,0): Warning LGHT1076: ICE03: String overflow (greater than length permitted in column); Table: Component, Column: KeyPath, Key(s): downlevel_manifest.8.0.50727.762.98CB24AD_52FB_DB5F_FF1F_C8B3B9A1E18E light.exe(0,0): Warning LGHT1076: ICE03: String overflow (greater than length permitted in column); Table: Component, Column: KeyPath, Key(s): downlevel_manifest.8.0.50727.100.98CB24AD_52FB_DB5F_FF1F_C8B3B9A1E18E light.exe(0,0): Warning LGHT1076: ICE03: String overflow (greater than length permitted in column); Table: Component, Column: KeyPath, Key(s): downlevel_manifest.8.0.50727.101.98CB24AD_52FB_DB5F_FF1F_C8B3B9A1E18E light.exe(0,0): Warning LGHT1076: ICE03: String overflow (greater than length permitted in column); Table: Component, Column: KeyPath, Key(s): downlevel_manifest.8.0.50727.103.98CB24AD_52FB_DB5F_FF1F_C8B3B9A1E18E light.exe(0,0): Warning LGHT1076: ICE03: String overflow (greater than length permitted in column); Table: Component, Column: KeyPath, Key(s): downlevel_manifest.8.0.50727.104.98CB24AD_52FB_DB5F_FF1F_C8B3B9A1E18E light.exe(0,0): Warning LGHT1076: ICE03: String overflow (greater than length permitted in column); Table: Component, Column: KeyPath, Key(s): downlevel_manifest.8.0.50727.193.98CB24AD_52FB_DB5F_FF1F_C8B3B9A1E18E light.exe(0,0): Warning LGHT1076: ICE03: String overflow (greater than length permitted in column); Table: Component, Column: KeyPath, Key(s): downlevel_manifest.8.0.50727.762.9BAE13A2_E7AF_D6C3_FF1F_C8B3B9A1E18E light.exe(0,0): Warning LGHT1076: ICE03: String overflow (greater than length permitted in column); Table: Component, Column: KeyPath, Key(s): downlevel_manifest.8.0.50727.100.9BAE13A2_E7AF_D6C3_FF1F_C8B3B9A1E18E light.exe(0,0): Warning LGHT1076: ICE03: String overflow (greater than length permitted in column); Table: Component, Column: KeyPath, Key(s): downlevel_manifest.8.0.50727.101.9BAE13A2_E7AF_D6C3_FF1F_C8B3B9A1E18E light.exe(0,0): Warning LGHT1076: ICE03: String overflow (greater than length permitted in column); Table: Component, Column: KeyPath, Key(s): downlevel_manifest.8.0.50727.103.9BAE13A2_E7AF_D6C3_FF1F_C8B3B9A1E18E light.exe(0,0): Warning LGHT1076: ICE03: String overflow (greater than length permitted in column); Table: Component, Column: KeyPath, Key(s): downlevel_manifest.8.0.50727.104.9BAE13A2_E7AF_D6C3_FF1F_C8B3B9A1E18E light.exe(0,0): Warning LGHT1076: ICE03: String overflow (greater than length permitted in column); Table: Component, Column: KeyPath, Key(s): downlevel_manifest.8.0.50727.193.9BAE13A2_E7AF_D6C3_FF1F_C8B3B9A1E18E light.exe(0,0): Warning LGHT1076: ICE03: String overflow (greater than length permitted in column); Table: Registry, Column: Registry, Key(s): reg_downlevel_manifest.8.0.50727.100.98CB24AD_52FB_DB5F_FF1F_C8B3B9A1E18E light.exe(0,0): Warning LGHT1076: ICE03: String overflow (greater than length permitted in column); Table: Registry, Column
[WiX-users] Problems with Dependencies inVotive
I've added this to my project: ItemGroup Content Include=..\setupdude\dude.cabLinkdude.cab/Link/Content /ItemGroup When I reload the project in vs2005, this is what ends up in the file. ItemGroup Content Include=..\setupdude\release\dude.cab Linkdude.cab/Link /Content /ItemGroup ItemGroup Folder Include=..\ / Folder Include=..\setupdude\ / Folder Include=..\setupdude\release\ / /ItemGroup I tried adding a folder structure manually first, but that looks like it's going to lead to trouble. When I create the first folder (..), I get a warning message that it exists already, but it does get added to the project. Then when I try to add a new folder to .., a new tree gets created. So, it looks like this isn't working correctly in the UI. I haven't checked if the msbuild file on its own works or not. Any thoughts? Anthony Wieser Wieser Software Ltd - Original Message - From: Justin Rockwood [EMAIL PROTECTED] To: 'Anthony Wieser' [EMAIL PROTECTED]; Justin Rockwood [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Sent: Friday, March 23, 2007 9:54 PM Subject: Re: [WiX-users] Problems with Post Build Step and Dependencies inVotive In Visual Studio, when you select Add Existing File... if you just click Add, then the file will be copied to your local directory. This is by design and works the same way as C#, VB, etc. If you want to add a link, which you do, then drop down the little arrow next to the Add you'll see an Add As Link option. You want to select that. This will then populate your MSBuild (.wixproj) file for you correctly. You will not be allowed to Delete that file, but you can remove the link from your project. Does this make sense? To do this manually, you have to do this: Content Include=relative path to file LinkHow you want the file to appear in your project/Link /Content A more concrete example: Content Include=..\Release\MyExe.exe LinkMyExe.exe/Link /Content You shouldn't get messy directory structures if you do this approach. Justin -Original Message- From: Anthony Wieser [mailto:[EMAIL PROTECTED] Sent: Friday, March 23, 2007 7:38 AM To: Justin Rockwood; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Problems with Post Build Step and Dependencies in Votive - Original Message - From: Justin Rockwood [EMAIL PROTECTED] To: 'Anthony Wieser' [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Sent: Thursday, March 22, 2007 6:40 PM Subject: RE: [WiX-users] Problems with Post Build Step and Dependencies in Votive Do you mind logging a bug on the _TimeStampAfterCompile? I'll look into that. Done. As far as forcing a recompile... You can do that by including your inputs into your .wixproj project file as Content elements. In Votive, you do this by selecting Content from the Build Type property in the property browser (hit F4 if it's not showing). If you're working just with the MSBuild .wixproj file, you can just add ContentRelative path to file/Content in an ItemGroup section. When compiling, I account for the Content elements to trigger a rebuild if they change. Justin I can't get this to work with Votive. My solution is structured as follows: Proj-root | |-Main Program Project | |-Debug | |-Release [exe to depend on is here] | |-Wix Project ||-bin ||--Release [msi ends up here] In my project in VS2005, I right click on the Wix project, and choose Add Existing Item... When I navigate up the hierarchy to release, what happens is that a copy of the selected .exe file ends up in the Wix Project folder. the .wixproj file contains: ItemGroup Content Include=myprog.exe /ItemGroup Is that correct? Manually editing as suggested above to Content Include=..\release\myprog.exe makes the project expand into a messy disaster of .. folders, which presumably isn't correct either. Especially as there are 3 .. based folders! looking at the aftermath of that, this is what ends up in the wixproj file: ItemGroup Folder Include=..\ / Folder Include=..\release / /ItemGroup Being of a suspicious nature, I created another folder, and then deleted it, and found it was removed from my disk. I dread to think what will happen if I try to delete one of these from within votive, but why not? Don'tTryThisAtHome Deleting the .exe shown under folder release under folder .. does indeed delete the exe from the release... Deleting the folder release under the folder .. the exe was in: You guessed it. The folders gone. Deleting the other folder release that was under the populated .. tries to delete, but, instead gives: Internal MSBuild Error: No parent BuildItemGroup for item to be removed. /Don'tTryThisAtHome Even I'm not brave enough to delete my parent folder, which contains the project I'm in and everything else. Ideally, I'd like to link in the outputs
Re: [WiX-users] Wix votive stable version
Can you, or anyone else for that matter, insert a link to another project, as Justin described here: Subject: Re: [WiX-users] Problems with Post Build Step and Dependencies inVotive In Visual Studio, when you select Add Existing File... if you just click Add, then the file will be copied to your local directory. This is by design and works the same way as C#, VB, etc. If you want to add a link, which you do, then drop down the little arrow next to the Add you'll see an Add As Link option. You want to select that. This will then populate your MSBuild (.wixproj) file for you correctly. You will not be allowed to Delete that file, but you can remove the link from your project. Does this make sense? There is no add as link option shown on my system when I right click the project on my my system. Add shows New Item Existing Item and Folder. Am I looking in the wrong place? Anthony Wieser Wieser Software Ltd - Original Message - From: Chris Bardon To: Nitin Chaudhari ; wix-users@lists.sourceforge.net Sent: Tuesday, March 27, 2007 3:20 PM Subject: Re: [WiX-users] Wix votive stable version So far, I've been using the Votive 3.0 build without any problems. I think the only thing unstable about the build is that there could be breaking changes in future releases that mean you'll have to change your code. Other than the environment variable macros (being able to refer to project output) not being in the 3.0 build, it seems to be much fuller featured than 2.0. Chris - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] What exactly is SourceDir?
Thanks for that. Very useful. What I hadn't understood is that there are two trees being set up in parallel, the SourceDir, which is strictly hierarchical, and and target location, which can suddenly jump anywhere. I assume the name side can't have properties set in it, which lets the tree jump somewhere else, correct? Where does the source dir hierarchy actually exists though? Is there a way to get the msi file to refer to external files that I've missed somewhere? Anthony Wieser Wieser Software Ltd From: Rob Mensching [EMAIL PROTECTED] You might read through this blog series of mine on my old blog: http://blogs.msdn.com/robmen/archive/2006/10/12/deciphering-the-msi-directory-table-part-6-standard-directories.aspx -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anthony Wieser Sent: Saturday, March 24, 2007 12:02 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] What exactly is SourceDir? In all of the samples you see fragments like this: Directory Id=TARGETDIR Name=SourceDir Directory Id=MFR Name=Wieser Software Ltd Directory Id=INSTALLLOCATION Name=Prog Component Id=ProductComponent Guid=MYGUIDHERE File Id=MainProgram Name=prog.exe Source=prog.cab DiskId=1 / /Component /Directory /Directory /Directory I don't really understand what the SourceDir is above, even though it seems to be required (you get a warning if it's not there). Looking through the logs, the SourceDir always seems to be set to the path of the msi file that's run, if its on a network, or even a drive created by subst. However, the TARGETDIR seems always to be set to C:\ Also, why are the other directories listed as a child of TARGETDIR, when they can in fact be located anywhere in the file system. Is it just a pragmatic solution, that requires a single top level node for parsing? Anthony Wieser Wieser Software Ltd - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Custom actions and per user installs, and UAC problems
I've built my msi installer now, and tried to launch the CE App Manager: Here's how I got my properties. Property Id=CEAPPMGR RegistrySearch Id=CEAPPMGRCMD Root=HKLM Type=raw Key=SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\CEAPPMGR.EXE /RegistrySearch /Property Property Id=CEAPPMGRDIR RegistrySearch Id=CEAPPMGRD Root=HKLM Type=file Key=SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\CEAPPMGR.EXE /RegistrySearch /Property Then I install my files to the folder (I'm not sure why this used to be the preferred place--in a subfolder of ceappmgr, but there you go). Condition Message=Microsoft ActiveSync or Windows Mobile Device Center software is required to install this software. CEAPPMGR /Condition Directory Id=TARGETDIR Name=SourceDir Directory Id=CEAPPMGRDIR Directory Id=MFR Name=Wieser Software Ltd Directory Id=INSTALLLOCATION Name=Dude Component Id=ProductComponent Guid=17524da5-7862-470b-bffc-db6ce4a660a1 File Id=MainProgram Name=Dude.cab Source=$(var.dude.TargetPath)\Dude.cab DiskId=1 /File File Id=CeInstall Name=DudeF.ini Source=DudeF.ini DiskId=1 /File File Id=ReleaseTxt Name=release.txt Source=.\release.txt / /Component /Directory /Directory /Directory /Directory So far, so good. The UAC consent pops up on vista, and then the files end up in their correct location. Then it's time to run the CEAPPMGR command to load the files onto the device. I tried deferred actions, etc, but to no avail. First the solution so far, then the questions at the bottom: In the end I had to resort to this: InstallExecuteSequence Custom Action='RegisterWithDevice' After=InstallFinalizeNOT Installed /Custom /InstallExecuteSequence CustomAction Id=RegisterWithDevice ExeCommand='[CEAPPMGR] [INSTALLLOCATION]DudeF.ini' Directory=INSTALLLOCATION Return=ignore/ Unfortunately, this only works if you're running as an administrator, and if you set Property Id=ALLUSERS Value=1/Property My Questions: CEAPPMGR seems to require it to be run with admin privileges. I've already specified that the msi file run elevated, but the actions seem to run as the user, or in the namespace of the administrator, which still causes the program not to be installed for the current user. Is there a better way around this? Do I need to build a special EXE to run that does the dirty work, which requests the elevation in its manifest instead. Secondly, is there a really good description anywhere of what the difference between per user and per machine installs actually is? When I ran the install from an elevated command prompt, it installed on my device, but then when I next started the app manager on my account, it tried to install the software again. (not sure why). Clearly, this isn't quite right either. I've gotten in such a mess trying to get this simple thing right so that it's easy for my users to do. I've filled up my system restore log, and lost all prior install points except for the last 20 or so, which are all installing and uninstalling this. To make matters worse, it then decided it wouldn't uninstall, and I had to resort to a rollback, which caused some other installers to be abandoned. I'm starting to wonder if I should go back to the old procedural way of doing things, and copy the cab file into the right location, then run CEAPPMGR. Anthony Wieser Wieser Software Ltd - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] What exactly is SourceDir?
In all of the samples you see fragments like this: Directory Id=TARGETDIR Name=SourceDir Directory Id=MFR Name=Wieser Software Ltd Directory Id=INSTALLLOCATION Name=Prog Component Id=ProductComponent Guid=MYGUIDHERE File Id=MainProgram Name=prog.exe Source=prog.cab DiskId=1 / /Component /Directory /Directory /Directory I don't really understand what the SourceDir is above, even though it seems to be required (you get a warning if it's not there). Looking through the logs, the SourceDir always seems to be set to the path of the msi file that's run, if its on a network, or even a drive created by subst. However, the TARGETDIR seems always to be set to C:\ Also, why are the other directories listed as a child of TARGETDIR, when they can in fact be located anywhere in the file system. Is it just a pragmatic solution, that requires a single top level node for parsing? Anthony Wieser Wieser Software Ltd - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Install to directory contained in registry path [SOLVED]
Thanks for your suggestions bob. The answer to most every MSI-related question is check a verbose log. A verbose log on MSI 3.x contains entries for every property change or deletion so you can see when MSI is setting it. I was doing that, but was obviously too tired to make sense of it. When I looked last night, it just wasn't setting the values; only using defaults. Not having a working install sample that I knew to work, it was difficult to know what a good log looked like. First, I try to read in the properties at the top of the file from the registry: Property Id=CEAPPMGRDIR Value=c:\defaultdir\ RegistrySearch Id=CEAPPMGRDIRreg Root=HKLM Type=directory Key=SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\CEAPPMGR.EXE Name=c:\crud\crud\myapp.txt/RegistrySearch /Property The MSI doc is woefully inadequate when it comes to the types of registry searches but I can tell you with high certainty that it won't convert a file path to a directory. It's likely never setting your property, because it doesn't match what you've told it to look for. Starting again fresh today, I've tweaked it piece by piece, and come up with this: Property Id=CEAPPMGR RegistrySearch Id=CEAPPMGRCMD Root=HKLM Type=raw Key=SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\CEAPPMGR.EXE /RegistrySearch /Property Property Id=CEAPPMGRDIR RegistrySearch Id=CEAPPMGRD Root=HKLM Type=file Key=SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\CEAPPMGR.EXE /RegistrySearch /Property Strangely, the raw type reads the whole string (I was expecting extra characters on the front specifying the type of information contained, but on re-reading, I see regular strings aren't decorated), and the file type reads the path portion. If you use directory, nothing is read, as you suggested. Then to install files into the found location, use this fragment Directory Id=TARGETDIR Name=SourceDir Directory Id=CEAPPMGRDIR Directory Id=MFR Name=Wieser Software Ltd Directory Id=INSTALLLOCATION Name=Prog Component Id=ProductComponent Guid=MYGUIDHERE File Id=MainProgram Name=prog.cab Source=prog.cab DiskId=1 /File File Id=ReleaseTxt Name=release.txt Source=.\release.txt / /Component /Directory /Directory /Directory /Directory as shown before. It took me awhile to realize that you could use other names that were previously set as the ID without specifying a name, as is the case in the use of CEAPPMGRDIR above. This raises a question about SouruceDir, which I've started another topic on. The other thing that puzzled me was the use of the name SourceDir above, which is required. What I don't understand is why the other folders are listed below this in the hierarchy. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Accessing the Source Directory
From: Rob Mensching [EMAIL PROTECTED] To: Geoff Finger [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Sent: Friday, March 23, 2007 12:28 AM Subject: Re: [WiX-users] Accessing the Source Directory Why are you copying files from the original media instead of just using the File element? While I'm not the original poster on this, I considered doing the same, and was looking for a solution (though I've not implemented it). I develop software which is distributed by a by a company who don't want a complicated build process. As a result, I've given them a directory tree which has my installer and autorun.inf, and a couple of folders that contain customer specific calibration files. In addition, we support customizable language files, which are installed into these extra folders as well. All of these files are of the form: strings.XXX where XXX is the primary language identifier. As a result, I don't need to know (and in fact don't) exactly which files are being sent to customers, yet the installation just works. Because it's built this way, my client doesn't need to have build tools installed on their PC. They just need to copy the customers calibration into the directory structure, and then copy the files to disk. Most of the installation remains unchanged, and therefore under version control. I was considering building a custom action that copied all of the files across from the installation folder, but if there's a better way, I'd love to hear it. Anthony Wieser Wieser Software Ltd - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Problems with Post Build Step and Dependencies in Votive
- Original Message - From: Justin Rockwood [EMAIL PROTECTED] To: 'Anthony Wieser' [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Sent: Thursday, March 22, 2007 6:40 PM Subject: RE: [WiX-users] Problems with Post Build Step and Dependencies in Votive Do you mind logging a bug on the _TimeStampAfterCompile? I'll look into that. Done. As far as forcing a recompile... You can do that by including your inputs into your .wixproj project file as Content elements. In Votive, you do this by selecting Content from the Build Type property in the property browser (hit F4 if it's not showing). If you're working just with the MSBuild .wixproj file, you can just add ContentRelative path to file/Content in an ItemGroup section. When compiling, I account for the Content elements to trigger a rebuild if they change. Justin I can't get this to work with Votive. My solution is structured as follows: Proj-root | |-Main Program Project | |-Debug | |-Release [exe to depend on is here] | |-Wix Project ||-bin ||--Release [msi ends up here] In my project in VS2005, I right click on the Wix project, and choose Add Existing Item... When I navigate up the hierarchy to release, what happens is that a copy of the selected .exe file ends up in the Wix Project folder. the .wixproj file contains: ItemGroup Content Include=myprog.exe /ItemGroup Is that correct? Manually editing as suggested above to Content Include=..\release\myprog.exe makes the project expand into a messy disaster of .. folders, which presumably isn't correct either. Especially as there are 3 .. based folders! looking at the aftermath of that, this is what ends up in the wixproj file: ItemGroup Folder Include=..\ / Folder Include=..\release / /ItemGroup Being of a suspicious nature, I created another folder, and then deleted it, and found it was removed from my disk. I dread to think what will happen if I try to delete one of these from within votive, but why not? Don'tTryThisAtHome Deleting the .exe shown under folder release under folder .. does indeed delete the exe from the release... Deleting the folder release under the folder .. the exe was in: You guessed it. The folders gone. Deleting the other folder release that was under the populated .. tries to delete, but, instead gives: Internal MSBuild Error: No parent BuildItemGroup for item to be removed. /Don'tTryThisAtHome Even I'm not brave enough to delete my parent folder, which contains the project I'm in and everything else. Ideally, I'd like to link in the outputs of the same configuration somehow into the dependency tree, though I'm not sure how to do that now. Any ideas? Anthony Wieser Wieser Software Ltd p.s. What's the proper protocol for replies like this? Should they go to the author and the list, or just the list? - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Problems with Post Build Step and Dependencies in Votive
- Original Message - From: Justin Rockwood [EMAIL PROTECTED] To: 'Anthony Wieser' [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Sent: Thursday, March 22, 2007 6:40 PM Subject: RE: [WiX-users] Problems with Post Build Step and Dependencies in Votive Do you mind logging a bug on the _TimeStampAfterCompile? I'll look into that. Done. As far as forcing a recompile... You can do that by including your inputs into your .wixproj project file as Content elements. In Votive, you do this by selecting Content from the Build Type property in the property browser (hit F4 if it's not showing). If you're working just with the MSBuild .wixproj file, you can just add ContentRelative path to file/Content in an ItemGroup section. When compiling, I account for the Content elements to trigger a rebuild if they change. Justin I can't get this to work with Votive. My solution is structured as follows: Proj-root | |-Main Program Project | |-Debug | |-Release [exe to depend on is here] | |-Wix Project ||-bin ||--Release [msi ends up here] In my project in VS2005, I right click on the Wix project, and choose Add Existing Item... When I navigate up the hierarchy to release, what happens is that a copy of the selected .exe file ends up in the Wix Project folder. the .wixproj file contains: ItemGroup Content Include=myprog.exe /ItemGroup Is that correct? Manually editing as suggested above to Content Include=..\release\myprog.exe makes the project expand into a messy disaster of .. folders, which presumably isn't correct either. Especially as there are 3 .. based folders! looking at the aftermath of that, this is what ends up in the wixproj file: ItemGroup Folder Include=..\ / Folder Include=..\release / /ItemGroup Being of a suspicious nature, I created another folder, and then deleted it, and found it was removed from my disk. I dread to think what will happen if I try to delete one of these from within votive, but why not? Don'tTryThisAtHome Deleting the .exe shown under folder release under folder .. does indeed delete the exe from the release... Deleting the folder release under the folder .. the exe was in: You guessed it. The folders gone. Deleting the other folder release that was under the populated .. tries to delete, but, instead gives: Internal MSBuild Error: No parent BuildItemGroup for item to be removed. /Don'tTryThisAtHome Even I'm not brave enough to delete my parent folder, which contains the project I'm in and everything else. Ideally, I'd like to link in the outputs of the same configuration somehow into the dependency tree, though I'm not sure how to do that now. Any ideas? Anthony Wieser Wieser Software Ltd p.s. What's the proper protocol for replies like this? Should they go to the author and the list, or just the list? - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Install to directory contained in registry path
I thought I'd got the hang of this, but just can't understand what's going on. I need to install a file to a location specified in the registry, and need some help. so, the location I'm searching for (and probably many others) is located at: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\CEAPPMGR.EXE which is the location that the WIndows Mobile installer is located, as an exe file. I need to strip the exe off to find the location, so that I can install into my folder below there. Then at the end of the install, I need to run the specified exe with some additional arguments (the name of my cab file in fact). Some of you will now recognize that this is the standard way to install an app on a windows mobile device. First, I try to read in the properties at the top of the file from the registry: Property Id=CEAPPMGRDIR Value=c:\defaultdir\ RegistrySearch Id=CEAPPMGRDIRreg Root=HKLM Type=directory Key=SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\CEAPPMGR.EXE Name=c:\crud\crud\myapp.txt/RegistrySearch /Property So, I try in my WiX project to define my directory strructure thus: Directory Id=TARGETDIR Name=SourceDir Directory Id=CEAPPMGRDIR Directory Id=MFR Name=Wieser Software Ltd Directory Id=INSTALLLOCATION Name=Prog Component Id=ProductComponent Guid=MYGUIDHERE File Id=MainProgram Name=prog.cab Source=prog.cab DiskId=1 /File File Id=ReleaseTxt Name=release.txt Source=.\release.txt / /Component /Directory /Directory /Directory /Directory Unfortunately, the files get installed into: c:\defaultdir However, the registry key I'm searching for specifies this (exported from my registry) Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\CEAPPMGR.EXE] @=C:\\Windows\\WindowsMobile\\CEAppMgr.exe Any ideas what stupid error I've made in my code above? Anthony Wieser Wieser Software Ltd - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Problems with Post Build Step and Dependencies inVotive
Subject: Re: [WiX-users] Problems with Post Build Step and Dependencies inVotive In Visual Studio, when you select Add Existing File... if you just click Add, then the file will be copied to your local directory. This is by design and works the same way as C#, VB, etc. If you want to add a link, which you do, then drop down the little arrow next to the Add you'll see an Add As Link option. You want to select that. This will then populate your MSBuild (.wixproj) file for you correctly. You will not be allowed to Delete that file, but you can remove the link from your project. Does this make sense? There is no add as link option shown on my system when I right click the project on my my system. Add shows New Item Existing Item and Folder. Am I looking in the wrong place? Anthony Wieser Wieser Software Ltd - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Problems with Post Build Step and Dependencies inVotive
- Original Message - From: Justin Rockwood To: 'Anthony Wieser' ; Justin Rockwood ; wix-users@lists.sourceforge.net Sent: Friday, March 23, 2007 9:18 PM Subject: RE: [WiX-users] Problems with Post Build Step and Dependencies inVotive Right mouse click on your project -- Add/Existing Item -- an open dialog pops up -- the Add button is actually a drop down button à click on Add As Link. Here's a screen shot. There's no drop down on my Vista system. Anthony Wieser Wieser Software Ltd - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Problems with Post Build Step and Dependencies inVotive
- Original Message - From: Justin Rockwood To: 'Anthony Wieser' ; Justin Rockwood ; wix-users@lists.sourceforge.net Sent: Friday, March 23, 2007 9:18 PM Subject: RE: [WiX-users] Problems with Post Build Step and Dependencies inVotive Right mouse click on your project -- Add/Existing Item -- an open dialog pops up -- the Add button is actually a drop down button à click on Add As Link. Here's a screen shot. It's also not a drop down on my XP system either. Anthony Wieser Wieser Software Ltd - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Problems with Post Build Step and Dependencies in Votive
Hi, I'm trying to set up my project to automatically sign my msi files, so I've added a a post build step that looks like this: signcode CERTIFICATE ARGUMENTS HERE -t http://timestamp.verisign.com/scripts/timstamp.dll $(TargetDir)AutoSharesWx.msi and the run post build event is set to: When the build updates the project output That all seems to work fine, though you get a strange error if the build fails: 1C:\Program Files\MSBuild\Microsoft\WiX\v3.0\Wix.targets(360,7): Error MSB4057: The target _TimeStampAfterCompile does not exist in the project. Ignoring that though, what I really want to be able to do is set dependencies on my Votive project to force it to recompile when my inputs change (say A.exe as an example). I've tried adding A.exe as a reference, but that doesn't work, nor does adding it as an embedded resource in the project. I must be missing something. Anthony Wieser Wieser Software Ltd - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Problems with custom bitmaps with wixUI
I've been tearing my hair out trying to figure out why my bitmaps for my dialog are getting a set of grid lines drawn across them. I've finally got my install working with the latest build 3.0.2716.0 after changing things to match the new methods, but still have the same problem with the bitmaps. I've added this as a bug (1684217), but on reading it looks like I should have brought it up here first, so sorry if I got the protocol wrong. I'm new to this open source stuff. Any ideas how I can avoid this? I'm including the files thus: WixVariable Id=WixUILicenseRtf Value=license.rtf / WixVariable Id=WixUIBannerBmp Value=bitmaps\banner.bmp / WixVariable Id=WixUIDialogBmp Value=bitmaps\dialog.bmp / Anthony Wieser Wieser Software ltd - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
