Regarding the uninstallation, all uninstallation by the WiX custom actions is
based on component refcounting. I.e. when the last component of guid
8AB78BF1-B785-4203-B23B-2CEB31757ADA is uninstalled from the system, all
things inside that component will be removed.
Although this has the
Is it possible your XML file has an inaccurate header? I've seen people before
with an XML header like this:
?xml version=1.0 encoding=UTF-8?
But their file isn't actually saved in UTF-8 format. This mismatch will cause
MSXML (which XmlFile uses) to fail on that file, everytime - I don't
. I'll check.
--
John M. Cooper
Volt at Microsoft
-Original Message-
From: Mike Carlson (DEV DIV) [mailto:mica...@microsoft.com]
Sent: Thursday, May 06, 2010 2:15 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] XMLFile not Finding file to Edit Even Though
The VerQueryValueW() call has been there since WiX 3.5 forked from WiX 3.0, so
I don't think this problem is necessarily Unicode-related. Perhaps you only
recently started using FileUtil's FileVersion() function (which requires
version.lib to be linked in)?
Try adding version.lib to the list
-Original Message-
From: Mike Carlson (DEV DIV)
Sent: Wednesday, April 28, 2010 2:46 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: RE: [WiX-users] WiX 3.5 dutil.lib build
The VerQueryValueW() call has been there since WiX 3.5 forked from WiX 3.0, so
I don't think
Yes, we still use nant/wix.build, and make.bat should work.
I don't have direct experience with the wix CVS repository, but I would think
it's best to begin building from cvs. If there is a problem, certainly it's
something we will want to fix.
-Original Message-
From: Neil Sleightholm
:(
Thank you for your help
Ondrej Zarevucky
On 13.4.2010 23:00, Mike Carlson (DEV DIV) wrote:
Christof is correct that WiX doesn't own the process of signing any
particular file - signtool.exe does that job. If you don't have any external
cabinets, just use signtool.exe to sign your MSI
Christof is correct that WiX doesn't own the process of signing any particular
file - signtool.exe does that job. If you don't have any external cabinets,
just use signtool.exe to sign your MSI, and you're done.
If you do have external cabinets (i.e. you have Media elements where
3.5 I changed to be after
ConfigureIIs7), but from log file I can see that website was not created
after ConfigureIIs7 action. Can you please specify name after which IIS
action I should execute mine custom action?
-Original Message-
From: Mike Carlson (DEV DIV) [mailto:mica
Also, what version of the tools are you running? Have you tried 3.0 RTM or a
recent 3.5 weekly release?
-Original Message-
From: s...@pacaccess.com [mailto:s...@pacaccess.com]
Sent: Wednesday, March 31, 2010 10:26 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re:
://sourceforge.net/tracker/?func=detailaid=2961215group_id=105970;
atid=642714
Is it the same as yours?
And Mike already fixed it in the latest Wix build which should be
available today.
-Original Message-
From: Mike Carlson (DEV DIV) [mailto:mica...@microsoft.com]
Sent: Thursday, March 25, 2010 8
I'd file a bug with the authoring you pasted below, and the answers to these
questions, if possible:
What's the exact error message you get (use a verbose logfile to find out)?
Does it work correctly if you install to an IIS6 machine?
Thanks,
Mike Carlson
-Original Message-
From: Ivo
It shouldn't be giving this message, but have you tried building the project? I
ask because it could be a secondary file (like the primary output) that heat is
trying to open (and is causing the exception to occur).
-Original Message-
From: Bill McCormick (LIST)
The recommended way now is typically to run heat.exe to harvest the com
registration information out of your DLL. This way it won't actually run the
code from the DLL at install-time (which is more likely to fail, won't handle
all of MSI's transactionality appropriately, and is generally a
The problem you're running into is that in the MSI world, [PropertyName] is
used to dynamically (at install-time) pull in the value of a property. So, you
need to escape your bracket so it isn't looked at in that way.
To escape [ replace it with [\[]
To escape ] replace it with [\]]
The full
I just realized this was already replied to. Apologies for the spam, everyone.
-Original Message-
From: Mike Carlson (DEV DIV)
Sent: Monday, March 22, 2010 11:26 AM
To: wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] (no subject)
The problem you're running
-Garakani
Sent: Monday, March 15, 2010 8:34 PM
To: General discussion for Windows Installer XML toolset.
Cc: Mike Carlson (DEV DIV)
Subject: RE: WIX 2.0 on IIS 7.5 with IIS 6.0 Compatiblity Mode
I should mention that that errors are primarily trivial with the exception of
the following:
1src\setup
.
Thanks,
Mike Carlson
-Original Message-
From: Navid Azimi-Garakani
Sent: Tuesday, March 16, 2010 1:36 PM
To: Mike Carlson (DEV DIV); General discussion for Windows Installer XML
toolset.
Subject: RE: WIX 2.0 on IIS 7.5 with IIS 6.0 Compatiblity Mode
Thanks again. Running WixCop will help
I don't know what would cause this issue in 2.0, but have you considered
upgrading to WiX 3.0 or even WiX 3.5?
A *huge* number of improvements have gone into WiX's IIS support in the WiX 3.0
RTM release. Going even further, WiX 3.5 actually has native support for IIS7,
so it doesn't require
You need to use a bootstrapper (an EXE designed for running one or more
installation packages) that will pass the appropriate language property to the
MSI at install-time.
WiX 3.5 will have a bootstrapper called Burn, but it's still under development
right now.
Thanks,
Mike Carlson
I believe you want to list these properties as the value of the built-in
SecureCustomProperties property, so they will be set in the server context as
well.
Try adding something like this to your authoring:
Property Id=SecureCustomProperties Value=WEBSITENAME;WEBSITEPORT/
Thanks,
Mike
Message -
From: Mike Carlson (DEV DIV) mica...@microsoft.com
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
Sent: Tue Feb 09 17:23:12 2010
Subject: Re: [WiX-users] Interrupting a WiX build
Do the cancel build (etc.) buttons work?
If you're sure the regular
Do the cancel build (etc.) buttons work?
If you're sure the regular cancel build options that work for C++ / C# builds
aren't working for wix (either the options aren't visible, or the options are
visible but don't function as you feel they should), go ahead and file a bug
against WiX 3.5 /
for your help,
Matteo
-Original Message-
From: Mike Carlson (DEV DIV) mica...@microsoft.com
Subject: Re: [WiX-users] Creation of an application pool on IIS7
installed on a server cluster
To: General discussion for Windows Installer XML toolset.
wix-users
Are you sure you're using WiX 3.0 / is it possible the version of
WiXIISExtension you're using is from WiX 3.5? I don't believe the
WriteIIS7ConfigChanges custom action existed until WiX 3.5.
Regardless, looks to me like a bug; I'd file one on sourceforge with as much
repro information as you
That mail thread is out of date - WiX 3.0 RTM (and 3.5) should have all fixes
that existed in WiX 2.0 (and in fact additional bugfixes as well).
The IIS7+ support works completely differently on WiX 3.5 and above - have you
tried building your product with the latest build of WiX 3.5, to see if
Have you considered using the iis:Certificate (and related) elements instead
of your own custom action? These will likely have fewer bugs (lower chance of
setup failure) than a custom-coded solution, as well as handle repair,
uninstall, patching, etc. correctly.
Part of the philosophy
Look closely; some of the link was cut off and placed in the next line, and
this portion was excluded from the hyperlink. If you include the ine.html
from the next line in the part that's hyperlinked, the link works for me.
-Original Message-
From: Jahanzeb Khan
It sounds to me like a bug. Please file one - don't forget to copy all the
helpful information (version information, sample authoring + log failure
messages) from your mail into the bug.
Thanks,
Mike Carlson
-Original Message-
From: Duncan Kelbie [mailto:duncan.kel...@neuralt.com]
Did you already try the -cc and -reusecab switches for light? Make sure to
specify both switches at the same time, and a valid folder after the -cc
option. This should allow light to just use an existing cab if none of the
files in that cab have changed. Then let it be a cab external to the MSI
: Montag, 2. November 2009 23:00
An: 'General discussion for Windows Installer XML toolset.'
Betreff: Re: [WiX-users] Link error for dutil.lib
Are you building 32-bit, or some flavor of 64-bit?
-Original Message-
From: Mike Carlson (DEV DIV) [mailto:mica...@microsoft.com]
Sent: Monday
Did you try a clean build? i.e. Delete your build output directory and build
again.
Thanks,
Mike Carlson
-Original Message-
From: Jiang, Chunyan (GE Healthcare) [mailto:chunyan.ji...@ge.com]
Sent: Monday, November 02, 2009 7:20 AM
To: General discussion for Windows Installer XML
@lists.sourceforge.net
Subject: Re: [WiX-users] WiX and certificates
3.0.5419.0
-Original Message-
From: Mike Carlson (DEV DIV) [mailto:mica...@microsoft.com]
Sent: Thursday, October 01, 2009 6:24 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] WiX
1) What version of WiX are you using?
2) What error message do you see in a verbose logfile in the event of failure?
3) Have you tried making the associated Component Permanent?
Thanks,
Mike Carlson
-Original Message-
From: phillip_sid...@dellteam.com [mailto:phillip_sid...@dellteam.com]
.
AddMachineCertificate: Error 0x80092004: Could not locate key pair from
PFX file.
AddMachineCertificate: Error 0x80092004: Failed to install certificate.
AddMachineCertificate: Error 0x80092004: Failed to install per-machine
certificate.
- Phil
-Original Message-
From: Mike Carlson (DEV DIV
First, I'm not intimately familiar with what you're doing, but have you tried
making use of the standard IIS custom actions to do what you want to do? See
wix.chm for the list of elements in the IIS extension - one of them may be able
to help you do this, and then you'll get install, uninstall,
-app/
iis:MimeMap Id=XAML6_new Extension=.xaml
Type=application/xaml+xml/
-- Yan
-Original Message-
From: Mike Carlson (DEV DIV) [mailto:mica...@microsoft.com]
Sent: Tuesday, September 01, 2009 7:04 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users
I believe it also controls the default bit-ness for the Win64 attribute on
certain things like RegistrySearches, Components, and binary Custom Actions (if
you specify a 64-bit architecture, these will default to 64-bit).
To see where it's used in the code, I'd open src\wix\compiler.cs and
Could you post appropriate excerpts from your authoring, if possible?
Is it possible you have at least one web locator record involved here (a web
element with no associated component)? This looks exactly like the issue where
a web element is trying to install to a location found by a web
If you're using the visual studio UI for WiX (called Votive), you'll want to
add a reference to WixIISExtension.dll, similar to the way you add references
to assemblies in your C# projects.
If you want general commandline help for the tools, either see the helpfile
(wix.chm), or try running
Look up WixNetFxExtension in the 3.5 CHM. You'll see all the properties listed.
In your case, you probably either want to reference the property
NETFRAMEWORK40FULL, or NETFRAMEWORK40CLIENT.
As for light.exe failing, that's a separate issue from the property reference,
and sounds like a bug -
It contains some of the WiX custom actions that, at install-time, do the work
for most of the elements of the WixUtilExtension.
Many of the other extensions have their own custom action DLLs.
-Original Message-
From: Sunkesula, Srivardhan [mailto:srivardhan.sunkes...@netapp.com]
Sent:
Did you specify the correct Certificate/@PFXPassword attribute?
Also, what build of WiX are you using? It's highly recommended to use WiX 3.0
RTM, as at least a few cert bugs existed in earlier 3.0 builds that were fixed
in RTM.
Thanks,
Mike Carlson
-Original Message-
From: Reese
Is verbose logging enabled (set voicewarmup regkey, preferably)? The log
messages here could probably be clearer that they aren't errors, but this isn't
actually failing the install, these are just info messages saying that the
WOW64 API isn't available on the machine.
What version of the
According to wix.chm, File isn't a valid parent element for
util:PerformanceCounter. It needs to be under a Util:PerformanceCategory
element, which in turn needs to be under a Component element, not a File.
See the CHM for more information.
Thanks,
Mike Carlson
-Original Message-
I would link the .wixobj into your final output, then use dark and see what you
get.
The formatting will be completely different, but depending on how extensive
your changes were, if you remember what you changed, you should be able to find
the things you added or modified, copy them back to
Keep in mind it's better to avoid XmlFile / XmlConfig and just rely on standard
IIS custom action functionality, if possible. I don't know enough about your
particular scenario to know if it's possible in this case, but if you can throw
a [ProgramFilesFolder] into your IIS authoring somewhere
I think a bug is already filed for this (#2803058):
http://sourceforge.net/tracker/?func=detailaid=2803058group_id=105970atid=642714
-Original Message-
From: Bob Arnson [mailto:b...@joyofsetup.com]
Sent: Thursday, July 09, 2009 6:26 PM
To: General discussion for Windows Installer XML
A *lot* has changed in the IIS custom actions since WiX v3.0.4805, including an
error that looks very similar to this. First, I would upgrade to the latest WiX
3.0 build (v3.0.5419) and see if you still have a problem after that.
Thanks,
Mike Carlson
-Original Message-
From: troy
: INSTALL. Return value 3.
Thanks,
- Troy
On Wed, Jul 1, 2009 at 12:51 PM, Mike Carlson (DEV DIV)
mica...@microsoft.com wrote:
A *lot* has changed in the IIS custom actions since WiX v3.0.4805,
including an error that looks very similar to this. First, I would upgrade
to the latest WiX 3.0 build
The x64 CA's also come with the x86 version of WiX. I believe the only
difference between the x86 and x64 releases of WiX is the MSBuild difference
mentioned below.
Also, to be clear, while some of the custom actions are also built as 64-bit
DLLs, others are not, and support 64-bit scenarios
Your website element is a website locator (i.e. it has no parent component).
That means the CA will look for this website on the local machine to install to
(and fail the install if it isn't present), rather than create it if it doesn't
exist. The logs in this case appear consistent with it
Bob raises a good point. Actually, this is an even better reason to split your
files up close-to-evenly into a few cabs.
-Original Message-
From: Bob Arnson [mailto:b...@joyofsetup.com]
Sent: Monday, May 11, 2009 6:57 PM
To: General discussion for Windows Installer XML toolset.
Subject:
Naturally it will take a long time to compress 5GB of data, so you will have to
expect that to take a while no matter what. If the files don't change often,
one way to cut down on the build time might be to use light's -cc switch, to
cache the CABs between builds.
Just in case, I have to ask -
An XmlFile entry will only get passed to ExecXmlFile if the component
associated with it is being installed or uninstalled.
Is the component associated with it being installed (or uninstalled)?
Thanks,
Mike Carlson
-Original Message-
From: Amy Rosewater
I don't believe there is an automated way to do this. I think clever use of the
DiskId attribute of the directory element is probably the easiest, assuming
the files are split up into a few directories. On the other hand, if all (or
most) of the files do go to the same directory, then I don't
1) Try the latest weekly build (currently 3.0.5207.0) of WiX to see if it fixes
your problem. A *lot* has been fixed in the IIS custom actions since the
particular build you're using.
2) If it still reproduces with the latest weekly build, enable verbose logging
by policy (search around for the
I just noticed you're modifying web.config directly using XmlFile. Just in
case, could you try to see if the problem reproduces without that, in case
there is some kind of conflict? Does the problem reproduce for you on pre-Vista
OS's as well?
Either way, it sounds like you should file a bug.
In your verbose log, what does Windows Installer think is the Action state
for this component on uninstall? You're looking for a line that says something
like this:
MSI (s) (4C:88) [14:30:42:128]: Component: Site; Installed: Local;
Request: Absent; Action: Absent
It should say
I've looked into this, and it seems this is an issue with the latest changes
I've made to the IIS custom action, to support Vista SP1.
I'm pretty sure I've tracked down the issue - please open a bug. Note that this
issue will occur in the latest version of WiX if you're using both IIS and Util
60 matches
Mail list logo
