the book or try running
your arguments directly against the SQL Server executable. That may give you
better error output. Also, there may be a log of the install in the temp
directory.
Nick
Date: Sat, 27 Jun 2015 03:01:55 -0700
From: ml-node+s687559n7600728...@n2.nabble.com
To: nickra...@hotmail.com
...@n2.nabble.com
To: nickra...@hotmail.com
Subject: Re: Bootstrapping SQL Server 2012 Express
Nick Ramirez wrote
Finally got it to work, after installing .NET Framework 4. I guess the SQL
Server installer can't do that for itself. ;-) Must have been some missing
dependency. Thanks all
-td7590635.html#a7590638
I've picked up the development build and ran with the -xn switch, which fixes
up the custom action issue, but I am still left with the merge module one.
Is there a way around this?
Nick Ball
Lux, as I understand it, tests that a property has a particular value after a
custom action has run.
As far as a robust test, this is pretty weak. Setting a property is just a
small part of the install process. But the sum total of an installation is
to put files on the system, configure the
I tried something similar and it compiled okay for me.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/LGHT0091-Duplicate-symbol-error-tp7598838p7598856.html
Sent from the wix-users mailing list archive at Nabble.com.
Thanks for the fantastic detailed clarification on this issue! I will endeavour
to use the melt approach outlined in Bob's post.
-Nick
--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET
Sounds like undocumented functionality of Melt. I don't see anything about
using it that way in the WiX.chm.
Also, binder variable don't solve the problem of binding the source files
into the XML file. They only give you a way to list a bunch of paths to
probe. So they don't replace the
if this is the best approach. Should
I just use the wixpdb approach instead?
Regards
Nick
--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot
Bind paths vs. Visual Studio project references (e.g.
$(var.MyProject.TargetDir))...the latter doesn't require passing custom
parameters to light. Why make the specifying of a source file more arcane
with a bind paths binder variable? Especially when the use case is a patch
file in the unseen
Ouch. So now you have to keep your old and new source files on hand. Would be
nice to keep the bind-files option or work it into the wixpdb. Also, not
being able to bind the files into the wixout or wixpdb means that if you
move the wixout/wixpdb and then try to run Pyro against it, all the paths
You cannot check whether a condition or feature is going to be installed in a
feature or component condition, since costing hasn't taken place yet.
Maybe you have a very special use-case, but in most cases, you've likely got
your features badly organized. With more information, we may be able to
WiX doesn't have a UI control that will show files in a file-explorer window.
You'll probably have to write a custom action that opens one.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/File-explorer-dialog-tp7598706p7598708.html
Sent from the
/1) First try - I have installed the file on the Document's folder and the
modified it with the wix extension XmlFile.this work for coping the file but
fail to modify it as reported the error that it can't find the file to
modify/
Some questions I have:
1. What error are you seeing?
2. What are
Okay, so it sounds like you want to:
1. Install the file to the Documents folder
2. Edit the file in place after it's been installed
I've often seen people posting about having problems using XmlFile. I have
always used the XmlConfig element instead and haven't had any problems. You
might get
Components can also be included in more than one feature. Could you add
subfeatures under your codec features?
- Feature: “Core files” (required)
--- Subfeature: “Codec A” (optional)
-- Subfeature: “Windows Explorer integration” (optional)
--- Subfeature: “Codec B” (optional)
--
I forgot about it, but you may have to publish the AddLocal event. I guess
it's been a little while since I thought about it, because I can't remember
if you can add/remove features with a feature condition outside of the
feature tree or if you have to use the AddLocal event (published by the
Next
Shouldn't need CreateFolder either.
Can you use a Property to store the password? Put the Hidden attribute on
it. I'd check the log after that to make sure it's hidden.
I am assuming the the IisExtension hides its custom action data already
(CustomAction/@HideTarget).
--
View this message in
I saw this and thought I'd pass it along. Books on the Packt Publishers
website are $5 until Jan 6. Includes the WiX book and the pre-release of the
new WiX Cookbook.
www.packtpub.com/all/?search=wix
--
View this message in context:
I thought it worked for me before too. But trying it again, it only
associated the certificate with the Web site after I'd added a
CertificateRef inside the WebSite.
--
View this message in context:
The personal store is available at localmachine too. Go to:
Run - mmc - File - Add/remove snap-in - Certificates - Add...
You'll see the option for Computer account and that's analogous to WiX's
localmachine. It has a personal and root (aka Trusted Root Certification
Authorities).
Right off, I
Does /-ext WixUtilExtension/ work?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/XmlFile-or-XmlConfig-in-patch-msp-tp7598517p7598616.html
Sent from the wix-users mailing list archive at Nabble.com.
Should you do this at all? Run a configuration script after the installation?
In most cases, you shouldn't. It should be part of the install. Collect all
the data you need for the configuration during the UI portion of the install
and then use that data in deferred custom actions during the
What do your calls to torch.exe and pryo.exe look like? Do they include the
-ext flag for the UtilExtension?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/XmlFile-or-XmlConfig-in-patch-msp-tp7598517p7598549.html
Sent from the wix-users mailing
Take a look at
http://msdn.microsoft.com/en-us/library/aa370739%28v=vs.85%29.aspx where it
says:
/The Custom Action Patch Uninstall option is not available. There is no
method for marking a custom action within a patch package to be run when the
patch is uninstalled because the installer does not
Are you handling the ResolveSource event? See:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/NET-4-pre-req-in-WixNetFxExtension-td7579058.html#a7579356
--
View this message in context:
What your WiX mark-up for the file look like?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/ICE60-during-install-of-ttf-file-to-private-folder-tp7598542p7598557.html
Sent from the wix-users mailing list archive at Nabble.com.
You'll want to make sure that your CA is scheduled during
InstallExecuteSequence and is deferred. Then, set the CustomActionData for
that CA, passing it your ENV property that way.
However, since you're updating an XML file, then the UtilExtension has XML
elements (XmlConfig) to do that, so you
According to the documentation for the Requires elements
(http://wixtoolset.org/documentation/manual/v3/xsd/dependency/requires.html),
it can be put inside of a Product element.
I am wondering if that's a feature that hasn't been implemented yet. What
I'm saying is, it sounds like the WiX team
Use a feature condition. A feature condition is where a Condition element is
placed inside a Feature element. There, it can change whether or not that
feature gets installed depending on if the statements evaluates to true.
It does this by changing the Level of the Feature:
Feature
It looks like what you have is correct. You have a SAME_VERSION property.
Although you might want to set OnlyDetect to yes if you want to keep the
existing product there and not overwrite it.
Then, use a launch condition to stop the new installation from going through
if SAME_VERSION is found.
A bootstrapper is just a list of install packages that are installed one
after the other. So, if you had three install packages in the bootstrapper,
you wouldn't have one install directory, you would have three. For example,
if you bootstrapped SQL Server, the .NET framework and then your
I was just thinking about this: What's the best practice for a custom action
that has a problem?
* Catch all exceptions and return ActionResult.Failure
* Allow the exception to be thrown?
Maybe ActionResult.Failure should be used for non-exception failed states?
Such as the user entered
Nope. Installing the WiX Toolset should get you all set up with VS 2013. No
other setup is required. I've tried it several times and it works for me.
--
View this message in context:
Try posting this on the wix-devs forum.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Latest-build-wix-3-10-visual-studio-2013-problem-tp7598342p7598353.html
Sent from the wix-users mailing list archive at Nabble.com.
If you want to install only for the current user, you should install to the
LocalAppDataFolder instead of ProgramFilesFolder. ProgramFilesFolder
requires elevated privileges since it's a machine-level folder.
LocalAppDataFolder is for current-user-only installs (Package/@InstallScope
= perUser)
Do you mean, create a file share?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Create-network-folder-tp7598287p7598356.html
Sent from the wix-users mailing list archive at Nabble.com.
How come you're using mst files for localization and not .wxl files that are
built into WiX?
http://wixtoolset.org/documentation/manual/v3/howtos/ui_and_localization/make_installer_localizable.html
--
View this message in context:
You don't need to put an Id attribute on the Fragment, it won't be used.
The Id attributes of Directory elements are themselves, properties. You can
see the full path to your install directory be looking at the value of the
property called INSTALLDIR. You can see it in the MSI log:
msiexec /i
WiX has a Group element in the Util Extension that can find an existing
Windows group, but can't create one of any kind. Its User element can create
a user, but I'm not sure if it works with AD. It has a Domain attribute, but
that may only be for referencing an existing AD account.
--
View this
To bind the certificate to the Web site, you can do something like:
iis:WebSite Id=myWebsiteElement Description=MyWebsite
ConfigureIfExists=yes Directory=INSTALLFOLDER
iis:WebAddress Id=myWebAddressElement Port=443 Header=mywebsite.com
Secure=yes /
/iis:WebSite
That should go into the same
You're overthinking it. You can set up your Directory elements for whatever
directory structure you need and wherever the user changes INSTALLFOLDER to
be, its child Directory elements will follow it there. For example, if the
user changes the path of INSTALLFOLDER to C:\MyStuff, they'll get:
C:/
I would only suggest uninstalling WiX and reinstalling. For me, when I do
Ctrl + SPACE, I get a list of WiX elements. I clicked just underneath the
Package element in the Product.wxs file and did Ctrl + SPACE.
--
View this message in context:
This probably isn't going to be helpful because I'm not that well-versed with
using Group Policy. But when I tried it once, the program ended up on a
different screen that regular programs. I had to go to *Control Panel -
Programs and Features - Install a program from the network*.
I base this
What are you wanting to uninstall? Is it an upgrade scenario? Are you trying
to replace an older version of your software with a newer version?
Or are you trying to remove some other software when yours is installed?
--
View this message in context:
Did you update your UIRef element to point to your new UI_Custom?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/FW-Correct-method-for-modifying-a-built-in-UI-tp7597759p7597765.html
Sent from the wix-users mailing list archive at Nabble.com.
I don't think the Exit dialog is going to be shown, in most cases, during an
uninstall because Add/Remove Programs (Programs and Features) suppresses the
UI when the user uninstalls from there. So, setting the property directly
may be enough.
I can't recall of the top of my head what that
I didn't read carefully enough. You only want to display the message on
uninstall. Because ARP suppresses the UI, the dialog won't be shown on
uninstall.
I was so close to having this work by simply adding something like that to
Burn's License UI theme. Alas, even though, with Burn, that Exit
Hmm...
Just to double-check:
Copied the Fragment contents of WixUI_Advanced.wxs to be local to
my installer project. Saved in separate wxs file
2. Renamed the UI, made the modifications I needed
---* Did you change the Id on the UI element?*
3. Copied the
The NetFxExtension always downloads it. To have the .NET 4.5.1 package
compressed inside your bundle, you would have to write the mark-up yourself.
You can use how the WiX team did it as a rough guide:
http://wix.codeplex.com/SourceControl/latest#src/ext/NetFxExtension/wixlib/NetFx451.wxs
Is SQL Server already set up? When you set it up you can enable Windows
authentication at that point. Otherwise, you'd have to turn it on somehow
during your installation, but could be trickier.
Are you installing SQL Server along with your website install? If so, turn
Windows authentication on
Not sure. Now that you've moved code into a wixlib, any UIRef elements left
hanging around still pointing to the old UI? It's probably something simple
that I'm not thinking of.
--
View this message in context:
Is the install log showing anything helpful? You say it's a permissions
issue.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Installing-DirectX9-Components-within-a-perUser-MSI-tp7597763p7597775.html
Sent from the wix-users mailing list archive
Thank Rob. Now I've tried the following:
sql:SqlDatabase ...
sql:SqlString Sequence=1
Id=sqlString_rollbackUninstall
SQL=CREATE DATABASE MyDatabase
RollbackOnUninstall=yes
ContinueOnError=yes /
Can anyone say what the current state of the Update element that goes into a
Bundle is?
http://wixtoolset.org/documentation/manual/v3/xsd/wix/update.html
Does it work, currently, with the standard BA? Or would someone have to
write their own to take advantage of detecting an updating MSI package
Thanks Jacob, that sounds like really good work on your part. I will follow
the link to learn more about it, and it will be nice to eventually see that
in the standard BA.
--
View this message in context:
Jeremiahf wrote
Sorry, Thought you were trying to remove the user from the group on
uninstall.
Yep. That's what I'm trying to do. The LocalGroupMember element from the
Community MSI Extensions does what I need. Not sure whether I should say
it's a bug in the Util extension that it lacks this
No need to make my own custom action. I've found that the WiX extension from
the Community MSI Extensions project has an element for adding an existing
user to a group that works for me.
--
View this message in context:
I have the following markup to add an existing user to a group:
Fragment
util:Group Id=AdministratorsGroup Name=Administrators /
ComponentGroup Id=ProductComponents
Directory=INSTALLFOLDER
Component Id=cmpExistingUser
Thanks Rob. For me, this is a thought experiment in which I was trying to
learn more about rollback CAs. So, my scenario is (similar to editing an XML
file with XmlFile), I wanted to install a JSON file and edit it at
install-time. If the installation failed, I would rollback the file to what
it
The result returned by a rollback CA can be Success or Failure. But should
that response be ignored by the installer? If I check it, and it is a
Failure, will that prevent the installer from rolling back?
--
View this message in context:
In a deferred custom action, I am changing some text in a file. I want to be
able to undo those changes in a rollback custom action. So, I'm attempting
to store the original contents of the file and then set the file back to
that data in the rollback CA.
The place where I've tried to store the
I wasn't able to find a way to pass data from a deferred CA to a rollback CA.
Nor could I access the session's database, which prevented me from storing
the data in a custom table.
The only way I found that worked was to store the original file in the TEMP
directory and, in the rollback, restore
A very old post, but in case anyone was wondering, to get the Change
permission on a file share, use the following properties on
FileSharePermission:
GenericWrite=yes
Traverse=yes
Delete=yes
GenericRead=yes
--
View this message in context:
I tried it again tonight and it's working just fine. The WIX variable is
there. I'm not sure what happened before. But I won't worry about it. I had
installed Visual Studio Express just before installing WiX (knowing that it
doesn't work on Express, but wanting to make sure that it /still /doesn't
After installing WiX 3.8 on Windows 8.1, I saw that the system environment
variable WIX, which is normally installed as part of the install (and still
is on Windows 7), isn't set. Has anyone noticed this?
--
View this message in context:
When installing the MySQL Installer MSI (it's an MSI that's trying to be a
bootstrapper, but that's not the big problem at the moment with it). I'm
getting the following errors:
Failed authenticode verification of payload:
C:\Users\Nicholas\AppData\Local\Package
Well then that is weird then because when I look at the Digital Signatures
tab of the MSI, it says it's been signed by Oracle America, Inc. and that
This digital signature is OK. Maybe Windows 8.1 has a different way of
seeing things. Or maybe it couldn't find its certificate chain. But I guess
Ah, I found it and it was a simple solution. I was missing the Win64
attribute on RegistrySearch, since the value is stored in the 64-bit part of
the registry.
--
View this message in context:
I am seeing the same behavior as reported in bug 4231
(http://wixtoolset.org/issues/4231/), using WiX 3.8. The Root element of
RegistrySearch is ignored. I have:
Chain
ExePackage Id=SQLSERVER_EXPRESS
SourceFile=en_sql_server_2014_express_x64.exe
The util:FileSharePermission element has many attributes for setting ACLs on
a file share, but none of them seem to work except for GenericAll. For
example, the following code will not give the user the specified
permissions:
Component Id=cmpFileShare Guid={6974184A-1F4F-4FBB-ADA6-826E9C947A7C}
Okay, I was wrong! I guess by setting only Read permission on the folder
(using Read, GenericRead, and ReadPermission -- not sure yet which one is
the magic one), the user is able to read the files in that folder and cannot
change/modify them. I guess it works even though the checkboxes for Read
The original version was 6.0.0.0 and the new one was 6.0.0.1
Sent with AquaMail for Android
http://www.aqua-mail.com
On July 7, 2014 11:13:07 AM John Cooper jocoo...@jackhenry.com wrote:
Well, the log indicates that Burn is uninstalling. What are the version
numbers for the initial and
This .wxl file is an oddball, being the only one that I see that uses these
UI elements to resize controls from a localization file. Bob Arnson wrote a
blog about it here:
http://www.joyofsetup.com/2012/07/14/localizing-more-than-strings-in-wix-v3-6/
And the bug that led to adding the UI
I don't understand. The $(var.MyProject.TargetMachine) is only used while
compiling the installer and not while using the installer. After compiling
the solution you should get one MSI file. You only need to deploy the MSI
file to the machine where you want to install.
--
View this message in
Can you show what markup you're using now? That would make it easier to
troubleshoot.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Permission-PermissionEx-Append-tp7594590p7594613.html
Sent from the wix-users mailing list archive at Nabble.com.
As far as I know, a transform file is a file used during the patch-making
process, but can't be used directly to perform a transform. It needs to be
joined with a patch file. The patch file has the knowledge of what the
transform applies to. Without it, I don't think Windows would know what to
do
Is it getting hung up on something? When you uninstall with logging, does the
log show anything happening that takes a long time around where it calls
RemoveFiles?
--
View this message in context:
For code suggestions, you can post to the wix-devs mailing list.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Testing-Wix-FirewallException-element-logging-question-tp7594455p7594616.html
Sent from the wix-users mailing list archive at
Upgrades are used to find and replace previously installed files. But if
there's nothing to replace, there's nothing to say the install can't
continue as a fresh install. If you need to not run the installer at all if
a previous install isn't there then try using a launch condition
Sorry, but I'm going to ask a few followup questions:
1. Does your custom action alter the user's computer at all?
2. I see the name NewServerInstance. Is this by any chance creating a
website in IIS?
3. Is it necessary to create a custom table over using properties?
--
View this message
You can use a VolumeSelectCombo UI control.
Control Id=myVolumeSelectCombo
Type=VolumeSelectCombo
Property=TARGETDIR
Fixed=yes
X=10
Y=10
Width=100
Height=17
Publish Property=quot;INSTALLLOCATIONquot;
This is just a guess: when you referenced one component, you created a link
between the fragment and the main project. Now the linker will yell at you
if it finds anything orphaned in that fragment. On the other hand, when you
didn't link anything from the fragment to the project, the linker
So the components in FeatureC can be installed as a standalone feature, but
those same components are needed by Features A and B?
I'd just include the components in all three features. And don't nest
Feature C inside Feature A or B.
--
View this message in context:
Is your installer installing at least one thing, such as a dummy text file?
The install won't run otherwise.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Noob-creating-a-Custom-Action-in-Wix-3-8-tp7593140p7593249.html
Sent from the wix-users
The ComponentGroup element's Directory attribute sets where to install the
components that are in that ComponentGroup. You can also set this on each
Component element via the Component's Directory element. Also, many of the
Windows directories are already defined for you by the WiX framework, so
You've set Win64=Yes on your components, thus marking it as a file that
targets 64-bit architecture. You wouldn't install such a thing into the x86
Program Files Folder, since that folder is for 32-bit architecture files. Is
your file truly compiled for x64? And if so, should it be?
--
View
Did you add an xmlns attribute on the Wix element to reference your
extension's namespace?
Is the XSD embedded inside the extension assembly? You can use ILDASM or
ILSPY to check.
--
View this message in context:
Heat generates the IDs based off the name of the file. In FileHarvester.cs,
it has:
if (this.setUniqueIdentifiers)
{
file.Id = this.Core.GenerateIdentifier(FilePrefix,
(this.suppressRootDirectory) ? directoryRef.Id : directory.Id,
Path.GetFileName(file.Source));
component.Id
Are you compiling it on the command line and not in Visual Studio? If so,
what's the command line you're using?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Noob-creating-a-Custom-Action-in-Wix-3-8-tp7593140p7593172.html
Sent from the wix-users
Changing ProductCode and Version, but keeping UpgradeCode the same denotes a
major upgrade of the same product.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Running-an-MSI-twice-tp7593163p7593173.html
Sent from the wix-users mailing list
If I'm understanding correctly, you're referring to that you see Visual
Studio calling candle and light when it compiles your WiX setup project?
At that time, it's calling those tools on your setup project, but your
custom extension project has already been compiled. By adding a reference to
it
Welcome! New user of Burn. Eh, I'm not sure that there's a command line that
you can use to bundle everything up. But the markup for Burn can be written
pretty quickly. So I guess it's more in line with how installer in WiX work
-- it's XML based instead of command-line based.
If you post the
I think that's how it work unless you update the Version attribute on the
Bundle element and also the Version attribute on the Product element in the
MSI.
--
View this message in context:
You'll need to create all the dialogs you need, and then show them
dyanmically. You can put the logic for which to show in the Next button of
your dialog (using the NewDialog event with conditional logic). This logic
can evaluate properties that you've set with a radio button.
--
View this
Eh, you don't have to copy it there. For me, I just don't like Browse-ing
very far. So I put it somewhere I want. You can browse to wherever you would
like to store your assembly.
--
View this message in context:
Hmm, I don't recall having to do anything special in the custom bootstrapper
to handle what gets displayed in Add/Remove Programs. I mean, you have to
implement handlers for the Detec, Plan, Apply events...but if you're
successfully installing and uninstalling you must be doing that. I think the
It's a WiX thing, but a good thing. By adding a reference to the build DLL,
you get the following added in the setup project's wixproj file:
ItemGroup
WixExtension Include=AwesomeExtension
HintPathAwesomeExtension.dll/HintPath
NameAwesomeExtension/Name
/WixExtension
Doesn't appear to be detecting your previous install:
[186C:1C04][2014-03-07T14:57:34]i101: Detected package: MyApplication1,
state: Absent, cached: None
[186C:1C04][2014-03-07T14:57:34]i101: Detected package: MyApplication2,
state: Absent, cached: None
It says that its current state is
Maybe try adding another if statement where you detect a package with
PackageId of MyApplication1
--
View this message in context:
Ah, I was reading your code wrong. I was seeing an == when you have a != when
checking the .NET Framework Package ID. Well, in any case, it's clearly not
detecting your previous install. I'm not too sure what that could be other
than that the UpgradeCode on the bundle needs to stay the same. Are
1 - 100 of 434 matches
Mail list logo