Here are the logs from the exact same test but with the SceduleReboot element
commented out of Package A. This upgrade is successful.
The main difference I see is the dependents check i.e. dependents are
actually found during this successful upgrade (and so A and B are correctly
left alone). Not
Hi
I have an include file:
and it has the following:
I use it in a merge module like this: (I include the include file)
BTW I need the " around the exe pathname or the custom action fails...
it doesn't work, the logfile has this entry:
MSI (s) (7
Hi all - really glad to see 3.6 is out ! We have an MSI with upgrade-related
logic implemented by the MajorUpgrade element: Specifically, we don't want
upgrades or downgrades to occur automatically (the user is prompted to use
Add/Remove Programs instead). Here is an excerpt from Product.wxs :
no worries (sorry for the double post :)
Steve
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Sources-for-WixUI-Mondo-tp7580455p7580460.html
Sent from the wix-users mailing list archive at Nabble.com.
I suppose you could, but I it's the wrong tool for the job.
I think just about everyone here would advise against using a MSI to push
another MSI onto a remote system.
You can get what you want with a batch file, scripting against WMI, and
there's probably something in powershell too.
Can you te
Goto the http://wix.codeplex.com/releases/view/93929 web site and download
the source *wix36-sources.zip*
Once you have it on your machine goto: Wix_Source\src\ext\UIExtension\wixlib
and there is a file called: WixUI_Mondo.wxs
Et viola :)
Steve
--
View this message in context:
http://windo
Thank you. I have missed the obvious. I was looking all over the places for
a source repository.
---
Kind regards,
Dennis Oleksyuk
On Wed, Sep 12, 2012 at 3:05 PM, Steven Ogilvie wrote:
> Goto the http://wix.codeplex.com/releases/view/93929 web site and
> download the source wix36-sources.zip
>
Goto the http://wix.codeplex.com/releases/view/93929 web site and download the
source wix36-sources.zip
Once you have it on your machine goto: Wix_Source\src\ext\UIExtension\wixlib
and there is a file called: WixUI_Mondo.wxs
Et viola :)
Steve
-Original Message-
From: Dennis Oleksyuk [
Where could I get sources for the WixUI_Mondo Dialog Set?
---
Kind regards,
Dennis Oleksyuk
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has change
Thanks for clarifying. We were able to suppress UAC by using
ApplicationRequiresElevation="true". So, it's certainly doable. I'm trying
to find out how to do it in 3.6 as we no longer use the GenerateBootstrapper
task.
--
View this message in context:
http://windows-installer-xml-wix-toolset.68
Sorry, I mean that you use the /quiet switch with the resulting executable
that the build produces, by specifying it at install time. E.g. if your build
produces setup.exe then you run "setup /quiet" when you install it.
You can't prevent UAC warnings with Windows. Only the user can do that by
dis
Some comments below; they may not fix your problem, but point to other
issues in the WXS:
> -Original Message-
> From: Branko Horvat [mailto:branko_hor...@hotmail.com]
> Sent: Wednesday, September 12, 2012 09:27
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] wix ftdi drivers
We use the VS 2010 plug-in, which uses candle and light exes. We don't use
burn.exe per se. So, I'm not sure how I can add the /quiet switch.
Also, for the other question, are you saying that there's no way to work
around the UAC warnings with Burn?
Thanks
Erkan
--
View this message in context
Hi,
I am using WIX 3.6 (release) and VS2010...
I am using burn to chain a bunch of MSI's, one of which is my main install
(the others are pre req check msi's that are not visible)
I want the UI of the main install to be present so the user can see what is
what and select/deselect features etc...
Burn is a container for the MSIs. The MSIs will behave in the same way as
they did before you started using Burn, so yes, the files will be updated.
-Original Message-
From: tyler.w.r...@accenture.com [mailto:tyler.w.r...@accenture.com]
Sent: 12 September 2012 15:33
To: wix-users@lists.so
Hello,
I have some products that we are installing with wix, but now I am
rewriting the installs to be more modular and am using burn to chain them
together. If I use the same upgrade codes will the files installed before burn
get updated when burn does its install?
Tyler Reid | Operat
Hello,
I would
like to install two ftdi (VCP: USB to COM) drivers with WiX, among others app
stuff. I have the last WiX, i.e. v3.6. I’m bugging with it for quite some days.
I’ve read quite a lot of stuff about WiX and about drivers installation. I
haven’t checked both .inf files with ChkINF
Rob,
* [property] Target framework changed to "Microsoft .NET Framework 2.0". -
NOT SOLVED
* [property] Read-only property "dir.hhw" cannot be overwritten. - SOLVED
- by removing "read-only=true" from source code
* [property] Read-only property "hhw-found" cannot be overwritten. - SOLVED
- by
Ok, thanks. I'll keep an eye on your thread.
//Caisa
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-Really-weird-upgrade-problem-tp7580416p7580441.html
Sent from the wix-users mailing list archive at Nabble.com.
---
But I am seeing this VBScript for doing the same, can't I execute this
script in Custom Action to do the same?
On Sat, Sep 8, 2012 at 10:56 PM, Philip Sayers wrote:
> I'm pretty sure you can't do this from inside a MSI.
>
> Wix is about creating the MSI, you're asking about how to apply that MSI
I forgot to point out the scenario for the logs:
- Bundle with 3 packages A, B, C
- Package A Schedules a reboot
- Package A and B are unchanged from initial 1.0.0.0 Bundle
- Package C has been changed from 1.0.0.0 to 1.0.1.0 (upgrade)
- Bundle version has been changed from 1.0.0.0 to 1.0.1.0 (Prod
Ok, did some more testing today:
1. This occurs with wixstdba or my custom ba
2. Upgrade fails (uninstalls all unchanged packages) when first package in
bundle is unchanged and schedules a reboot
3. Upgrade succeeds if first package in bundle is unchanged but does NOT
schedule a reboot
4. Upgrade
This sounds very similar (the same) to the problem I have been struggling
with for a while.
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Bootstrapper-Upgrade-Issue-tt7579392.html
Just did some more testing today, about to update above thread with my
findings.
--
View this messag
23 matches
Mail list logo