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 wrote:
> In my application I use the built in functionality for storing user settings
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,
http://blogs.msdn.com/b/robmen/archive/2006/05/30/610950.aspx
On Tue, Sep 14, 2010 at 11:05 AM, Skip Sailors wrote:
> Help me understand, please.
>
>
>
> I have an EULA, written in RTF, saved using WordPad. At the top of the
> EULA is a logo that the business thinks is pretty important. When I
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.
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.
--
Think
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 info
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 close
Check the archives for more information, I asked a similar question
sometime last year. I can't find the exact thread, but ended up being
convinced to make the change. I did however find a list of pointers
from Rob around localization - changing the PackageCode was important
enough to be item 0 ;)
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 wrote:
> It is by design of Windows Installer.
>
> -Original Message-
> From: David Watson [mailto:dwat...@sdl.com]
> Sent: Wednesday, June 16, 2010 8:41 AM
>
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 MS
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
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
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, Blair
Try http://www.robmensching.com/ :)
On Thu, May 27, 2010 at 7:51 PM, Francesc Castells
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 a lot of money I onl
;t run the app without required MFC 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 l
Have you tried using merge modules rather than the redistributable?
On Tue, May 25, 2010 at 4:35 AM, Tony Juricic 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 the same vcredist_x8
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 forma
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 c
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 PM,
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 the
Try "[WindowsFolder]hh.exe,0" for the icon
On Mon, May 3, 2010 at 7:53 PM, subramanyeswari wrote:
>
> thanks.
>
> I have added non-advertised shortcut in my code. here is the code
>
> Name="Test Books Online"
>
> WorkingDirectory=
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 appe
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 basic
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?
On Fri, Apr 30, 2010 at 5:44 AM, Wix Mailing List wrote:
> Is there a list somewhere of things like THE_USER_ACCOUNT and the like?
>
>
>
>
>
> ---
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 wrote:
> This is going to start hitting big, as people encounter ICE validation
> failures on a team build.
>
> Apparently, what's go
The condition should include "Installed OR" so that the condition
always succeeds in a repair/remove situtation.
>From memory the easiest solution here is to fix the package you used
to install (e.g. using Orca), repair and recache with the "new"
package ("msiexec /fv") then you should b
Oohhh... nifty! Thanks for pointing that out Bob :)
On Sun, Apr 25, 2010 at 11:42 PM, Bob Arnson 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 lin
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
wrote:
>
> Hi
>
> I am building a WiX x64 install and I want to merge into the install an MSM
> (Microsoft Merge Modul
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
wrote:
>
> Hi
>
> I am using heat.exe of WiX 3.0.
>
> Can it
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, 2010
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 wrote:
>
> Still no luck Sascha.
> :(
>
> I replaced the earl
If Target="[CommonAppDataFolder]\MT\STR" fails, then try
Target=""[WindowsFolder]Explorer.exe"
"[CommonAppDataFolder]\MT\STR""
On Tue, Apr 20, 2010 at 4:27 PM, Sach wrote:
> [CommonAppDataFolder]\MT\STR
--
_
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 wrote:
>
> I changed the code as follows:
>
>
>
>
> Guid="{8436995c-2e76-4030-b92d-c6b4bc243c43}">
>
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
wrote:
> Hi,
>
> I've a text box in my custom dialog and I just need a small v
m trying to understand the conditional logic I posted.
> Right now, when I attempt to install the condition is evaluating to TRUE and
> causing the *first* install to fail. I am not understanding why it is
> evaluating this way.
>
> On Tue, Apr 20, 2010 at 2:02 AM, Sascha Beaumont
&
Your custom action is failing... try setting CustomAction/@Return="ignore"
On Tue, Apr 20, 2010 at 10:24 AM, Pierson Lee (PIE)
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. DLL:
> C:\Windows\Ins
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
inst
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
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 AM,
http://wix.sourceforge.net/manual-wix3/check_for_dotnet.htm
On Thu, Apr 15, 2010 at 9:37 AM, Vishwajit Walke
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: 'General discussion for Windows
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 wrote:
> I got into this problem once when I did
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
wrote:
> Hi,
>
> try using the "windows installer clean up
and a
> specific CA as the windows logged in user (the initial user before
> elevation)?
> Otherwise, I don't see how I can solve this...
>
> Thanks again for your help,
>
> Francesc
>
>
> On Wed, Apr 14, 2010 at 1:39 AM, Sascha Beaumont
> wrote:
>
>> Mos
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
wrote:
> Hi,
> I have an installer that upgrades an old program and imports the data. To do
> that, it opens the old program's co
creased
> for internal builds, only for releases to the customers.
> What is the benefit of having also the 4th field in the version (in your
> case)?
>
> Thx,
> Viv
>
>
> On 4/12/2010 3:57 AM, Sascha Beaumont wrote:
>> You can't do this while also using Pr
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 -
http://msdn.microsoft.com/en-us/library/aa368976(VS.85).a
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
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 wrote:
>
> Hi Pally,
>
> Thank you
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
I'm using nant with the candle/light tasks
On Wed, Apr 7, 2010 at 11:49 AM, ppremk 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!
> --
> View this messag
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 wrote:
>
> Hello Guru's
>
> I have begun my journey with wix and have found i
ean how can I remove a file only when an real
> uninstall is done and not a major upgrade which also includes an
> uninstall before the new install?
>
> Thx,
> Viv
>
>
> On 3/29/2010 6:51 AM, Sascha Beaumont wrote:
>> Letting the user modify "installed" fil
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 time
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 th
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 eve
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
wrote:
>
> I read this in the WIX tutorial:
>
>
> This will store the s
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 wrote:
> I'd do something similar to the checkbox on the LicenseAgreementD
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 :)
.
.
.
On Mon, Mar 8, 2010 at 10:25 PM, Andy.Kruger wrote:
>
>
> I want to launch an exe from the exit
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
wrote:
> Sure, I'll contact you of
Sure, I'll contact you off-list :)
On Mon, Mar 8, 2010 at 4:25 AM, Christopher Painter
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 this area who have experience w
What do you mean by "this way?" ;)
Here's a working fragment copied straight from our current release...
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 = "ap
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 follo
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.
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 you
ject: Re: [WiX-users] A real challenge: how to launch the app in elevated
> mode after finishing its setup ?
>
>
>
>
>
> Thank you very much. Applying the 'WixShellExec' which is described in the
> below link has worked perfectly.
>
> http://wix.sour
e I know would argue against the policy modules given that
> information.
>
> -Original Message-
> From: Sascha Beaumont [mailto:sascha.beaum...@gmail.com]
> Sent: Monday, February 15, 2010 2:42 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: [Wi
here 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 discus
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:
Removed references to policy MSMs because
the general recommendation is to not include policy MSMs when
redistributing
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 m
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, Fe
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 t
I use the following code to launch a program on finish, users are
always prompted to elevate, application manifest includes
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
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 w
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 compilati
>> 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 dep
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 yo
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 wrote:
> Hello all. :)
>
> I'm new to th
r issues that break when repair is run,
>> you should seek to fix those instead of disabling repair. Those issues
>> aren't just "repair" issues, they are also upgrade issues (and possibly even
>> remove issues) that should never be shipped until you fix them.
&
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
No, you would need to create your own external UI and bootstrapper.
On Wed, Dec 30, 2009 at 4:17 PM, Sanjay Rao
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 change the msi icon shown i
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 sec
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"
On Fri, Dec 18, 2009 at 5:27 PM, Rob Mensching wrote:
> Doesn't look
The code will fail to compile with the following error:
Undefined preprocessor variable '$(var.IDoNotExist)'.
Sascha
On Fri, Dec 18, 2009 at 3:22 PM, Steve Lessard wrote:
> Is it me or is the preprocessor example at
> http://wix.sourceforge.net/manual-wix3/
X and MSIs in general,
> 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"
Have you tried using a custom action, instead of a launch condition to
block install?
e.g.
On Fri, Dec 18, 2009 at 9:44 AM, Jason T. wrote:
> Hello,
>
> I'm trying to detect when a different version of my package has
> al
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.
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 vari
e common area in the first place? It's not as if you can't
> sub-directory the keys for each user in that location if necessary.
>
> 2. This sounds like standard data collection, so why not just have the user
> enter the key in a user sequence dialog, and have MSI put it som
Check out http://blogs.msdn.com/rflaming/archive/2006/09/21/765665.aspx
You can probably use MSIREALADMINDETECTION to make the AdminUser
property behave as you require.
Sascha
On Thu, Dec 17, 2009 at 6:08 AM, little.forest wrote:
> Our installer needs Admin right to run. So a "Standard user"
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,
at 1:52 AM, John Aldridge 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/1
lar, 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: Tu
:\ (the
> drive with the most free space), rather than being 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
ramFiles64Folder.
>
> 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&#x
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
>
>
> SourceFile="$(var.WixMergeModule1.TargetPath)" />
>
>
Try this instead:
1 - 100 of 176 matches
Mail list logo
