Does the install log show that it is detecting the old version?
At one point I thought that I had to schedule InstallExecute after
RemoveExistingProducts, but last I tried it that didn't seem to be the case.
Is it possible to switch to use the new MajorUpgrade element? It seems to
make life
I used to have problems with projects not loading. It seems like it had
something to do with having to copy some Version file or something into
another directory.
I tried the whole thing again and it works for me:
1. Cloned the repository (don't check certificate):
hg clone --verbose
That's the error message you get for pretty much any reason. It's like a
catch-all error message. Try changing the service's account in the services
console and see if it starts. Maybe try to debug into it while it's
starting. I've done that before after putting it to sleep for a few seconds
to
I wasn't able to find much information about this. Does Burn handle package
ref counting automatically? Is there nothing we need to do? Or should we be
using the DependencyExtension in some way? Do install devs need to handle
adding to the package ref count and subtracting?
Thanks.
--
View
Would you say that the Requires element is not needed? I thought that
Requires might be placed inside of an MsiPackage or ExePackage, for
instance, to reference the Provides. But apparently the schema doesn't
support that. It can only be placed under a Bundle, Fragment or Provides. Is
it not
This is probably a naive question, but why is it required to read the file at
install time? Could you get the information you need during development and
hardcode it into a component?
--
View this message in context:
I believe that adding an XmlFile element inside of a Component will add an
action to the install sequence that will do the XML writing. That would
happen during the installation, not at the end. Is it a hard requirement
that this only be performed at the end? All actions that change the state of
If I understand, the new MSI will have a single file that can be used on any
OS? And the other OS-specific files will be removed/replaced?
A major upgrade should work well. It will uninstall the old files and then
install the new files. (Not necessarily in that order). So you'll
essentially be
Have you tried making the name of the property all uppercase? SERVICE_URL?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/util-XmlFile-using-old-property-value-tp7581739p7581838.html
Sent from the wix-users mailing list archive at Nabble.com.
Are you using the MajorUpgrade element? And what do you have for the
Product's Id? An asterisk? If it's the same Product ID, version and
UpgradeCode, I am surprised you are not seeing the Repair/Modify dialog when
the second MSI is run.
--
View this message in context:
I'm curious about your setup. What is it about it that make having two MSIs
worthwhile? Did you not want to have two Features in a single MSI?
--
View this message in context:
WiX is a layer on top of Windows Installer, which has a certain look that
can't be changed. You could customize the look by adding a bootstrapper
project and writing a custom BA using WPF or WinForms, but that would be
some extra work on your part for such a small requirement.
--
View this
Just a few questions to help clarify:
What do you mean when you say it's not working?
Where are you putting the PermissionEx elements? Inside of a RegistryKey
element?
In your code sample you're using curly braces: {username}. Is that how you
have it for real?
--
View this message in context:
Using a custom action is something I hadn't considered. Here's a past posting
where someone was doing that:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/OpeFileDialog-C-Custom-Action-td5860149.html
--
View this message in context:
StartType on the ServiceInstall table is not listed as a Formatted type.
Only formatted types can accept Windows Installer properties. I don't think
it's possible to do what you want with WiX markup. Possibly a custom action
could be made to handle it.
--
View this message in context:
You cannot use the Message method to write to the install log when the custom
action is called using the DoAction control event. This is a limitation of
MSI.
--
View this message in context:
Could you provide the steps you're using to create the installer? With
command line arguments?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Falling-back-to-default-language-if-locale-is-not-present-tp7582282p7582309.html
Sent from the wix-users
I'm more of a .NET guy, where the session.Message method in the DTF library
can't be called from within a DoAction custom action. It calls the
MsiProcessMessage behind the scenes. So the Message method you're talking
about may be different.
It seems to be a part of something called the
Several people from the WiX community lent a hand getting the update to the
WiX book into shape. The end result covers more ground than the last
version, including, of course, Burn. All in all, I'm very pleased with the
end result! It's available for the Kindle on Amazon's site at:
Does it work if, instead of using the ServiceConfigFailureActions and Failure
elements, you use the util:ServiceConfig element? It has
FirstFailureActionType, SecondFailureActionType and ThirdFailureActionType
attributes that you can set to restart, runcommand or reboot.
--
View this message in
Could you attach the part of the log into the email message? Attachments
don't show up in the forum for me. It could be a couple of things really.
Might help to post some of your WiX markup too.
--
View this message in context:
I don't see your MSI in the bundle's chain. Only the python and .NET ones. Is
this the code you wanted to show to the forum?
I've gotten that error message once before. It went away after I recompiled
through.
--
View this message in context:
In your Bundle.wxs, if you have:
BootstrapperApplicationRef Id=ManagedBootstrapperApplicationHost
...
/BootstrapperApplicationRef
then you also need, after the BootstrapperApplicationRef:
WixVariable Id=WixMbaPrereqLicenseUrl Value=... /
WixVariable Id=WixMbaPrereqPackageId Value=... /
That's a syntax I've not seen before: using the Property and VBScriptCall
attributes to trigger an embedded VBScript custom action. Try taking that
out and putting your script inside the CustomAction element.
CustomAction Id=A.ContentName Script=vbscript Execute=immediate
lt;![CDATA[
It's acceptable to include the same components (your Java components) in two
different features.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Adding-feature-dependency-tp7583348p7583384.html
Sent from the wix-users mailing list archive at
It is MSI's default behavior to choose the disk with the most space. Try
capitalizing the property to TARGETDIR.
TARGETDIR=E:\
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Msi-is-not-creating-in-the-Drive-tp7583373p7583385.html
Sent from the
You could try to hardcode false in the app.config. Then, put a conditional
statement inside the Component element that has the XmlFile in it so that
the component will only be installed (and the app.config written to) if the
property exists.
When the box is deselected, the property should be
Have you read through the various documentation: manual, tutorial, book at
http://wixtoolset.org/? I would start by learning the basic of building a
WiX project before jumping into installing a website. Installing a website
is an advanced topic. To do so, you will need to use the WiX IIS
Are you able to start/stop the service manually? Just to make sure there's
nothing wrong with the service itself. What is the exact error message
you're seeing? Is there anything in the Windows event log? Such as a
permission issue?
--
View this message in context:
That's good that you can start the service manually. That means that there
isn't something wrong with the service itself. Also, the error message
you're seeing is a generic message, not necessarily related to permissions.
The first thing I'd try is adding the Wait attribute to your ServiceControl,
This is an interesting circumstance. Chocolatey is a new way of deploying
software packages, sort of like apt-get on Linux. Ordinarily, upgrading
software that was previously installed via an MSI is easy. You just author a
major upgrade into the next MSI or you create a patch. I'm not familiar
That sounds right to me. Use a MajorUpgrade element to handle the upgrade.
That will replace the obsolete version and replace it with the new one.
You'll just need to manually change the Product's Id (and Product version)
in updated versions of the MSI.
--
View this message in context:
So is there a different install/uninstall set of URLs for each MSI version?
Just curious.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Using-Product-Id-tp7583827p7583881.html
Sent from the wix-users mailing list archive at Nabble.com.
Not sure yet how to check if the value is already written in the file. But to
write it, you could use something like:
ComponentGroup Id=ProductComponents Directory=INSTALLFOLDER
Component Id=CMP_MyFileXML
Guid={05AB616A-AD9E-468B-AE86-477759234CA0}
File Source=MyFile.xml KeyPath=yes
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:
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
--
Nick Ramirez
--
View this message in context:
http://n2.nabble.com/MSI-5-0-ServiceConfigFailureActions-fails-during-InstallExecuteSequence-tp4452709p4469530.html
Sent from the wix-users mailing list archive at Nabble.com
SE_SHUTDOWN_NAME.
Phil Wilson
-Original Message-
From: Nick Ramirez [mailto:nickra...@hotmail.com]
Sent: Wednesday, January 27, 2010 12:30 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] MSI 5.0 ServiceConfigFailureActions fails during
InstallExecuteSequence
I've
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 specific
problem.
A
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 Condition elements
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:
Control
Id=myCheckbox
Type=CheckBox
CheckBoxValue=my value
X=50
Y=50
Height=10
Width=150
Text=Check the box please.
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
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
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:
Control
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
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
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
-Original Message-
From: Nick Ramirez [mailto:nickra...@hotmail.com]
Sent: Thursday, April 29, 2010 2:48
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
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
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
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
ownProcess.
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.
UI Id=CustomWixUI_Minimal
Add a UIRef element to your main .wxs file with an
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:
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:
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
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
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
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
Here's how I understand it:
For an MSI package (unlike an MSM package) you only specify one LCID for the
Package element's Languages attribute. If you omit it, it will be considered
a language neutral package. This is stored in the Template Summary property
of the MSI, which you can see by
We've found that if we've already installed our MSI, but then try to install
it again (from the command line) and supply the ADDLOCAL property, it takes
us to the ResumeDlg (this seems to happen for any MSI using a WiX dialog
set). What we really want is for it to take us to the
I think this:
CustomAction Id=ResetPreselected Property=Preselected Value= /
InstallUISequence
Custom Action=ResetPreselected After=CostFinalizeInstalled AND
Preselected/Custom
/InstallUISequence
fixed my problem, but I'm still curious about how MaintenanceWelcomeDlg is
included. Anyone
Hello everyone,
I wonder if anyone can help with this. I'm using the WebAddress element to
set the address for my website:
iis:WebAddress Id=WebServiceForPhoneSystem_WebAddress
bIP=*
Port=443
Header=[ASMX_WEBSITE_DNS_NAME]
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
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=*
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
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
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
Hello all,
I've gotten pretty far (I think) in creating a compiler extension. So far,
my extension is a .dll that can be included in my WiX MSI project. After
including the extension, I can see my new element in Visual Studio and can
add attributes to it. When I use it, a new custom table is
Oops. Sorry. I posted the wrong part of the code. Here's the part that I use
to register the .wixlib:
public override Library GetLibrary(TableDefinitionCollection
tableDefinitions)
{
if (this.library == null)
{
this.library = LoadLibraryHelper(
Thanks Blair and Neil for the help. I looked at the extension you gave a link
to, Neil, but I'm not able to see anything that they have that I don't. I'm
sure there's a piece to the puzzle I'm missing.
At the risk of sounding completely clueless, how does one debug an extension
project? It seems
Oookay. So, now it's one of those situations where it didn't work and
magically...it does! What did I do? I messed around with flags for lit.exe,
removed them, changed things back to what they were orginally...rebuilt
everything and it worked. So, same code, different result. I'm not sure. I
Thanks Rob. I'd love to contribute. Where do you need more eyes?
As for the compiler extension, I'm back to where I was. I haven't been able
to get Candle to recognize the embedded wixlib in my compiler extension.
Experimenting with several ideas, I've added the Link element to my build
script,
I've got an update. I've gotten my wixlib to show up in my MSI! The trick,
for me, was to add a Property to the Fragment in the wixlib I was embedding
and then use a PropertyRef to pull it in in my installer project. Pulling
that in pulled in all the other stuff (including custom actions) from
Ah, fantastic. That sounds like a much more elegant solution that using a
PropertyRef. Thanks Blair. So, it looks like this method is referencing a
table and row that would be created with the wixlib. Like this from the Util
extension.
core.CreateWixSimpleReferenceRow(sourceLineNumbers,
Apparently, there's hyperlink support with MSI 5.0. Bob Arnson blogs about it
here:
http://www.joyofsetup.com/2009/01/17/msi-v50-features-in-wix-v30/
Going back to your earlier question, about re-evaluating whether .NET is
installed, the reason you're getting the same result even after .NET has
In many cases, you need to make your own version of the .wxs file to replace
that dialog in the wizard. However, in your case, you only want to change
the text on the buttons. So, it's much easier. You only need to add a .wxl
file to your project with the strings that match the text and tooltip
If I'm reading this correctly, you're code is this:
MTPreInstallDlg
Control
Id=LicenseFile
Type=PushButton
X=20
Y=120
Width=56
Height=17
Text=Browse
Publish Property=_BrowseProperty Value=[LICENSE_FILE]
Order=11/Publish
Publish Event=SpawnDialog
Can anyone tell me when you would use Light's -sacl flag?
I found this post:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/LGHT1032-Unable-to-reset-acls-on-destination-files-td689045.html#a689046
but I don't understand it. Is this flag used when sending the output of a
WiX build
Thanks Neil. I've been trying out different scenarios with sending the output
of my MSI build to a network share and viewing the permissions of the MSI.
But I must be missing something. Do you have an example of the permissions
problem?
--
View this message in context:
Okay. Now I see what you mean. I can see how the -sacl flag affects the
output MSI. I followed these steps:
1. Create a folder to send the output of the build to, call it something
like Output
2. Set the permissions on that folder to not inherit their permissions from
the parent folder and then
I think your question may stem from thinking that you have to specify
localization files of different cultures with each -loc flag. However, you
could also specify multiple .wxl files with the same culture. For example,
if you had one .wxl file to handle all of the localization strings for your
You are right. An MSI can only be localized for one language. What that means
is actually pretty simple. If you look inside the MSI database (with a tool
like Orca.exe), you'll see that many of the tables contain text (the Control
table, for instance). Once the MSI is built, these strings are
There's a static method called Preprocessor.GetSourceLineNumbers that accepts
an XmlNode object. It's used by WiX as Candle is looking through your
markup. I'm not sure that you'll be able to use it very easily. If you don't
mind my asking, what is it you're trying to achieve? Preprocessor
So, this is a sort of validation to make sure the database type they've
selected is truly installed? In that case, you could call your custom action
when the user clicks the Next button on your dialog. You can do that by
adding a Publish element inside the button control, setting its Event
I think you're on the right track. The Name attribute on the Directory
element can't use the [PROPERTY_NAME] notation because it isn't a formatted
string field. Examples of attributes that are include the Text attribute on
the Control element, the Title on Dialog, and Message on Condition.
If
Oops.
Replace Value=[VirtualDirectoriesdir]INSTALL_SHAREPOINT_PORT
with
Value=[VirtualDirectoriesdir][INSTALL_SHAREPOINT_PORT]
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-refer-WIX-properties-within-wxs-files-tp5537053p5538585.html
I'm not sure why, but this seems to work for me:
!--Next button--
Control Id=NextButton Type=PushButton ...
Condition Action=disable
![CDATA[DisableButton = 1]]
/Condition
Condition Action=enable
![CDATA[DisableButton 1]]
/Condition
...
/Control
!--SelectionTree
Have you tried the CheckBoxPropertyRef attribute?
Control
Id=CB1
Type=CheckBox
Property=myCheckboxResult
CheckBoxValue=my value
Text=Check the box please.
X=50
Y=50
Height=10
WiX does offer up a browse dialog control called DirectoryList. It's often
paired up with a PathEdit control to display the path you've selected, a
button to navigate up one directory (PushButton control that publishes the
DirectoryListUp event), a button to create a new folder (PushButton that
Right, I sort of understood your question from the start, but I tried to take
the easy way out! Try this:
Control
Id=CB1
Type=CheckBox
Property=myCheckboxResult
CheckBoxValue=my value
Text=Check the box please.
Hi everyone. I've just gotten a book about WiX published. A portion of the
proceeds will go to the WiX team. I'm not sure how all of that is set up, so
Rob and Bob let me know if you don't see it! Anyway, it should be a good
guide for those new to WiX. It also gets into creating UI controls,
So, is your build server building the dependencies after the .wixproj
project? Is it a matter of it not invoking the correct configuration?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Project-dependencies-not-working-tp5640712p5647660.html
Sent
At first, you were using:
Text!(loc.License_Agreement)/Text
which uses a localization variable. You then switched to placing all of the
RTF content inline. Did you mean to do that? Or did you still want to use
the localization variable? If so, you can put the RTF data in your .wxl
file, such
A major upgrade, as you probably know, will completely remove the old
version. So, if your second installer does not write to the registry, it
makes sense that the value will be removed but not replaced. You shouldn't
change the UpgradeCode for the lifetime of the product, across all upgrade
1 - 100 of 277 matches
Mail list logo