There is a whole new build system in WiX v3.7 so lots changed. Can you file
a bug on this and I'll try to figure out which setting created the problem.
On Mon, Nov 26, 2012 at 7:20 PM, Bruce Cran br...@cran.org.uk wrote:
Something seems to have changed with the way wcautil.lib and dutil.lib
Upgrade bundle runs uninstall of the old bundle to remove it. The log files
should explain what is going on.
On Mon, Nov 26, 2012 at 11:31 PM, Neil Sleightholm n...@x2systems.comwrote:
Can anyone help with this?
-Original Message-
From: Neil Sleightholm [mailto:n...@x2systems.com]
Hello All,
I have the requirement of giving SQLExpress (logged on user)
Read/Write access to a directory inside my installation directory.
The user I'm talking about appears in the SQL Configuration
manager.
More ideally I should be able to find
Fix was a bit more simple than that but the same in the end. smile/
On Sun, Nov 25, 2012 at 5:23 AM, Neil Sleightholm n...@x2systems.comwrote:
Unfortunately verbose logging on its own is not enough, to get a property
dump you also need to set INSTALLLOGMODE_PROPERTYDUMP. So effectively burn
The wixstdba doesn't do anything like that but a custom BA could.
On Thu, Nov 22, 2012 at 4:50 AM, Gonçalo Lopes goncaloclo...@gmail.comwrote:
Hi everyone,
I've been trying out WiX with great success so far, but now I'm stuck in a
specific issue using Burn bootstrapper. I'm using
This is probably a bug in the wixstdba code.
On Fri, Nov 23, 2012 at 4:28 AM, Nicholas Pierce
nicholas.pie...@permasense.com wrote:
Hi,
I have written a ManagedBootstrapperApplication that requires .net 4.0.
On Windows 2003 and XP, this requires the Windows Imaging Component, so
I've
I have checked the logs and don't really understand why it is doing what it is
doing: first it runs the new install, and then it uninstalls the cached version.
Why is this second step required? Shouldn't running the install do the remove
of the existing package? If I was doing this without burn
Yes - I never thought to look what the MSP package did, it had exactly the
correct code! Thanks for turning this around so quickly.
-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com]
Sent: 27 November 2012 08:07
To: General discussion for Windows Installer XML
Hi
We have got the same effect in our installation package.
One of our dialogs contains a radio button group control and below it, some
controls,
one of them is an edit control for password entries.
Control Id=ServiceAccountSelection Type=RadioButtonGroup X=20 Y=55
Width=100 Height=60
The old bundle has to be uninstalled to remove it's registration and cache
information. This is basically the same thing the Windows Installer does
when you schedule RemoveExistingProducts after InstallFinalize. Burn today
does not allow you to schedule the remove existing bundles, it's always
Helps when we're in RC for WiX v3.7 and looking to close bugs. smile/
On Tue, Nov 27, 2012 at 12:23 AM, Neil Sleightholm n...@x2systems.comwrote:
Yes - I never thought to look what the MSP package did, it had exactly the
correct code! Thanks for turning this around so quickly.
-Original
Ok thanks, so if my install is upgrading correctly the uninstall wouldn't
happen? I have RemoveExistingProducts scheduled after InstallValidate if that
matters.
That gives me something to investigate, I thought my install did upgrade
correctly but I'll investigate further.
Neil
Hi
When I install a new version of my project it includes a ServiceInstall and
ServiceControl element. How can I make sure the service status and account
details are unchanged during an upgrade? I assume I need to somehow place
the ServiceInstall and ServiceControl elements in a conditional block
Hi,
I have an MSI and a bundle (standard off-the-shelf), which chains SQL CE and my
MSI at the end. So far so good, but on few upgrades, we see that the previous
version stays in ARP alongside the new version. This doesn't happen all the
time, so it is real pain to reproduce. The last time it
I have discovered something but not a solution. I have 3 MSIs in my bundle, 2
work ok but the third doesn't. All are set to RemoveExistingProducts after
InstallValidate (although I have also tried InstallExecute) and also
AllowSameVersionUpgrades=yes.
In the burn log for the first phase of the
Thanks Neil, I suspected as much. In this instance the message isn't vital so
I'll just do without it. (I dare say it would be useful to others - probably
including me in the future.)
Kevin
-Original Message-
Date: Mon, 26 Nov 2012 14:55:13 +
From: Neil Sleightholm
My team has decided to add only the top-level project reference to the WiX
project in each solution. We typically have simple builds where each solution
has one WiX project that builds a single MSI. So if we have a service
solution, we will be adding a single project reference to our WiX
I don't fully understand what you're describing but one difference from our
set-up is that we have the Wix projects each in their own solution. The MSIs
take a long time to build and most C# (C++, etc.) developers don't want to
build them when they press build solution during development, nor do
Rob Mensching-7 wrote
2. Bundles are registered in ARP (aka: Program and Features, aka:
theUninstallKey). That's how you can click on the Uninstall button in
ARPand Burn launches to remove the bundle. You can search for it that way
ifyou want.
Forgive me If I am missing something, but I would
I think I understand what you are describing. I think we have a similar setup.
We have a lot of solutions that follow this pattern (please let me know if this
does not accurately describe what you are trying to describe):
The solution has one or more assembly projects, each with many file
Peter Shirtcliffe wrote
If you look on a machine where the bundle is installed, you will find
anentry for the bundle in the Uninstall registry key. It can be
distinguishedby the presence of several values called Bundle... There is
anuninstallString value under that key that you could use for
I meant Surely the answer cannot be...
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/WiX-Bootstrapper-Bundle-creating-uninstall-shortcut-in-program-files-tp7580364p7582122.html
Sent from the wix-users mailing list archive at Nabble.com.
On 27/11/2012 17:18, rpriest12 wrote:
I am in the same boat - I need the product code. there seem to be several
questions about this for various reasons. Surely the answer can be to troll
the uninstall registry key looking for Bundle*? What if you have multiple
applications that installed
Hello all,
Quick question: If we have a product installed for a client, using the pre-burn
(WiX 3.5) installer, and we give the client
a newer product version installer, but built with 3.6, using Burn,
a) Will the product upgrade as expected?
b) If (a) is Yes, it will upgrade, then what if we
Thanks for the reply Bruce,
Match on BundleUpgradeCode... I guess as a workaround that could work. You are
still left to iterate over all the product code keys under the uninstall key
looking for one that contains the BundleUpgradeCode you seek. Inefficient, but
it seems I have no other
Hi
I would like to know if it's worth migrating all the UI to the bootstrapper?
Also, is it worth starting the software exe from the MSI, or from the
bootstrapper?
I am trying to understand where should be placed things, I mean, I
wonder should I put this action in a custom wixstdba or should
For our installs (about 200 Assemblies in about 15 installers spread through 8
solutions); I manage the contents manually, using project references and inside
the WiX, I have a component for each binary file that represents the Assembly
and its .PDB file. It took a little work getting it
During uninstallation, using a custom action, I'd like to check if certain
conditions apply popping up a windows dialog. Only if user clicks OK,
uninstallation may proceed. But, if the user cancels, we want to cancel the
uninstallation.
Now, when user clicks cancel, basically the custom action
I need to upgrade a package which was unfortunately created with
per-user scope. It's installing to ProgramFiles. I understand that MSI
can't upgrade my perUser to perMachine.
I have some ideas:
1. Automatically uninstall the per-user package (custom action?)
2. Install the per-machine package
On Burn's Install page pressing Alt-C (Close) and then selecting no on the are
you sure you want to cancel pop-up leaves the hot keys dead until you hit tab
or do some other activity first. Pressing Alt-O (Options) does not.
One other side effect I've seen is if the Logo is the width of the
Hi,
I'm using the next package to download and install .Net 3.5SP1 on my machine:
ExePackage Id=Netfx35Web
Compressed=no
Permanent=yes
Vital=yes
Name=redist\dotnetfx35.exe
Remember that PowerShell 3 can call batch files as well; my preference since
batch technology is so outdated.
-Original Message-
From: Neil Sleightholm [mailto:n...@x2systems.com]
Sent: Friday, November 23, 2012 10:47 AM
To: Sudripta Nandy; General discussion for Windows Installer XML
What does the plan say?
On Tue, Nov 27, 2012 at 4:28 AM, Neil Sleightholm n...@x2systems.comwrote:
I have discovered something but not a solution. I have 3 MSIs in my
bundle, 2 work ok but the third doesn't. All are set to
RemoveExistingProducts after InstallValidate (although I have also
1. Sounds right.
2. Seems like if you reboot, the bundle will finish whatever the last
operation was. If it was uninstall, the bundle will uninstall.
3. No, a reboot is required. After the reboot the bundle will end up in the
correct state.
On Tue, Nov 27, 2012 at 3:56 AM, Philip Patrick
You should be fine as long as you do a major upgrade.
On Tue, Nov 27, 2012 at 9:32 AM, Stelios Kyprou stelios.kyp...@fcg.imwrote:
Hello all,
Quick question: If we have a product installed for a client, using the
pre-burn (WiX 3.5) installer, and we give the client
a newer product version
Hello all,
I'm just wondering this since I have a program that installs to app data by
default rather than program files, and it's developer says that the change of
default directory has to do with special permissions needed. I mean, what is
the point of the app data folder anyway? I'd never
You cannot control the BundleId. A new one is generated every time.
Instead, try looking for the Bundle by a related bundle id such as your
Bundle/@UpgradeCode. That is how Burn finds things.
Note: These are implementation details and could change in future versions.
On Tue, Nov 27, 2012 at
Thanks, Rob. We tried to reboot after we saw 2 entries - it didn't remove the
old entry. Currently I instructed QA to follow the MSI's request to reboot the
machine (they do not always follow it) so when it is upgraded to next version,
the previous will be removed correctly.
-Original
Well, not sure ours was the best solution, but what we did is a custom action
that literally moves all registry entries related to per-user package to
per-machine. That means from
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\SID-OF-USER
to UserData\S-1-5-18 (latter stores
39 matches
Mail list logo
