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 unfor
figuration file. The two Web.config files are both for IIS7. 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 toolse
Is it possible your XML file has an inaccurate header? I've seen people before
with an XML header like this:
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 remember
with what error code.
Anot
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 Sleighthol
rlson
-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 d
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 lis
Please file a bug for this, if you haven't already.
Thanks,
Mike Carlson
-Original Message-
From: Navid Azimi-Garakani [mailto:naz...@microsoft.com]
Sent: Monday, April 19, 2010 4:14 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] 64-bit WiX
Thanks
manual-wix3/wix_xsd_digitalsignature.htm
doesn't describe the element very much :(
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 do
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
Media/@EmbedCa
nd I made it to
be executed after ConfigureIIs (in Wix 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 Mess
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
s before about the same thing:
http://sourceforge.net/tracker/?func=detail&aid=2961215&group_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:m
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 St
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) [mailto:wpmccorm...@ace-c
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 non
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 into is that i
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 "[\]]"
T
al 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 a lot but I am still having trouble
s
om: Navid Azimi-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 followin
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 the
I can't help with the CVS issues, but to download the latest official build of
3.5, you want the "weekly releases" page, linked from wix.sf.net.
The direct link to weekly releases page is here:
http://wix.sourceforge.net/releases/
Thanks,
Mike Carlson
-Original Message-
From: Matt Hoov
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
-Origi
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:
Thanks,
Mike Carlson
-Original Message-
From: 万 毅 [mailto:overwhelmi
checks
for the cancel between each file.
- Original Message -
From: Mike Carlson (DEV DIV)
To: General discussion for Windows Installer XML toolset.
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'
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 / V
Many thanks for your help,
Matteo
-Original Message-----
From: "Mike Carlson (DEV DIV)"
Subject: Re: [WiX-users] Creation of an application pool on IIS7
installed on a server cluster
To: General discussion for Windows Installer XML toolset.
Are you sure
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 (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 underlying wix's design
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 [mailto:jk...@commondes
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]
Sent
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 th
-
Von: Blair [mailto:os...@live.com]
Gesendet: 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
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 toolset
am.com]
Sent: Monday, October 05, 2009 8:06 AM
To: wix-users@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
erver.
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 (DE
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]
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,
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 sear
ect: Re: [WiX-users] Failed while processing WebDirs
Sure, here you go:
-- 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-
apped
in a component.
Please, let me know if the snippet above doesn't contain what you were
asking for.
NOTE: it is reproduced when I'm creating a new site. If a user chooses
to use existent site, everything goes fine.
Thank you!
-- Yan
-Original Message-
From: Mike Carlson (D
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 locato
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 the
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
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 [mail
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: Su
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 too
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-
From:
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 th
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 in
I think a bug is already filed for this (#2803058):
http://sourceforge.net/tracker/?func=detail&aid=2803058&group_id=105970&atid=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
Were you by chance using Visual Studio 2010? Votive2010 was inadvertently
removed for a few builds, but the issue has since been fixed, and votive2010
should be back in the MSI with the latest 3.5 build (3.5.0704.0).
Thanks,
Mike Carlson
-Original Message-
From: Rob Mensching [mailto:r.
. Our web site is a root web site in IIS, on
which we want to create several virtual directories.
Ideally, we do not want to create a web site .. we only want to create
virtual directories. A web site locator record should be all that we need.
- Troy
On Wed, Jul 1, 2009 at 3:23 PM, Mike Carlso
ction ended 18:38:07: 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
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 hostet
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 th
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 fa
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:
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
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 [mailto:arosewa...@spectrumhr.com
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
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. T
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 "A
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
65 matches
Mail list logo
