So I tried to move from Tallow to Heat because, well, when I use Tallow, I have
to manually edit Tallow's output to delete short filenames so it works with
WiX3...
Particularly challenging part of my projects is to generate WiX files for sample
input/output. This sample input/output is on the ord
I realize the hip new thing to do is install into C:\Program Files\Whatever.
But I have a legacy app that absolutely must be installed into C:\Whatever. I
tried this:
But then it wants to install my application into R:\Whatever. Any idea how to
make it install into C:\Whatever? Th
> meaning for 'where the software installs to', i.e. TARGETDIR.
>
> --
> Mike Dimmick
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Nick
> Sent: 26 April 2007 21:29
> To: wix-users@lists.sourceforge.net
> Subje
I am trying to make a setup that does NOT install on Windows 2000. Here's what
I have so far:
TARGETDIR=""
TARGETDIR=""
When I run the MSI on a Win2K machine, here's the beginning of t
That would work great...but my app needs WinXP-SP2 or better, or Win2003-SP1 or
better, or Vista, and that's where it gets messy. (It depends on Windows
Firewall, which is only present in those operating systems).
On 5/10/07, Trevor Clifton <[EMAIL PROTECTED]> wrote:
> I do just the opposite an
So be it. I'm dropping custom actions, since they don't evaluate to a 1 or a 0
anyway, but rather evaluate to something like 500=500. I'll use
(VersionNT = 501 AND ServicePackLevel >= 2) OR (VersionNT = 502 AND
ServicePackLevel >= 1) OR (VersionNT > 502)
Thanks!
On 5/10/07, Trevor Clifton <[E
wouldn't evaluate any further conditions).
What I was trying to do is define custom variables instead of making one long
string. Oh well, I can live with one long string :)
Nick
On 5/10/07, Lewis Henderson <[EMAIL PROTECTED]> wrote:
> Hi Nick,
>
> I'm new to the listserv
I had dealt with this issue before, you may find the discussion if you search
the archives.
Note, if you disable a feature from the installation tree, a savvy user can
still use something like Orcas and extract *all* the files that are sitting in
your .msi file...
What I ultimately did was this;
I create a dummy installation project with Visual Studio 2005, and I make it
install .NET runtime and VC++2005 as pre-requisites. Then I delete the .msi
file that VS generates, and I put in the one WiX generates. Congratulations,
you have a setup.exe that installs all the pre-requisites.
On 5/
If you wrote it in VC++ 2005 then one of your dependencies will be the Visual
C++ 2005 redistributable. One of your dependencies will also probably be .NET
framework 2.0. You put these in your bootstrapper, since neither are included
by default with your XP or 2K system. (Unless some other app a
DLL. See here:
http://www.tramontana.co.hu/wix/lesson3.php#3.3
On 5/10/07, Jason Van Eaton <[EMAIL PROTECTED]> wrote:
> Thanks, Rob. By CustomAction, do you mean an action that cobbles together
existing stuff from inside WIX or Windows Installer, or do you mean calling off
to a custom .dll t
I sent an email to a third-party component vendor, asking them to give me a
merge module for their product (OCX goodies), citing this as my concern:
http://blogs.msdn.com/robmen/archive/2003/10/18/56497.aspx
Their answer:
"Also since the Modules are serialized and stamped at install time, we are
it back to the purchaser).
Great.
-Original Message-
From: Bob Arnson [mailto:[EMAIL PROTECTED]
Sent: Friday, June 01, 2007 01:31 AM
To: Mike Dimmick
Cc: 'Nick'; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Merge Modules Serialized and Stamped at Install Time
Mike Dim
I know I'm probably too late with this info...but if you have VS 2005 SP1, your
C++ dependency that you created with VS bootstrapper is not being installed
correctly. Update your
C:\Program Files\Microsoft Visual Studio
8\SDK\v2.0\Bootstrapper\Packages\vcredist_x86\product.xml
file to change thi
I should probably be hung for doing this...
I run the VS2005 bootstrapper to install C++ and .NET runtimes. Then the
bootstrapper starts an ORCA'd MSI. This MSI asks the user to enter the correct
password. If the user does so, the custom action de-crypts (that's why I need
the C++ and .NET runt
Can you recommend another bootstrapper that can kick off an .exe (instead of the
.msi)? Something tells me I might be writing my own bootstrapper tomorrow.
-Original Message-
From: Bob Arnson [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 17, 2007 00:09 AM
To: Nick
Cc: wix-users
07:30 AM
To: [EMAIL PROTECTED]
Cc: wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] (no subject)
Nick,
I've had good success using NSIS (http://nsis.sourceforge.net) to create
my bootstrapper. It can easily launch any application you may need. I've
also heard good things about
I'm getting an error that looks like this (new for WiX3, latest weekly build)
C:\MFragment.xml(8) : warning LGHT1076 : ICE60: The file MCmdFile1000 is not a
Font, and its version is not a companion file reference. It should have a
language specified in the Language column.
Ewhat???
The l
When creating patches...
Does the wixpdb method compare the binaries from the two .msi files? Or, does
it compare the files as they are on the disk? (My preference is for using .msi
files due to project archiving and other such things).
If it compares the files as they are on the disk, is it wi
The following chunk of code
NOT MAYINSTALLSOURCE
Works great to disable installation of the "Input" if the user enters a bad CD
Key. (As intended. No need to get into details here.).
The problem though is if the user enters a bad CD Key, selects a "Custom"
instal
Nah, I got plenty others...
+ Complete
Bin
Input
Output
Source
On 1/4/07, Levi Wilson <[EMAIL PROTECTED]> wrote:
Is that your only item?
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceFo
Nah, I got plenty others...
+ Complete
Bin
Input
Output
Source
On 1/4/07, Levi Wilson <[EMAIL PROTECTED]> wrote:
Is that your only item?
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForg
My sanity has been questioned, and I realize no sane person would probably want
to do this, but...
Here's what I'm trying to accomplish; is there a more elegant way to do this?
I'm trying to make some code that installs only on Windows:
XP SP2 or better,
2003 SP1 or better,
or Vista or better.
I'm using the code below, and my application happily installs itself on Win2000.
What am I doing wrong?
-
I'm using the 3502 build (shame on me, should have tried 3509) to make an
installer for my app. It was a success with WiX2, but I decided to move to
WiX3 for the new featureset.
A chunk of my installation looks like this:
Why would you want to wrap an .msp into an .exe? Once your bootstrapper
installed the pre-requisites with the original .msi, you don't need to do any
more pre-requisites. (Or, are you adding a new pre-reqisite with your .msp?)
I use BMG (http://www.codeplex.com/bmg) and it has no problems launch
This code:
...
...
Works perfectly well in WiX2, but not in WiX3:
C:\blah.xml(65) : error LGHT0094 : Unresolved reference to symbol
'File:Notepad.exe' in section 'Fragment:'.
I have also tried [WindowsFolder]\Notepad.exe.
How would I fix this?
-
How is the MajorUpgrade element scheduled in your MSI? By default it is
"afterInstallValidate", which does not bring back the old version if there
is a rollback. See the documentation at
http://wix.sourceforge.net/manual-wix3/wix_xsd_majorupgrade.htm.
--
View this message in context:
http://w
I'm still not grasping what's happening. Do I have this right?
* You have a dependency on .NET 4
* You used the WiX .NET extension in your Burn bootstrapper to install .NET
if it isn't already installed
* For the portion of the install (after .NET is installed) that applies to
your own software, y
Burn caches MSIs that are in the bundle in the Package Cache, so having the
original media, I wouldn't /think/ would be a problem. When one MSI in the
bootstrapper chain fails, all preceding MSIs should be rolled back.
--
View this message in context:
http://windows-installer-xml-wix-toolset.68
That makes sense then. I wonder if adding the *-cultures:en-us* flag or
*-cultures:fr-fr* to the Linker tool settings in the bootstrapper's
properties would do the trick?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-Localization-Identifiers
The MajorUpgrade schedule is important for the MSI that failed. If an MSI
will be rolled back, having the original MSI reinstalled is dependent on the
MajorUpgrade element. On the other hand, the first MSI, which installed
fully, will not roll back. At best, when the Chain fails, it will probably
j
In the bootstrapper project's Visual Studio properties, go to Tool Settings
and enter the command-line args into the Linker text box.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-Localization-Identifiers-Duplicated-tp7586776p7586899.html
Se
I think you're right. This other thread seems to agree:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Installl-upgrade-several-MSIs-in-one-single-transaction-td7495903.html
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Bootstrapp
Are you installing some sort of suite of different products? Maybe the
Visible flag on the MsiPackage element will get you closer to what you want.
Or there might be a way to build a custom BA that would present a screen to
remove particular products.
--
View this message in context:
http://wi
Microsoft Office 2007 has a single entry in ARP that can be used to
modify/remove the installed products. I wonder if they are using Burn to do
that.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Creating-separate-entries-in-Add-Remove-for-each-M
Hi All,
I am passing some properties to a custom action, and one of the values being
passed is quite large, and never seems to make it to the CA. I am wondering
what is the maximum size of a string that can be passed via CustomActionData?
Thanks,
Nick
Nicholas Miller (Network Administrator
size of a string that can be passed via CustomActionData?
>
> Thanks,
> Nick
> Nicholas Miller (Network Administrator) LiveTechnology Holdings, Inc.
> LiveTechnology Park: 16 Sterling Lake Rd, Tuxedo Park, NY 10987
> Phone: 845.351.5100 Direct: 845.535.6205 Fax: 845.351.5102
> Email:
You should be able to download the example for that chapter at the Packt
publishers (packtpub.com) site. On the page that shows the details about the
book, click the tab that says "Support" and there ought to be a "Code
Downloads" link.
--
View this message in context:
http://windows-installer-
I added an MSI project to check it, and it compiles ok for me. I link the
projects together as:
* The wixlib project needs to pull in the custom actions from the CA
project. Two ways to do that are
1. Use a build events in Visual Studio to copy the CA.dll file to the
wixlib project's directory
Okay, I maybe wasn't fully understanding the problem. :) So, you're saying
that you want to use your extension in another WIXLIB (unrelated to the
WIXLIB you used to build your extension)...but when you try that, but don't
reference the extension in your Setup project too, you get the error "Cannot
(s, e) =>
{
If(initialInstall)
{
System.Diagnostics.Process.Start(InstallDir +
@"\path\to\exe.exe");
}
Dispatcher.CurrentDispatcher.InvokeShutdown();
};
Hope this helps,
Nick
-Original Message-
F
I don't think you want that check. You want Burn to register the package for
each bootstrapper that installs it. In other words, you want to install it
everytime, even if it's already installed. Burn should detect that the
package is already installed and just skip over it. That way, when one
bundl
The Property attribute should be the same on both elements. It ties them
together in that way.
According to the MSI documention for the ComboList property:
"If the ComboList Control bit is set on a combo box, the edit field is
replaced by a static text field. This prevents a user from entering a
Are you just starting your journey with WiX? If you are, you might take a
step back from WPF user interfaces for a few days and dig into writing an
MSI file. Once you've got that, I'd read up on how to use Burn by itself,
using the UI that comes with the toolset. Here, I'm talking about just
writin
Things to try:
1. Did you replace/remove the old Publish elements that were directing the
user elsewhere? Looks like in the WixUI_Advanced.wxs, there are there
Publish elements, each taking the user somewhere else depending on a
condition.
2. Does your Publish element have an Order property? If n
Some things to try:
* Is the MSI failing? There ought to be separate MSI log files in the same
directory, so check those for any errors.
* Check the bootstrapper's log file to see how far it gets, may give you a
clue about where it's failing
* If you want to step into your managed BA, put a threa
You might have to save the users's choice (Machine or User) somewhere and
feed it back in as a command line arg upon uninstall.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Dual-purpose-package-won-t-uninstall-when-uninstalling-bundle-tp7590376p
It's hard to say what's causing the problem. Can you post the code from your
bundle.wxs file? Maybe the problem is there.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Dual-purpose-package-won-t-uninstall-when-uninstalling-bundle-tp7590376p759039
I think the problem is what Jacob said (and what the post said) -- an issue
with choosing perMachine/perUser at runtime. It's what I meant to say, but
had the other things in my head and said that instead accidentally. :)
--
View this message in context:
http://windows-installer-xml-wix-toolset
According to this post:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Bundle-amp-per-user-or-per-machine-td7579453.html#a7579508
It sounds like Burn may not support a mixed 64/32-bit setup.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.na
You can dynamically set an install directory with the SetDirectory element.
The WebVirtualDir element, in the IIS extension, uses the Directory property
to point to a Directory element. So if you set up your Directory element,
point to it with WebVirtualDir, and use SetDirectory to change its targe
I think the easiest way to use Prism is to pull in the dependency using
NuGet. The command is:
Install-Package Prism
You can download NuGet for Visual Studio 2010. It's an extension to Visual
Studio.
http://visualstudiogallery.msdn.microsoft.com/27077b70-9dad-4c64-adcf-c7cf6bc9970c
I think that
You can create a custom bootstrapper application (such as by using WPF) and
have that do just about anything you need. Burn has extension points for
this. Curious, how come the logic needs to live on a website? Did you not
want to base the language off of the user's language settings on their PC?
I have developed Wix installers in the past using the minor upgrade
route but have recently changed to major upgrades to allow for easy
double click upgrades. A couple reasons we wanted to do this was:
1) Preserve existing configuration files
2) Preserve login and recovery options for our Wind
es" />
The only problem is that in IIS7, the IP address is set to nothing. If I use
an actual IP address, such as 127.0.0.1, it shows up. The asterisk, or
leaving IP off, causes the website to get no IP assigned. Has anyone
experienced this?
Thanks,
Nick
--
View this message in context:
ht
I am attempting to use Major Upgrade with my Wix installer to IIS 6 on
a Windows XP machine. In the past when using this same installer with
a Minor Upgrade it would work fine and only show up once in the
Add/Remove Programs dialog even after several upgrades. Now that I
have changed the installer
chedule' attribute is needed on the 'MajorUpgrade' element in
> order for it to remove the existing version.
>
> On Tue, Apr 19, 2011 at 7:59 AM, Nick Porter
> wrote:
>
>> I am attempting to use Major Upgrade with my Wix installer to IIS 6 on
>> a Windows XP
Thanks Wyrdfish,
It looks like it is working now -- even though, the asterisk doesn't show up
where the IP would be in the IIS manager. I had been waiting for our systems
guys to create a DNS entry for the website and once I had it, it seems to
work. Must be a false alarm. It is interesting though
Please make it stop!
-Original Message-
From: abdoulaye.souleyma...@rohde-schwarz.com
[mailto:abdoulaye.souleyma...@rohde-schwarz.com]
Sent: 01 July 2011 14:38
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Abdoulaye Souleymanou/RSD ist außer Haus.
Ihre Nachricht betreffend:
In our development environment, we are installing to an existing website
hosted in IIS 7 (Server 2008). However, in our QA environment, we are
installing to an existing site hosted in IIS 6 (Server 2003). I've found
that in IIS 6, the existing website can't be found unless we add the
SiteId="*" att
We've had quite a bit of hands on experience with this sort of thing lately.
In one project, we bound a certificate to a port during the install so that
we could use SSL (the same as if you were to go into IIS and set the binding
and choose a certificate). In another case, we used ws-security in th
I'm not sure if you ever got this figured out. If not, can you show us the
markup for the custom action?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Executing-a-Batch-File-during-Install-tp6579146p6646053.html
Sent from the wix-users mailing list
Could you show the markup you're using for the controls?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Multiple-RadioButtonGroup-controls-in-the-same-dialog-tp6644681p6646096.html
Sent from the wix-users mailing list archive at Nabble.com.
---
For sure, I wouldn't mind getting involved in making some sort of extension.
That project doesn't seem to have much activity though.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Installing-https-WCF-Webservices-tp6641855p6648697.html
Sent from th
I am using Wix 3.6 (and have tried this in Wix 3.5) to install a Web
application to IIS 7 and the install works correctly but when
uninstalling the application either with Add/Remove Programs or with
MSIExec I get the following error in IIS.
There was an error while performing this operation. Deta
I am attempting to write new values to the Registry with a Wix
installer on a Windows 7 box. On the first installation the settings
are written properly, I then uninstall the application and find that
the Registry settings are still there (which is what I want).
When I try to install again, or use
eone might have some insights into this.
Thanks in advance,
Nick Hall
-Original Message-
From: Nick Hall
Sent: 26 June 2009 18:44
To: 'wix-users@lists.sourceforge.net'
Subject: Uninstall and the Restart Manager
Our application installs a Microsoft Exchange agent (Exchange 2007,
ing this screen. Installation cannot proceed from here!
Any suggestions why this is happening?
-Nick
=== Logging started: 14/12/2009 11:31:41 ===
Action 11:31:41: INSTALL.
Action start 11:31:41: INSTALL.
Action 11:31:41:
SystemFolder.21022.08.Microsoft_VC90_MFC_x86.RTM.17F6CCF1_663E_333F_994
olSet\services\testsvc
SUCCESS
--
Nick Ramirez
--
View this message in context:
http://n2.nabble.com/MSI-5-0-ServiceConfigFailureActions-fails-during-InstallExecuteSequence-t
seems to be an issue isolated to MSI 5.0's
ServiceConfigFailureActions element, but only when using either the
"restart" or "reboot" actions. And even with all of the permissions I can
think to give, those actions don't complete successfully.
Nick
Wilson, Phil wrote:
>
Hello all. I've just joined the list in hopes of solving a specific
problem.
A few months ago I used WiX to create a fairly simple .msi. Here is the
relevant portion of the .wxs file, with identifying information redacted
(GUID1 and GUID2 represent real uppercase GUIDs):
---START OF CODE---
Is this a per-user or per-machine install? The reason I ask is that
sometimes, by not setting the ALLUSERS property to something before you call
FindRelatedProducts, you run into trouble.
Nick Number wrote:
>
> Hello all. I've just joined the list in hopes of solving a specifi
couldn't get an installer together in a couple of weeks,
so I stopped trying.
If you get any further, how about trying to feed it back into WiX? I
know there are a few of us now with this in mind.
Regards
Nick
-Original Message-
From: wix-users-requ...@lists.sourceforge.net
[mailto:wix-
Take a look at the description for ICE30:
http://msdn.microsoft.com/en-us/library/aa368954(VS.85).aspx
What I gather from it (and a preliminary test confirms it) is that if you
have two files being installed to the same directory, then the only way to
avoid an error is to add elements to both c
Have you tried using the fully qualified name for the NetworkService user?
Such as "NT AUTHORITY\NetworkService"?
--
View this message in context:
http://n2.nabble.com/install-service-tp4716985p4718779.html
Sent from the wix-users mailing list archive at Nabble.com.
Are your properties public, meaning are their Ids uppercase? If they're not,
they won't pass from the UI to the Execute phase.
example:
And do you see the property being set in the install log? Like...
MSI (c) (98:F0) [12:04:32:046]: PROPERTY CHANGE: Adding CHECKBOX_PROPERTY
property. Its va
Add the ComboList="yes" attribute to the control. Also, you may want to add
Sorted="yes". Hope that helps.
--
View this message in context:
http://n2.nabble.com/Combobox-Display-Question-Problem-tp4677659p4719093.html
Sent from the wix-users mailing list archive at Nabble.com.
---
I've experimented with this and have found that the symbols really seem to
mean this:
# - Can be any number
& - Can be any letter
? - Can be a number or letter
^ - Can be any letter, but it will always be converted to uppercase
@ - Creates a random number.
< - Beginning of visible part of mask
>
When, during the uninstall process, are you getting the error? Is it
happening during the RemoveFiles action? If so, you might try adding the
Wait="yes" attribute to your ServiceControl so that it waits for it to stop
the service before moving on to remove files. It may be that the SCM is
taking t
In Visual Studio, you can set a Build Order for your projects (assuming that
they're all in the same solution). That way, your custom actions will be
built before your WiX files, assuring you that they're always up to date.
You can't, as far as I know, directly reference a custom action project in
I've seen the same thing. Although in my case I'm just trying to speed up
localization, not make a patch. It seems to be caused by the -bf flag.
Without it (in which case you'll need to make sure that your WixVariables or
-d flags are referencing the bitmaps and icons correctly in relation to the
Hello, I'm trying to figure out what the EndDialog event does when given a
Value of "Retry". According to the Windows Installer documentation, it does:
"The wizard sequence is closed and the control returns to the installer with
the Suspend value."
I have the following control:
1
Clicki
Okay. Maybe the code 1604 isn't so weird. I found another site that said it
means:
"1604 - Installation suspended, incomplete. - ERROR_INSTALL_SUSPEND"
So, then it worked, right? So, then how to I resume it from its suspended
state? If that's what has happened?
--
View this message in context:
.msi), will that tell light not to un-pack and re-pack all the
files?
Or, alternately, will I see more performance improvement if I assign a RAMdisk
or similar?
Nick
_
Hotmail: Trusted email
Can anyone tell me more about the actions that Light does? For example, does
linking happen before binding? When is the .wixout or .wixpdb file created?
When are unreal tables used and is it okay to drop them with the -dut flag?
We'd like to optimize our calls to Light and any info about the order
We're trying to make it faster. We're currently using a wixout file to get us
halfway through the process. Yet, it still takes a while since we are
localizing for eight languages. Our latest idea is to stop reusing the
wixout in such a synchronous way. By that I mean that we use a batch file
that
Hello,
The Property element's Secure attribute is supposed to be necessary to pass
a property from the UI to the Execute sequence. However, I've never been
able to create a situation where it was necessary. For me, just making the
property uppercase has always done the trick.
I've tried the foll
I needed this specifically to get a
> property from a registry key to pass to a custom action during uninstall.
>
>
> Matt Johnson MCPD, MCTS, MCSD, MCDBA
> Director of Application Development
> Time America, Inc.
> ma...@timeamerica.com | www.timeamerica.com
>
>
>
Okay. It took quite a while to get some results, but I've finally managed to
get the properties to not pass from the UI sequence to the Execute sequence.
The key factor seems to be whether or not you're prompted to elevate your
privileges during the install.
On Vista, you're almost always prompte
How are you scheduling your custom actions in the InstallExecuteSequence
table? With the InstallExecuteSequence element?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Custom-Actions-Missing-in-InstallExecuteSequence-tp5039683p5043350.html
Sent fro
You don't need to have an immediate custom action. Here are some pointers.
1. The progress bar appears and is incremented during the deferred stage, so
any custom actions that run during this phase can update the bar. It's nice
to see some text that says what's happning when you control the progr
Is SERVICEACCOUNT a local user, not a domain user? If so, it might help to
prefix it with ".\" to denote that it's a user on the local computer. Also,
local users often don't have the rights to handle services unless the
Interactive attribute on ServiceInstall is set to "no" and Type is
"ownProces
You could get the WixUI_Minimal.wxs file from the WiX source code, save it to
your project under a different name, like "CustomWixUI_Minimal.wxs". Open it
up and change the UI element's Id to "CustomWixUI_Minimal".
Add a UIRef element to your main .wxs file with an Id that matches.
Is it possible that the child process (the batch file) is picking up the same
environment as the MSI (parent process?) and in order for it to pick up the
new environment variable it would have to somehow refresh its environment?
I'm not sure how to do that.
--
View this message in context:
http
Does this thread help?
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Windows-Service-not-removed-on-Uninstall-td710002.html
What is the "Action" of the component with your service, from the uninstall
log?
--
View this message in context:
http://windows-installer-xml-wix-toolset
The action state of a featre is supposedly set after CostFinalize. Trying it
out, it seems that checking the action state in the condition of a
component, as you've done here, evaluates to -1, "unknown".
I would have thought that it would always evaluate to 3, "local", since the
INSTALLLEVEL pro
Okay. I think I understand this a bit more now. I think that the action state
of components and features are figured out during the FileCost phase, but
not set in stone and made available until after CostFinalize. Also, I
believe that conditions on components and features are evaluated at the same
If I understand your question, you want to increment the progress bar for
more than one custom action? You'd just need to reuse the code in those
custom actions too, either by duplicating it or putting it in some central
assembly. If you didn't want to reset the progress bar each time, you could
s
You can remove the Sleep from the example. I used it to show the progress bar
with several pauses. In a real application, your function would call the
"DisplayActionData" function at times when you decide to show a message and
increment the bar. Now that I think about it, my DisplayActionData func
1 - 100 of 479 matches
Mail list logo
