2014-10-03 12:04 GMT-03:00 vorsichtdiekurve :
> No, they are being uninstalled using the managed bootstrapper GUI. I have
> options to modify the installed packages (which simply installs/uninstalls
> depending on what the client desires) or uninstall (which is done by setting
> in code that all pa
I have some folders with localized html documentation, each folder contains
many files, and they are not vital for my application, I harvest the folder
using heat to build the wxs and then the msi.The installation of these folders
is very very slow as heat doesn't order the files based on direct
Hi,
This is the first time I am working to create the patch. From the WIX
documentation I am able to create the first patch without any difficulty but
doing the second patch is giving me a hard time. I am using the original RTM of
our application for the base of our patch and I am trying to do
I know it is true for external MSI's that you'd need to set Cache=Yes (It
should default to yes so if it isn't then that sounds like a bug) on the
MsiPackage in the bundle to have it cache it in the WiX PackageCache. I haven't
confirmed it yet, but I would assume the same for embedded files as w
The MSI doesn't get installed from inside the exe, Windows Installer
doesn't know how to do that, so it's first unpacked into some
location. The bootstrapper logging should tell you where that is.
---
Phil Wilson
On Mon, Oct 20, 2014 at 9:33 AM, Hoover, Jacob
wrote:
> Sorry, forgot t
Sorry, forgot to post a reference.
http://blogs.msdn.com/b/heaths/archive/2009/02/02/changes-to-package-caching-in-windows-installer-5-0.aspx
-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: Monday, October 20, 2014 11:30 AM
To: General discussion about t
>From what I remember, Windows Installer caches the entire MSI to preserve the
>digital signature, however it doesn't consider the version it caches as a
>valid source for files. So if it needs a file to repair it will still prompt
>for source (and is also a reason to always use external CAB's).
I thought that had changed at one point and the windows installer cached the
full msi. Not looked into it for ages.
-Original Message-
From: John Cooper [mailto:jocoo...@jackhenry.com]
Sent: 20 October 2014 15:04
To: General discussion about the WiX toolset.
Subject: Re: [WiX-users] Repo
As I recall, the copy in the Installer folder is dehydrated (stripped of
content). For Repair/Patch to work without the dreaded missing source dialog
appearing, the MSI needs to be either: 1) cached, or 2) in the same location
it was when the install was performed.
--
John Merryweather Cooper
Thank you. Maybe this is a different topic, but what is a pseudobundle and a
passthrough, as in Command.Passthrough object? pseudobundle.cpp talks about
passing the command line to a passthrough bundle.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble
If the msi is installed it is usually stored in the c:\windows\installer folder
and that would be used for autoheal repair.
I understand that burn caches packages in case this is not true anymore.
-Original Message-
From: Farrukhw [mailto:farru...@gmail.com]
Sent: 20 October 2014 13:34
Hey!
I have a bundle project with 2 internal MSI packages (in a chain).
Both of my MSI packages support downgrade, buy when I try to downgrade the wix
bundle containing them, I get the following:
Error 0x80070666: Cannot install a product when a newer version is installed.
I really need to support
Hi,
Reposting with a hope that someone may be able to give some guidance, as
last time it was left abandoned:
I've developed a Managed Bootstrapper and now near to release the product.
Normally, if a KeyPath file is removed/modified, Windows Installer would try
to restore/repair that. But in ca
13 matches
Mail list logo
