1. The detection is for the x86 + x64 package. In plain english you can read
the condition as x86 NetFx key exists and either the machine is not 64-bit or
the x64 NetFx key exists.2. 4.0.3 is an update for .Net 4. It still requires
the original .Net 4 to be installed. Instead of creating
This is similar to a number of bugs I recently fixed in the IIS Extension. It
looks like I may have missed one. I will take a look. I have opened bug
3002703 to track the issue.
Thanks!Eric
From: chilavegp...@mail.ru
To: wix-users@lists.sourceforge.net
Date: Mon, 17 May 2010 14:22:23
This was actually a bug in the IIS custom actions. It should be fixed in the
latest build : 3.5.1714.00. Please give it a try.
-Eric
From: houssam.ham...@netiks.com
To: wix-users@lists.sourceforge.net
Date: Thu, 6 May 2010 12:03:46 +0300
Subject: Re: [WiX-users] IIS error during Repair
Can you confirm your scenario:
Website exists with virtual dirs.
Your installer locates the site and installs virtual dirs with different paths.
On uninstall, all virtual dirs, regardless of path, are removed.
Do you think you could attach your repro source to the bug?
Thanks,
Eric
Did you try http://wix.sourceforge.net/manual-wix3/wix_xsd_error.htmYou can
also try http://wix.sourceforge.net/manual-wix3/wix_xsd_uitext.htm
The error table should only be used to associate text with error strings,
UIText table is your general purpose bag-o-strings.
-Eric
From:
Have you considered using a WixLib to do this?
Date: Tue, 19 May 2009 20:17:30 -0700
From: jonathan.new...@ni.com
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Using INSTALLDIR in MSM That Eventually Reflects the
MSIs INSTALLDIR
Hi Bob,
The problem is that the exe
See http://msdn.microsoft.com/en-us/library/aa372835(VS.85).aspx you will see
that the message states Control [3] on dialog [2] needs a property linked to
it.
I suggest setting the contr...@property attribute:
http://wix.sourceforge.net/manual-wix3/wix_xsd_control.htm
-Eric
Date: Wed, 20
See http://wix.sourceforge.net/manual-wix3/votive_project_templates.htm
A wixlib is a wix library. Consider it wix's form of a staticly linked
library. If you don't need to share your MSM externally you could just compile
a wixlib of fragments instead, add a reference to the wixlib in all of
You mentioned before that you wanted variable for later usage, these are
called properties in MSI. See
http://msdn.microsoft.com/en-us/library/aa370889(VS.85).aspx. You'll want to
set that to a public property (all capital letters) so that it can be specified
on the commandline when the
Hi Murray,
The fix for this bug was to change the order that ReferencePaths is used when
locating an extension. You should see that RefrencePaths in the .USER file
will override the value of HintPath, but Votive will not actually change the
value of the hintpath in the .wixproj. Note that
Can you do partial validation in the UI sequence then delegate the rest to a
deferred CA? Deffered CAs will run as SYSTEM if Impersonate=no. MSDN has an
example that demonstrates how to pass credentials to a deferred CA. Please see
Hello Mukesh,
Have you tried setting SuppressModularization=yes on the binary element of your
merge module?
-Eric
From: magra...@microsoft.com
To: wix-users@lists.sourceforge.net
Date: Thu, 14 May 2009 15:54:20 +0800
Subject: [WiX-users] FW: Using a binary key from external merge module in
A quick search turned up this KB, not sure if it will
help.http://support.microsoft.com/kb/180548
-Eric
Date: Wed, 13 May 2009 16:16:26 -0500
From: bphilp...@sqlsentry.net
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] UAC prompt on feature modification after installation
When
One solution I have seen implemented is to write an immediate custom action
that runs before RemoveExistingProducts, queries the registry table for
registry path and name, reads the values for keys in the table, and overwrites
the value column of the registry table for the in memory database.
You need a component to have an individually serviceable element because the
decision MSI makes on whether or not to update/repair a file is based on a
component's keypath. If you have more than one file in a component and you
want to patch the file that is not the keypath you will be forced
Open up your WXL file and look for the line like this:WixLocalization
Culture=foo xmlns=http://schemas.microsoft.com/wix/2006/localization;
Codepage=1252
Replace foo with en-US.
Date: Wed, 13 May 2009 10:23:02 -0400
From: james.macdiar...@eds.com
To: wix-users@lists.sourceforge.net
Subject:
I assumed you were using a WXL file because you mentioned that my project
isn't loading my localization file.
A localization file (WXL) is required if you use loc variables in your setup
source: IE !(loc.xx).
A localization file is also required if you use an extension (like
Neil, we run into the same issue with our product, but normally restart manager
catches it:
MSI (s) (6C:2C) [17:29:11:221]: RESTART MANAGER: Detected that the service
FooService will be stopped due to a service control action authored in the
package before the files are updated. So, we will
That doesn't work because those are product code guids, not component guids.
Try a registry search under
HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall\{productcode}.
Also consider a search under HKCU if both your product and the dependency are
per-user products.
-Eric
To:
Have you set wixlocalizati...@culture to en-US for the localization files you
expect to be used when specifying Cultures=en-US?
-Eric
Date: Tue, 12 May 2009 18:44:46 -0400
From: james.macdiar...@eds.com
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Localization file
Try the following, it uses the shell exec custom action to open the browser:
CustomAction Id=LaunchUrl BinaryKey=WixCA DllEntry=WixShellExec
Execute=immediate Return=check Impersonate=yes /
Control Id=PrivacyButton Type=PushButton X=55 Y=199 Width=145
Height=28 Text=!Privacy Statement
21 matches
Mail list logo
