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
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:
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:
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
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:
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:
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
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
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
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
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
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.
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,
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:
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
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
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[
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=... /
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
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:
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:
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:
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.
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
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
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
This is not a big issue, really just something I stumbled on and am curious
about. If I use a localization variable in a component's GUID, like this:
/Component Id=cmpSomeFileTXT Guid=!(loc.SomeGuid)
File Source=SomeFile.txt /
/Component/
And then add a .wxl file:
/?xml version=1.0
Oh, glad I asked then. The way that I've done localizable text in software
has been to use a satellite assembly. In that case, I think that each set of
localized strings gets its own assembly (if I am remembering that
correctly). Maybe best practice is to include all of these assemblies in the
You probably don't want to use TARGETDIR in this way. TARGETDIR points to the
root directorty (C:\ for example) of where your files will be installed to.
It's not typically where you put components.
See this link about TARGETDIR:
Seems to be Burn specific and sets a Burn variable while the other
RegistrySearch that's not in the UtilExtension sets a Property.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/util-RegistrySearch-tp7581620p7581624.html
Sent from the wix-users
I've come across an executable installer that has a flag to allow it to be
installed silently. However, it doesn't have any uninstall flag. Its
documentation recommends that it be installed with msiexec. In these cases,
does anyone have an opinion on what the best uninstall strategy is? Should I
I have a simple Burn installer that is attempting to install two patches. The
markup is like this:
Chain
MspPackage SourceFile=Patch1.msp /
MspPackage SourceFile=Patch2.msp /
/Chain
The software that it's supposed to update has been installed. If I were to
install the MSP files
It seems that this only happens if I am installing two patches. If I comment
one out and only have one listed in the Chain, then it gets installed okay.
The log for a good attempt, only installing one patch shows:
Verified acquired payload: Patch2.msp at path: C:\ProgramData\Package
The version I have is 3.6.3303.0. I took a stab in the dark and rearranged
the elements various ways, but couldn't come up with a solution.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-failing-when-two-MspPackages-tp7580938p7580953.html
That's what I figured. The installer in question is the Java Runtime. It's
pretty sparse with the command-line flags!
--
View this message in context:
I was trying out the Chain/@ParallelCache attribute and found that it shaved
a second or two off of my install time. I'm sure that bigger installs would
see more time saved. I was just wondering, is there ever a time when you
would not want to use this optimization?
--
View this message in
I tried setting a condition:
/Bundle Name=My Software
Condition=VersionNT = 500
.../
But it always evaluates as false.
/Condition 'VersionNT = 500' evaluates to false.
Bundle global condition check didn't succeed - aborting without loading
application./
A Windows 7 machine
Based on Neil Sleightholm's blog,
http://neilsleightholm.blogspot.com/2012/05/wix-burn-tipstricks.html, it
seems that the VersionNT is a value like v6.1. Strange that it's not the
same format as the Windows Installer property, but now the condition
evaluates as expected.
/Condition=VersionNT =
Thanks Jacob. Looks like I did gloss over that part in the documentation.
Interesting that the VersionNT value was changed though.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-conditions-tp7580784p7580875.html
Sent from the wix-users
Experimenting a bit.
Installing a newer version bundle over an older one causes the old bundle
entry in Add/Remove Programs to be overwritten with the new one, such as
going from bundle version 1.0.0.0 to 1.1.0.0. In the end I only get one
entry. The MSI that's packaged gets a major upgrade. (I
I noticed that there's Bundle/@Condition and there's also
bal:Condition Message=some message
/bal:Condition
Is the element Condition preferred over the attribute since it can have a
descriptive message? Also, are the only properties we can use here the ones
that are available at this early
If I've got an MSI package in my bundle's chain that is /newer/ than some
previously installed version on the user's computer, will Burn automatically
pick up on that? That a major upgrade needs to happen for /that/ particular
MSI? This is assuming I don't change the version on the Bundle.
Or is
Reading through the source code and just doing some experimentation helped me
figure it out. But in case anyone else is looking for a practical
definition:
Error during MSI 3 here means rollback to the last boundary. Uninstall MSI 2
and 3, but keep 1 since it was before the boundary:
Chain
When I'd created a new website in IIS and wanted to bind a certificate to the
IP address, I didn't find a WiX element that would do it. At the time, I
used a shell script to do this binding, using netsh. I ran the shell script
as a custom action. This probably isn't the most robust way to do it.
Could you use a custom action to get the environment variables at install
time? In managed code:
System.Environment.GetEnvironmentVariable(String name)
I'm not sure if there's a declarative way of doing this in WiX.
--
View this message in context:
I was curious about the *OptionalUpdateRegistration* element. Seems to have
to do with patches? So, this is for a scenario where you've grouped a couple
of MSP files into a Bundle?
--
View this message in context:
That %VariableName syntax, I'm not familiar with that in WiX. It reminds me
of parameter values in a Windows shell script? Are you wanting to collect
the domain\username from the person who launches the installer? If that's
the case, if you wanted them to pass that in on the command line, you
I've got the following markup in my bootstrapper:
BootstrapperApplicationRef
Id=WixStandardBootstrapperApplication.Foundation
bal:WixStandardBootstrapperApplication
ThemeFile=custom.thm
LicenseFile=CustomLicense.rtf
LocalizationFile=thm.wxl
The RtfLicense standard UI works. Are there any known issues with the
Foundation UI?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-standard-UI-wxl-tp7580680p7580681.html
Sent from the wix-users mailing list archive at Nabble.com.
It looks like FileShare (and User) is included in the WixUtilExtension. Have
you added that as a referenced assembly in your project and added the util
namespace to your Wix element
(/http://schemas.microsoft.com/wix/UtilExtension/)? You would also need to
then prefix the FileShare element with
Just to clarify, are you saying that it is finding the default website
correctly and placing the new web application under it? But that WiX is
somehow changing the IP address binding of the default website?
--
View this message in context:
One of the problems I've encountered when using .wixpdb files to create a
patch is there's no way to bind the binary data into them. So, if you move
them, there's a good chance the paths to your source files won't work
anymore. (For this reason I find that using .wixout files are easier because
Does the .exe get run at all? The ExeCommand should be the parameters passed
to the executable.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Running-an-Exe-tp7580285p7580288.html
Sent from the wix-users mailing list archive at Nabble.com.
I'm just playing around with creating a .thm file and, for me at least, when
I set the foreground or background of a Font, like this:
the hex code is not the RGB I'm used to seeing in say, CSS. It seems to be
BGR? The Font here makes blue text on a red background. Is there a story
behind that?
I've been looking over the Windows Installer documentation and it says that
if you don't specify the Languages attribute (on the Package element), then
the language defaults to neutral.
http://msdn.microsoft.com/en-us/library/Aa372070
In my own experiments, when I leave off that attribute and
Oh hang on, I see. It's picking up the code page from the Product element.
So, to make a neutral package, I'd need to set Language to 0 on the Product
element and the Package element.
--
View this message in context:
I found one workaround. Putting the RegistryKey inside of another RegistryKey
that does have a value marked as the keypath. That satisfied the ICE38 rule
for that component.
--
View this message in context:
Does anyone know the best method for writing an empty Registry key under
HKCU? This code isn't cutting it:
*ComponentGroup Id=ProductComponents Directory=PersonalFolder
Component Id=CMP_RegistryWrite
Guid={3BF28DC8-4AFC-43E8-B605-AA6456B06921}
RegistryKey
Root=HKCU
When you say the harvest functionality has been disabled, are you referring
to a particular part of Heat.exe? Like for me, harvesting a project didn't
work out too well (it didn't pick up the dependencies), but harvesting a
directory works just fine. Is the new info in the help files?
--
View
Looking through the WiX installer, in CoreMsi\Doc.wxs, I see a shortcut being
added:
Component
File Source=WiX.chm /
Shortcut Id=WixChmShortcut
Directory=ShortcutFolder
Name=WiX Documentation
Icon=WixSetupIcons.ico
jimitndiaye wrote
Run the setup executable with the /layout command on a machine that does
have connectivity. It should download all required files into a folder of
your choosing. Copy that to your target machine then rerun setup as
normal.
Right, that part I understand now. There was an
I guess there's a bug open about this. 3534099. If I disable the network
adapter on my virtual machine and try the install with the /layout option,
it fails (after I've chosen the layout directory). So possibly an offline
install is still in the works?
--
View this message in context:
In your BootstrapperCore.config file, should:
host assemblyName=TestBA
be
host assemblyName=MyBA
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Wix-bootstrapper-sample-issue-tp7576441p7579431.html
Sent from the wix-users mailing list archive at
Now it makes sense to me. Have to create the offline installer with the
/layout option and then take that to the offline machine and install it.
Tested it out on a Windows 7 x64 machine with no internet connection.
This may be more of a .NET Framework installer issue (this machine didn't
have
What does DiskPrompt and VolumeLabel mean when used on a MediaTemplate
element? On the old Media element, it made sense because each Media element
corresponded to a unique CAB file:
Media Id=”1”
Cabinet=”media1.cab”
EmbedCab=”yes”
DiskPrompt=Disk 1
Looking at the definition for ServiceInstall, you have to have the File
element in the same component. So, that limits you. Otherwise you'd be able
to put the File in one component and maybe reference it by two different
ServiceInstalls. Alas.
I've done something that may be similar to what
I see. What would Result.Ok do then in this situation? Is there a place that
lists what the different result codes do, out of curiosity?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/NET-4-pre-req-in-WixNetFxExtension-tp7579058p7579374.html
Sent
This has all helped. Apparently, I've been testing too many things at once
and must have been experimenting with the ForceReboot element in my MSI.
Removing that should make things run much smoother!
--
View this message in context:
I've been able to install my bundle with Burn, but I'm having trouble
uninstalling it. I have an uninstall button on the UI that when clicked
calls a method that starts the Plan phase:
public void StartUninstalling(Window mainWindow)
{
this.mainWindow = mainWindow;
Okay, an update: Actually, if I click my Uninstall button after the reboot,
it does eventually uninstall the bundle. Is it /supposed/ to require a
restart to uninstall a Burn bundle? And does that restart only become
mandatory when you want to uninstall?
--
View this message in context:
*I'm reference this in the Chain element:*
PackageGroupRef Id=NetFx40Redist/
*But I get an error using my custom bootstrapper application:*
Plan complete, result: 0x0
[0A00:07D8][2012-07-06T23:48:46]: Apply begin
[0BD4:07B8][2012-07-06T23:48:50]: Creating a system restore point.
Can someone explain what the RollbackBoundary element is used for? Is it
always used with the ParallelCache attribute on the Chain element? Thanks!
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/What-is-a-rollback-boundary-tp7579098.html
Sent from
Thanks, Bob!
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/NET-4-pre-req-in-WixNetFxExtension-tp7579058p7579070.html
Sent from the wix-users mailing list archive at Nabble.com.
It's fantastic that with the later builds of version 3.6, we can reference
the WixNetFxExtension and then put PackageGroupRef Id=NetFx40Web/ in to
make .NET 4 a prereq.
Chain
PackageGroupRef Id=NetFx40Web/
MsiPackage SourceFile=MyInstaller.msi /
/Chain
Looking at the source code for
So, assuming I put a cancel button onto my managed bootstrapper application
UI, can anyone say what's the best practice for carrying it out? Do I
somehow trigger a rolled back on the entire chain of packages? If so, what's
the method to call?
I've been looking through the WiX demo setup, but I'm
That makes perfect sense then. To use the Directory attribute feature, I will
just have to nest the components inside of the ComponentGroup. With so many
ways to arrange these elements, I wonder which way is the cleanest or most
readable or most maintainable.
--
View this message in context:
You can put an ampersand in front of the name of the feature to check its
action state. There's some more info about it here:
http://wix.tramontana.co.hu/tutorial/com-expression-syntax-miscellanea/expression-syntax
and here:
I've never got it to work for me to show attachments. Maybe you could paste
the relevant code in? So, when it doesn't show the custom dialogue in
maintenance mode, do you mean that it skips it and goes to the dialogue
after that?
--
View this message in context:
The default WiX setup project template in WiX 3.6 generates a ComponentGroup
element with a Directory attribute on it. An early post by Rob says that
this attribute is meant to be inherited by any child components:
What I was thinking about was the ability to do ComponentGroup/@Directory,
which
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
101 - 200 of 277 matches
Mail list logo
