Refer the ms guidelines, user data should remain after uninstall. So leaving a
trail that is expected.
System preferences... Now that's a different beast :)
Cheers,
Sascha
On 11/06/2012, at 11:52 PM, Jerra beddel...@gmail.com wrote:
In my application I use the built in functionality for
Hyperlink controls were introduced with MSI 5.0. Windows Installer 5.0
is available for Microsoft Windows 7 and Windows Server 2008 R2.
http://msdn.microsoft.com/en-us/library/dd407936(v=VS.85).aspx
So yes, if you target MSI 5.0 and don't require installation on older
operating systems.
On Fri,
Have you taken a look at the documentation on registering preview
handlers? http://msdn.microsoft.com/en-us/library/cc144144(VS.85).aspx
explains pretty much everything in detail.
Here's some sample code for installing a 32-bit native code handler on
both 32 and 64-bit systems, hope this helps.
Try this... the user will see a UAC prompt, same as if the application
was manually launched. There's no way around this, but our users have
never complained.
Fragment
CustomAction Id=SetElevatedAppTarget
Property=WixShellExecTarget Value=[#ElevatedApp.exe] /
FYI, Stackoverflow.com is pretty responsive :)
P.S. Is there a good forum that discusses MSI issues? I am pretty new
to this and I don't want to bother the WiX community with noobish
installer questions.
--
ThinkGeek
You'll need to ship two separate MSI files if you want to do this
using Windows Installer.
On Thu, Jun 17, 2010 at 5:57 AM, Blair os...@live.com wrote:
It is by design of Windows Installer.
-Original Message-
From: David Watson [mailto:dwat...@sdl.com]
Sent: Wednesday, June 16, 2010
I'm using the following code (Sample code I found, not originally
written by me) which I haven't had any problems with. According to
msi.chm PMSIHANDLE objects are automatically closed as they go out of
scope, which doesn't happen for MSIHANDLE -- if you're using
MSIHANDLE you're required to
Ahh... that sounds more a setup design problem ;)
I'm pretty sure I saw a thread recently about strange behaviour when
displaying additional InstallUISequence dialogs for configuration
after InstallExecuteSequence has completed. Sounds similar...
In my opinion you should gather configuration
Yes, but nothing free I'm aware of :)
We use IRMakeBootstrap that is a component of MSI Factory
(http://www.indigorose.com/products/msi-factory/) - you don't need to
use MSI Factory, the bootstrapper is a self-contained component that
can be integrated into any build process. Unfortunately an MSI
I answered a similar question a while back, this is by design of
Windows Installer to support Advertised installations. It all makes
sense once you read the documentation on the Icon table
[http://msdn.microsoft.com/en-us/library/aa369210(VS.85).aspx] -
specifically the following paragraph:
The
Windows Installer and Windows does have a way to deal with this
situation... it's called the Restart Manager ;)
http://msdn.microsoft.com/en-us/library/aa373524(VS.85).aspx
If you implement restart manager support, Windows Installer can ask
your app nicely to shut down and release the file locks,
The approach suggested by Blair makes the most sense, if the files are
in the package already just install *all* files and update a registry
setting to indicate the desired MUI... alternatively automatically
load based desired MUI based on the current locale.
On Tue, Jun 1, 2010 at 6:11 AM,
version.
-Original Message-
From: Sascha Beaumont [mailto:sascha.beaum...@gmail.com]
Sent: Tuesday, May 25, 2010 2:18 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Do UFOs visit Install land?
Have you tried using merge modules rather than
Try http://www.robmensching.com/ :)
On Thu, May 27, 2010 at 7:51 PM, Francesc Castells
fcaste...@dgtexperts.com wrote:
Hi,
I was hoping to find a WIX expert to help me with my installer needs. I
posted jobs at oDesk and Elance and I tried several developers and after
several months and quite
Have you tried using merge modules rather than the redistributable?
On Tue, May 25, 2010 at 4:35 AM, Tony Juricic tjuri...@tradestation.com wrote:
Hi Phil,
Here are the missing context and details.
The app is 32 bit. It was built with C++ redistributables version
9.0.30729.4148. Exactly
I used to have a similar problem with a Merge Module we were consuming
from a third party, when we would call the COM object on some systems
this would always trigger a repair.
Eventually we traced it back to some .NET conditions included in the
module (we weren't using the wrappers, only native
Hi,
Is there any reference with a complete summary of the new elements
(e.g. MajorUpgrade) in WiX 3.5? Ideally I'm looking for a complete
reference (even if it's just a list of a few blog posts) of the
changes so far before I begin migration and cleaning up my sources.
I'm in the process of
You need to manually extract the required icons. Your desired behavior
is to only embed the required icon, but WiX just provides a way to
declare Windows Installer packages and this behavior isn't the way
Windows Installer works due to how packages are handled when
advertised.
As specified in
See
http://stackoverflow.com/questions/1792782/wix-how-can-i-launch-a-help-file-after-installation-wixui-exitdialogoptionalc
Basically you just need to launch [WindowsFolder]hh.exe with your CHM
as a parameter, rather than trying to launch the CHM itself.
Sascha
On Thu, May 6, 2010 at 6:40
Not as far as I know, check Heaths blog for a relevant post on this
(windows installer setting TARGETDIR to a USB drive for example) -
http://blogs.msdn.com/heaths/archive/2010/02/26/testing-for-components-that-install-under-targetdir.aspx
The underlying problem is technically that USB drive
Try [WindowsFolder]hh.exe,0 for the icon
On Mon, May 3, 2010 at 7:53 PM, subramanyeswari sravi...@yahoo.com wrote:
thanks.
I have added non-advertised shortcut in my code. here is the code
Shortcut Id=startmenuAdv Directory=testshortcut Advertise=no
Name=Test Books Online
Secure is not required to pass from the UI to the Execute sequence,
it's required to pass to the *server side* in the Execute sequence.
(i.e. deferred CAs)
Take a look at the diagram on
http://blogs.msdn.com/rflaming/archive/2006/09/21/765452.aspx - Pink
is UI, Yellow is Execute and Green is
I would suggest opening a bug/support case with the team build guys :)
It doesn't sound like this is a WiX bug...
On Thu, Apr 29, 2010 at 11:59 PM, Will Sullivan wsulli...@softdocs.com wrote:
This is going to start hitting big, as people encounter ICE validation
failures on a team build.
What do you mean by THE_USER_ACCOUNT? That's a vague reference that
doesn't sound like anything in the MSDN documentation ;)
Maybe on THE_INTERNET? /grin
On Fri, Apr 30, 2010 at 5:44 AM, Wix Mailing List w...@danhinsley.com wrote:
Is there a list somewhere of things like THE_USER_ACCOUNT and
You can probably just drop the 32-bit MSVCR71.dll straight into your
application folder rather than worrying about a merge module.
On Wed, Apr 28, 2010 at 4:21 AM, jeff00seattle
jeff_tan...@earthlink.net wrote:
Hi
I am building a WiX x64 install and I want to merge into the install an MSM
Oohhh... nifty! Thanks for pointing that out Bob :)
On Sun, Apr 25, 2010 at 11:42 PM, Bob Arnson b...@joyofsetup.com wrote:
On 4/22/2010 7:29 PM, Sascha Beaumont wrote:
No, heat doesn't harvest 64-bit information.
I just do a find/replace (sed would work from the command line if it
needs
The condition should include Installed OR so that the condition
always succeeds in a repair/remove situtation.
Condition Message=This installer is designed for IIS7. Use the IIS6
installer.
![CDATA[Installed OR IISMAJORVERSION = #7]]
/Condition
From memory the easiest solution here is to
You can happily build MSIs targeting the x64 platform on x86 boxes,
there's no problem there. They just won't *run* on x86 boxes.
FWIW, I have a dedicated x86 VM for running WiX builds and I have
never had a problem outputting MSI files targeting the x64
architecture.
Sascha
On Fri, Apr 23,
No, heat doesn't harvest 64-bit information.
I just do a find/replace (sed would work from the command line if it
needs scripting)
Find: Guid=*
Replace: Guid=* Win64=yes
Sascha
On Fri, Apr 23, 2010 at 9:22 AM, jeff00seattle
jeff_tan...@earthlink.net wrote:
Hi
I am using heat.exe of WiX
.
On Tue, Apr 20, 2010 at 2:02 AM, Sascha Beaumont
sascha.beaum...@gmail.comwrote:
So you want to prevent repair, uninstall and upgrades? Ugh.
If the Product ID isn't changing, Windows Installer should bail
automatically with Another version of this product is already
installed from memory
You want to use a MaskedEdit control instead.
wix.sourceforge.net/manual-wix3/wix_xsd_control.htm
http://msdn.microsoft.com/en-us/library/aa369797(VS.85).aspx
Sascha
On Wed, Apr 21, 2010 at 6:29 AM, Vishwajit Walke
vishwajit.wa...@matrikon.com wrote:
Hi,
I've a text box in my custom dialog
Well a folder isn't an application, when you open a folder it's
being shown using Explorer.exe - try as a parameter to that
On Thu, Apr 22, 2010 at 12:26 PM, Sach sachinth...@gmail.com wrote:
I changed the code as follows:
!-- Desktop Shortcut Test --
Directory Id=DesktopFolder
If Target=[CommonAppDataFolder]\MT\STR fails, then try
Target=quot;[WindowsFolder]Explorer.exequot;
quot;[CommonAppDataFolder]\MT\STRquot;
On Tue, Apr 20, 2010 at 4:27 PM, Sach sachinth...@gmail.com wrote:
[CommonAppDataFolder]\MT\STR
No idea then sorry, suggest looking at the log files and seeing if you
can debug the issue. Additionally see if you can manually create a
shortcut with the settings suggested and see if that works
On Thu, Apr 22, 2010 at 1:17 PM, Sach sachinth...@gmail.com wrote:
Still no luck Sascha.
:(
I
So you want to prevent repair, uninstall and upgrades? Ugh.
If the Product ID isn't changing, Windows Installer should bail
automatically with Another version of this product is already
installed from memory, if you're using an automatically generated
Product ID you can use the fact that Windows
This sounds like a design problem, not a setup problem and
*definitely* not a WiX problem... you will get a better answer by
asking on stackoverflow.com or some other developer forum.
Some suggestions off the top of my head...
- build a Merge Module that 3rd party apps can consume (and so can
Your custom action is failing... try setting CustomAction/@Return=ignore
On Tue, Apr 20, 2010 at 10:24 AM, Pierson Lee (PIE)
pierson@microsoft.com wrote:
Trying to uninstall a service and it fails to uninstall. Log shows:
MSI (s) (68:00) [17:20:43:678]: Invoking remote custom action.
Have you tried searching the mailing list archive? This same question
has been asked and answered virtually *every single week*.
The official answer from the team has been when it's done. Try
asking in another 6 months and you might get a better response :)
Personally I use the irmakebootstrap
Have you read the manual? Checked the archives?
http://blogs.technet.com/alexshev/archive/2008/02/20/from-msi-to-wix-part-10-shortcuts.aspx
http://wix.sourceforge.net/manual-wix3/wix_xsd_shortcut.htm
http://n2.nabble.com/Shortcut-to-Folder-example-td710954.html
On Fri, Apr 16, 2010 at 10:40
see how I can solve this...
Thanks again for your help,
Francesc
On Wed, Apr 14, 2010 at 1:39 AM, Sascha Beaumont
sascha.beaum...@gmail.comwrote:
Most likely your CA is running deferred and with elevated privileges,
try setting CustomAction/@Impersonate=true
On Wed, Apr 14, 2010 at 12
Bad bad bad bad bad...
Rob put together a good post explaining why it's so nasty...
http://robmensching.com/blog/posts/2009/3/6/More-on-Haacks-Troubleshooting-Windows-MSI-Installers
On Wed, Apr 14, 2010 at 11:26 PM, Johann Taferl, T-AU
johann.taf...@tecan.com wrote:
Hi,
try using the
See my post earlier this week
(http://n2.nabble.com/correct-upgrade-table-td4876031.html) showing
the solution I've come up with to prevent the user from installing
different 'builds' of the same product.
On Wed, Apr 14, 2010 at 6:13 PM, Viv Coco vcotirl...@hotmail.com wrote:
I got into this
http://wix.sourceforge.net/manual-wix3/check_for_dotnet.htm
On Thu, Apr 15, 2010 at 9:37 AM, Vishwajit Walke
vishwajit.wa...@matrikon.com wrote:
On the similar lines can I detect the .Net Framework Installed or not ?
From: Vishwajit Walke
Sent: Wednesday, April 14, 2010 9:27 AM
To:
Most likely your CA is running deferred and with elevated privileges,
try setting CustomAction/@Impersonate=true
On Wed, Apr 14, 2010 at 12:53 AM, Francesc Castells
fcaste...@dgtexperts.com wrote:
Hi,
I have an installer that upgrades an old program and imports the data. To do
that, it opens
You can't do this while also using Product/@Id=*, a product with the
same version but different ID is seen as a different package. The best
solution that I've come up with is to increase the fourth version
field and block installation when the version number is the same.
Windows Installer ignores
Are you planning to support installation on Win9x systems?
If so, then yes you should address this warning. However if you're not
planning to support Win9x systems you can safely ignore this
limitation. See also the documentation on ICE47 -
UPGRADINGPRODUCTCODE is set when you're being uninstalled during an
upgrade, so it sounds like the wrong condition. For example to force a
CA to run on a full uninstall only, but not when it's being
uninstalled because an upgrade is happening I use
REMOVE ~= ALL AND NOT UPGRADINGPRODUCTCODE]
I
Hi Xmun,
Check out the series of blog posts at
http://blogs.msdn.com/rflaming/archive/tags/UAC+in+MSI/default.aspx on
understanding UAC and MSI. There's a lot to take in (27 posts?), but
it's a worthwhile read :)
Sascha
On Fri, Apr 9, 2010 at 12:38 AM, Xmun xmu...@gmail.com wrote:
Hi
I just use signtool.exe as a post-wix step in my build scripts and
sign the same way that I sign all my binaries
http://msdn.microsoft.com/en-us/library/aa387764(VS.85).aspx
On Sun, Apr 4, 2010 at 4:27 PM, ppremk prem.kumar.ponutho...@exact.com wrote:
Hello Guru's
I have begun my
I'm using nant with the candle/light tasks
On Wed, Apr 7, 2010 at 11:49 AM, ppremk prem.kumar.ponutho...@exact.com wrote:
Thanks for the input. Shall give this a shot.
When you say post build script.. do you mean you are using Votive to compile
or from command line?
thanks again.
cheers!
?
Thx,
Viv
On 3/29/2010 6:51 AM, Sascha Beaumont wrote:
Letting the user modify installed files will cause significant
headaches. Best solution, until you understand why, just don't do it.
Can you install a default configuration file and then copy that to the
user configuration
If this happens again... here's the procedure I usually follow
1) Fix the broken condition.. avoid making any other changes if possible.
2) On a broken machine, recache the MSI with msiexec /fv myproduct.msi
3) Uninstall as normal (the broken msi has been replaced with the
fixed one, and
Letting the user modify installed files will cause significant
headaches. Best solution, until you understand why, just don't do it.
Can you install a default configuration file and then copy that to the
user configuration if it doesn't exist? That way Windows Installer
doesn't 'know' about the
With MSI... nope.
You can try to work around the issue using ActiveSetup but that'll be
an undocumented and unsupported method.
Your best bet is to file a bug with your developers, this is something
that needs to be taken care of in the app rather than during setup
(i.e. recreate cache every
Sure, I'll contact you off-list :)
On Mon, Mar 8, 2010 at 4:25 AM, Christopher Painter
chr...@deploymentengineering.com wrote:
I've never done much by way of localization and while I'm trying to read
every help topic and blog article I can find, I was wondering if there are
any experts in
Flick an email to sascha.beaum...@nitropdf.com and I'll be more than
happy to help - my personal inbox is overloaded at the moment so
you'll get a quicker off-list response to my work address ;)
On Tue, Mar 9, 2010 at 2:27 PM, Sascha Beaumont
sascha.beaum...@gmail.com wrote:
Sure, I'll contact
If you require UAC elevation, then you need to ensure that it's a
deferred execution CA. Here's the example from the manual using
CAQuietExec :)
CustomAction Id=QtExecDeferredExampleWithProperty_Cmd
Property=QtExecDeferredExampleWithProperty
Something like the following condition might work, but remember UI is
optional so there should be a corresponding check/error in the
InstallExecuteSequence
INSTALLDIR
On Mon, Mar 8, 2010 at 11:57 PM, Pally Sandher pally.sand...@iesve.com wrote:
I'd do something similar to the checkbox on
I would say that VC++ automatically references/extracts/adds the item
for you without requiring an additional manual step, while WiX just
does exactly what you specify.
On Tue, Mar 9, 2010 at 10:34 AM, Kristoffer Danielsson
kristoffer.daniels...@live.se wrote:
I read this in the WIX tutorial:
What do you mean by this way? ;)
Here's a working fragment copied straight from our current release...
Fragment
CustomAction Id=SetLaunchApplicationTarget
Property=WixShellExecTarget Value=[#$(var.launchapplication)] /
CustomAction Id=LaunchApplication
If the issue is a registry key or something that includes the file
path, you could use the property [!filename] to get the short filename
of filename and write that to the registry. See
http://msdn.microsoft.com/en-us/library/aa368609(VS.85).aspx for more
information on the formatted text type.
MSI sees 1.2.3.10 and 1.2.3.9 as 1.2.3 - so they appear as the same
version. In order to prevent a downgrade on a 4th field change, you
can rely on the (documented) fact that MSI ignores the 4th field to
prevent installs where the version numbers are identical to Windows
Installer.
I use the
If you do use an empty file and want the file to be looked after by
Windows installer for patching, repair, etc - you can update the
filesize information post-build. Something like the following should
work (this is a somewhat simplified version of an actual script we
use)
Const MSI_SOURCE =
Unfortunately no. The EXE may contain a compressed MSI anyway :)
Microsoft Office, Visual Studio, etc. don't use the internal Windows
Installer UI - the UI is handled externally by the bootstrapper which
means you can drive installation of multiple MSI's.. If you take a
look at the Office DVD
much. Applying the 'WixShellExec' which is described in the
below link has worked perfectly.
http://wix.sourceforge.net/manual-wix3/run_program_after_install.htm
Thank you all for your great valued replies.
-Baris
-Original Message-
From: Sascha Beaumont
This seems wrong, I'm pretty sure users in the Administrators group
get the pre-Vista type behavior you're looking for.
I tested the code briefly before posting last week, unfortunately that
my 2008 R2 machine keeps locking up on me today so I can't confirm
right now.
If you're still stuck let
Hi,
Looking over
http://blogs.msdn.com/astebner/archive/2007/02/13/building-an-msi-using-wix-v3-0-that-includes-the-vc-8-0-runtime-merge-modules.aspx
I see the following note:
update date=2/11/2009 Removed references to policy MSMs because
the general recommendation is to not include policy
does one obtain the merge modules you listed below? I've not
been able to find the VC Runtime as a Merge Module.
-Original Message-
From: Sascha Beaumont [mailto:sascha.beaum...@gmail.com]
Sent: Monday, February 15, 2010 4:42 PM
To: General discussion for Windows Installer XML toolset
: Sascha Beaumont [mailto:sascha.beaum...@gmail.com]
Sent: Monday, February 15, 2010 2:42 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Microsoft merge modules and policy modules, what to
include?
Hi,
Looking over
http://blogs.msdn.com/astebner/archive/2007/02
Without MSIUSEREALADMINDETECTION set the user can run the MSI, but
they can't install the application. Once they press the 'Install'
button (with the UAC Shield) they'll be prompted to enter a username
and password to continue. With MSIUSEREALADMINDETECTION set to 1 then
the message will display.
I've never needed to feed anything back to the UI sequence from the
Execute sequence so I'm not sure of the limitations, if any.
However If you enable logging you'll be able to see when and where
properties are changed/modified, just search for PROPERTY CHANGE: in
the log.
Sascha
On Thu, Feb
Your install and config the services section is the issue, using WiX
you wouldn't run those commands directly - you would include the
relevant registry information in the MSI itself. That way if anything
goes wrong, Windows Installer can roll back the changes.
Without having the source code of
I use the following code to launch a program on finish, users are
always prompted to elevate, application manifest includes
requestedExecutionLevel level=requireAdministrator uiAccess=false
/
Fragment
CustomAction Id=SetAppTarget Property=WixShellExecTarget
What about writing a registry key (or keys) to indicate Dependencies
of Product A are installed ?
This could be a reference count that you increment when B, C, etc are
installed, or a more detailed description that indicates exactly what
products are installed. If you are using a bootstrapper you
I don't want to use cmd.exe and do it indirectly. I am sure that there is a
way to do that in WIX.
Not that I could find ;) Custom actions seem to launch from some
folder ... I never bothered trying to figure out which but it seemed
to be either system32, %temp% or the folder of the MSI
I have a small VBScript that uses
Scripting.FileSystemObject.GetFileVersion to retrieve the version of
my 'main' EXE. As part of my Nant script, I run the VBS, output to a
file, read it back in as a variable and then pass it as a command line
variable to WiX.
In my particular environment
When I interviewed for my current position I was asked about
familiarity with InstallShield, no questions about MSI itself. I
responded honestly that I had no idea, had used it once many moons ago
and found it complex, horrible and a pain to understand. What I didn't
realize for another 6+ months
You're not clear if you're referring to WiX DLLs, your own DLLs or 3rd
party DLLs.
WiX itself is licensed under the CPL, see CPL.TXT where you installed
WiX for more information.
Generally I follow the rule of thumb that if a Merge Module is
available, use that. Licensing is usually pretty clear
Welcome!
1) You will need separate 32 and 64-bit installers.
2) Starting from scratch will definitely be easier :)
3) If you're starting from scratch, just don't add a UI.
Hope that helps get you started..
On Fri, Jan 15, 2010 at 6:07 AM, Vern Graner v...@txis.com wrote:
Hello all. :)
I'm not too familiar with Administrative installs, but I would assume
you could condition something in the AdminExecuteSequence and
AdminUISequence to abort the install.
Aborting if a repair is triggered sounds like a very strange request,
what if your KeyPaths are damaged and you have advertised
remove issues) that should never be shipped until you fix them.
-Original Message-
From: Sascha Beaumont [mailto:sascha.beaum...@gmail.com]
Sent: Thursday, January 07, 2010 1:49 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Disable repair and admin
No, you would need to create your own external UI and bootstrapper.
On Wed, Dec 30, 2009 at 4:17 PM, Sanjay Rao
s...@noida.interrasystems.com wrote:
Hi All,
I have two issues for which I have not found any solution-
1. I need to change the icon of created MSI file using WIX.
2. I need to
The documentation indicates that it happens during AppSearch
(http://msdn.microsoft.com/en-us/library/aa367578(VS.85).aspx) -
RegistrySearch elements map to the RegLocator table in the MSI.
The AppSearch action searches for signatures using the CompLocator table
first, the RegLocator table
I would suggest shipping multiple merge modules (even if they are
interdependent for complete functionality) - we used to integrate
merge modules from a third party, they provided ~10 modules but our
software only needed 5 of the components. Basically it was base
module, licensing module, plus
It's not that simple, in fact it's not supported at all.. see
http://blogs.msdn.com/oldnewthing/archive/2003/09/03/54760.aspx for
some background. The Quick Launch shortcuts were never supported
either, however it developers quickly figured out that dropping a
shortcut in the folder did the trick.
Have you tried using a custom action, instead of a launch condition to
block install?
e.g.
Upgrade Id=$(var.Property_UpgradeCode)
UpgradeVersion OnlyDetect=yes
Minimum=$(var.version)
Property=NEWERVERSIONDETECTED
IncludeMinimum=no
,
but in the past when I used a custom action I had 1 action for setting
the property and a second action that actually used that property. Do
I need to do something like that? It just seems that the upgrade
stuff isn't getting executed currently.
On Thu, Dec 17, 2009 at 6:56 PM, Sascha Beaumont
The code will fail to compile with the following error:
Undefined preprocessor variable '$(var.IDoNotExist)'.
?define Iexist ?
?if $(var.Iexist) ??endif? !-- true --
?ifdef $(var.Iexist) ??endif? !-- true --
?ifndef $(var.Iexist) ??endif? !-- false --
?if
The expression can be easily unrolled, elseif becomes and else block,
containing an if/ifdef/ifndef... i.e. if your desired language doesn't
support elseif you use else, if
?ifdef FOO ?
?define value=1 ?
?else ?
?ifdef BAR ?
?define value=2 ?
?else ?
?define
, John Aldridge j...@jjdash.demon.co.uk wrote:
Genius! Thank you :)
Now, is this behaviour a bug in WiX which I ought to report? It seems
really odd that it doesn't know that CommonFilesFolder is
intrinsically 32 bit.
--
Cheers,
John
On 16/12/2009 00:59, Sascha Beaumont wrote:
I think
If anything, it's a limitation of Windows Installer - not WiX.
WiX just writes control/dialog entries in the MSI database, Windows
Installer implements the actual UI. See
http://msdn.microsoft.com/en-us/library/aa368342(VS.85).aspx for
documentation on the control itself.
Sascha
On Thu, Dec 17,
for you? Then you're not running programs with the wrong account.
Also, if it's an installer property then it also enables silent installs, GPO
installs. Have you looked at the PIDKEY property, for example?
Phil Wilson
-Original Message-
From: Sascha Beaumont [mailto:sascha.beaum
.
Thank you for the suggestion, though.
--
Cheers,
John
On 14/12/2009 22:51, Sascha Beaumont wrote:
I came across an almost identical problem last week :) I'm guessing
it's because your merge module is defined as a subcomponent of a
64-bit folder
Directory Id=TARGETDIR Name
put into
ProgramFiles64Folder.
Thank you for the suggestion, though.
--
Cheers,
John
On 14/12/2009 22:51, Sascha Beaumont wrote:
I came across an almost identical problem last week :) I'm guessing
it's because your merge module is defined as a subcomponent of a
64-bit folder
...@xpedienttechnologies.com wrote:
On a similar, but related note... Sascha, are you saying that you can have
multiple target directories for a merge module? I thought you could only
have the one merge reference path...
-Original Message-
From: Sascha Beaumont [mailto:sascha.beaum...@gmail.com]
Sent
I came across an almost identical problem last week :) I'm guessing
it's because your merge module is defined as a subcomponent of a
64-bit folder
Directory Id=TARGETDIR Name=SourceDir
Directory Id=ProgramFiles64Folder
Merge Id=wmm Language=0 DiskId=1
WiX doesn't support dynamically including files, however you can run
heat to generate a wxs each time prior to calling candle/light.
On Sat, Dec 12, 2009 at 6:32 AM, Sankaranarayanan loony...@yahoo.com wrote:
Hi,
Whats the best way to include all files from a source folder and deploy them
One thing to consider with this type of requirement, is how to define
the scope of installation
Many setup developers consider install as a much narrower scope than
those who are defining the requirements. Leveraging a configuration
utility on MSI setup completion (via a bootstrapper or the
One file? Then use a self-extracting bootstrapper :)
On Thu, Dec 10, 2009 at 6:19 AM, Kevin Garman gar...@scadaware.com wrote:
Well ya...I'm really trying to keep everything contained in a single
file (ie. the msi).
Thanks though.
On Wed, 2009-12-09 at 10:38 -0800, Blair wrote:
Unfortunately the documentation is a bit vague on this particular
subject. Basically you can use one or more -b parameter's with Light
(http://wix.sourceforge.net/manual-wix3/light.htm) to indicate what
directories should be searched when looking for files in 'SourceDir'
Sascha
On Mon, Dec 7,
1 - 100 of 167 matches
Mail list logo
