It’s like I wrote: Windows Installer will first try to move files it intends on
either replacing or deleting. If that succeeds, then the directory can then be
removed (but only if empty).
Files that cannot be deleted (whether moved or not) are marked for deletion
upon the next reboot if the
Thanks for the clarification, that helps.
On 19-12-2013 14:55, Blair Murri wrote:
It’s like I wrote: Windows Installer will first try to move files it intends
on either replacing or deleting. If that succeeds, then the directory can
then be removed (but only if empty).
Files that cannot
I get the same behavior from builds with both Wix 3,7 and 3.8
The only entry if ARP is for the bundle
Burn bundle 1.0 installs 2 msi packages.
Burn bundle 1.1 has 1 msi upgraded and leaves the other one unchanged. The
bundle is a MajorUpgrade and the upgrade code is unchanged.
I expect to see
Hi Blair,
I just created a new sample just writing two registry keys and a readme file.
Registry key gets written only if the Root is HKCU - if it is HKLM or HKMU
installs fine, but no registry key written.
Please let me know what am I missing here. Thanks in advance.
?xml version=1.0
Well it's not a Win64 component, so it's going to WoW6432 in the registry.
Where were you looking?
Phil Wilson
On Thu, Dec 19, 2013 at 11:47 AM, Shyam Kannam shyam.kan...@hotmail.comwrote:
Hi Blair,
I just created a new sample just writing two registry keys and a readme
file. Registry key
You need to decide the bitness of that package and ideally say something
explicit in the components and in the Package Platform - nothing
is specified, so it's x86 by default. If you want both, you need two
separate MSI files.
Phil Wilson
On Thu, Dec 19, 2013 at 12:10 PM, Phil Wilson
I don't mean to add any confusion to this thread, but I am curious. If
keypath=no in the above code, what is the keypath in this situation?
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Adding-a-registry-key-to-HKLM-tp7591371p7591443.html
Sent
I think the easiest way to use Prism is to pull in the dependency using
NuGet. The command is:
Install-Package Prism
You can download NuGet for Visual Studio 2010. It's an extension to Visual
Studio.
http://visualstudiogallery.msdn.microsoft.com/27077b70-9dad-4c64-adcf-c7cf6bc9970c
I think that
Thank you very much Phil. I'm not aware of WOW6432. Yes, the written key
is present in the WOW6432.
But if in case of HKCU, it is written in the normal path. Not sure why?
I'll try to build the installer in 64 bit and check.
-Original Message-
From: Phil Wilson
You can create a custom bootstrapper application (such as by using WPF) and
have that do just about anything you need. Burn has extension points for
this. Curious, how come the logic needs to live on a website? Did you not
want to base the language off of the user's language settings on their PC?
Hi guys,
I am using 3.7.
I am trying to figure out where in the source I can change the behaviour of
the Image:
Image X=11 Y=11 Width=495 Height=60 ImageFile=Logo.png
Visible=yes/
to make it to back so the Title is in front:
Text X=80 Y=11 Width=-11 Height=64 FontId=1 Visible=yes
I have been trying to get WIX to deal with an ExeCommand which uses INSTALLDIR
which contains spaces in the path without
success.
I won't repeat the bug I opened on this. Here is the link:
http://wixtoolset.org/issues/4257/
As you can see in the bug. I cannot get a cmd.exe to launch one of
On 19-Dec-13 12:16, Wheeler, Blaine (DSHS/DCS) wrote:
I expect to see the bundle install the upgraded msi and to leave the
unchanged package in place. But Burn installs the upgrade and then removes
the unchanged package even through the InstallCondition for package #2
evaluates True
From
On 16-Dec-13 08:44, Graham Harwood wrote:
My question is, what reason does the CA for the firewall not update an
application rule if one already exists?
The quarter came up tails. :) That was the behavior I needed when I
designed the firewall extension. Both behaviors are right. It'd be
14 matches
Mail list logo
