Hello Phil,
Do you have any further inputs on what could be done to resolve this
problem?
Kiran Hegde
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-set-Title-in-Summary-Information-Stream-tp709628p7589515.html
Sent from the wix-users
Hi All,
Wix 64 bit Msi Installer on uninstall does not remove product entry in Program
Features for 64bit Win 7 and Win 8 versions. It leaves a trail of registry
entries @ location. HKCR\Installer\ProductsProduct ID
HKCR\Installer\UpgradeCodesUpgrade Code
Also it doesnot remove .msi file and
OK. Does the easy way to do it involve TFS?
On 08/10/2013 01:03, Blair Murri wrote:
Yes, that can be done. In fact, I did it last month. Someone knowledgeable
with MSBuild would be able to set that up in a short time. In fact, that
other project could build all or any combination of
On 10/8/2013 1:03 AM, Blair Murri wrote:
The rest (of us) buy the book
(http://www.amazon.com/gp/product/0735626286?ie=UTF8tag=sedodream-20linkCode=xm2camp=1789creativeASIN=0735626286)
Note that the link is for the first edition, not the second.
--
Bruce Cran
It should work as long as your package isn't conditioned out. Your SO
question doesn't provide detail about your MsiPackage authoring to answer.
On Mon, Oct 7, 2013 at 4:39 PM, Dave Andersen d.ander...@gmail.com wrote:
I posted this question on Stack Overflow, but it hasn't gotten any
Add and populate the PatchMetadata element to your authoring.
Date: Mon, 7 Oct 2013 23:35:47 -0700
From: kirann.he...@gmail.com
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] How to set Title in Summary Information Stream
Hello Phil,
Do you have any further inputs on what
Sorry, I grabbed the link from the author's website. I didn't search deeply for
the latest edition (despite the fact that the edition I own is the second).
Date: Tue, 8 Oct 2013 14:08:45 +0100
From: br...@cran.org.uk
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Howto
What does the verbose log say?
From: akanba...@avaya.com
To: wix-users@lists.sourceforge.net
Date: Tue, 8 Oct 2013 07:53:36 +
Subject: [WiX-users] Wix 64bit Msi Installer on uninstall does not remove
product entry in Program
Hi All,
Wix 64 bit Msi Installer on uninstall does not
PackageGroup Id=p1
MsiPackage Id=p1
Cache=yes
Compressed=yes
Any way if user delete the folder in which it was cached
you will see the resolve source msi Ui if you dont provide it in a custom
MBA
excactly what i trying to do now ...:)
you
Ok,all looks good.all work for now...one issue left is out of order
uninstalation
can you please elaborate on:
OnPlanTargetMsiPackage are used to allow you to gather and control if any
given MSP will be added/removed from any given MSI,
Assuming I install Patch 1, 2, 3
How can i prevent
1. I have Setup.msi file
2. In the same location(where my Setup.msi is), i have two more files
'launch.exe', 'set.ini' files
How to get the current directory of msi is running from?
and then
a) trigger 'launch.exe' file
b) use 'set.ini' file?
Note: 'launch.exe', 'set.ini' files were not packaged
How can you be sure launch.exe and set.ini will be there?
Why not bundle them with the MSI using burn?
(http://wixtoolset.org/documentation/manual/v3/bundle/)
Alain
-Original Message-
From: ak m [mailto:wixak...@gmail.com]
Sent: Tuesday, October 8, 2013 12:14
To: General discussion
2013/10/8 ak m wixak...@gmail.com:
1. I have Setup.msi file
2. In the same location(where my Setup.msi is), i have two more files
'launch.exe', 'set.ini' files
How to get the current directory of msi is running from?
and then
a) trigger 'launch.exe' file
b) use 'set.ini' file?
Note:
Also, from those filenames it seems that you may be installing another
setup. If that is the case then:
1. If it's MSI-based there are restrictions when launching it from within
your MSI install, and a custom action that may seem like an obvious
solution won't always work.
2. Burn might be the
You may have something in your setup that MSI cannot cost
correctly. Sometimes custom actions and self-registration can cause this.
For example the progress bar won't increment correctly during long-running
custom actions unless you explicitly added code to make it do that.
The ReserveCost
Hi guys,
I am trying to install 1 file to 2 different locations by using 2 different
directory elements, 2 different component elements and 2 different file
elements.
Before I do this I have a custom action that copies the
powershell.exe.config to powershell.exe.config.bak (I try both the
2013/10/8 StevenOgilvie sogil...@msn.com:
Hi guys,
I am trying to install 1 file to 2 different locations by using 2 different
directory elements, 2 different component elements and 2 different file
elements.
Before I do this I have a custom action that copies the
powershell.exe.config to
Solved it...
I created a customaction to populate a property with the powershell folder
CustomAction Id=CA_Set_PowerShellx86_Path Directory=POWERSHELLX86_DIR
Value=[POWERSHELLPATH_X86]/
CustomAction Id=CA_Set_PowerShellx64_Path Directory=POWERSHELLX64_DIR
Value=[POWERSHELLPATH_X64]/
I use
Or install to a common location this file, and utilize the CopyFile element to
stick it in the destination based on bitness. I'm not 100% certain, but is it
not possible to have both X86 and X64 versions of powershell on the same system?
-Original Message-
From: Steven Ogilvie
Solved it...
I created a customaction to populate a property with the powershell folder
CustomAction Id=CA_Set_PowerShellx86_Path Directory=POWERSHELLX86_DIR
Value=[POWERSHELLPATH_X86]/
CustomAction Id=CA_Set_PowerShellx64_Path
Directory=POWERSHELLX64_DIR Value=[POWERSHELLPATH_X64]/
I use
It is. On my Server 2012 install, that is exactly how Windows place PowerShell
3.0. I have both x86 and x64 versions installed.
--
John Merryweather Cooper
Build Install Engineer -- ESA
Jack Henry Associates, Inc.(r)
Shawnee Mission, KS 66227
Office: 913-341-3434 x791011
Well it compiles now but won't overwrite the file :(
How do I force a file to be overwritten when it is a system file...
I am adding .net 2.0 and 4.0 to the powershell.exe.config file so I can run a
powershell script that requires .NET 4.0 (i.e. on Windows 2008R2 server)
Steve
-Original
The more I think about this the more I think the right way is to try to
modify the existing file (if it exists) using XmlFile/XmlConfig. If the file
doesn't exist, I would want to create an empty one and then have the custom
actions run to modify it.
As an end user, I know I would be angry if
The installer is not blowing anything away...
I have a custom action that first backs up any powershell.exe.config to .bak
(both x86/x64) then I try to copy over the modified version over it is set as
perm so it won't remove it
Steve
-Original Message-
From: Hoover, Jacob
Microsoft says: Using PowerShell 2.0 with .NET Framework 4.0 is not
supported. While it is possible to force PowerShell 2.0 to run with
.NET Framework 4.0 using various mechanisms such as creating a config
file for PowerShell or editing the registry, these mechanisms aren't
supported and can have
I've tried using those attributes, but I think I'm actually missing
something in my MBA to actually trigger the Cache action on the package.
I'm controlling installation of the package by setting/unsetting a Variable
in the MBA, which is tied to the InstallCondition of the package; perhaps
that
I have a MBA which I modeled after the Wix installer code. I am trying to
add localization to it. I did a lot of reading on different approaches and
then installed NuGit and WPFLocalizationExtension.
http://wpflocalizeextension.codeplex.com/
I have this implemented like the sample that is at
I am using the WiX Source\Setup\WixBA as a starting point for a custom
managed bootstrapper application.
I am trying to wrap my head around how the UpdateCommand works but I
don't even see the DetectUpdateBegin method get fired.
I see the DetectComplete method get fired but that just goes
Here's what I would do:
In OnDetectTargetMsiPackage gather the productcode and check the installed
state of all of the patches on that product. Store that in memory.
In OnPlanTargetMsiPackage I would prevent an uninstall of patch 2 for the
indicated productcode if detect indicated that patch
Hi,
I just upgraded from WiX 3.5 on VS2010 to WiX 3.7 on VS2012, and I'm
getting this error:
light.exe(0,0): error LGHT0199: The Wix element has no namespace. Please
make the Wix element look like the following: Wix xmlns=
http://schemas.microsoft.com/wix/2006/localization;.
When I search
Hi Experts,
I have a requirement to keep the installer as a single exe instead of msi.
Is there a way other than creating a bootstrapper to get exe. As there is
no other/ additional action required from a bootstrapper.
I am looking of a simple soution like selecting to generate exe instead of
msi
1. I have Setup.msi file
2. In the same location(where my Setup.msi is), i have two more files
'launch.exe', 'set.ini' files
How to get the current directory of msi is running from?
and then
a) trigger 'launch.exe' file
b) use 'set.ini' file?
Note: 'launch.exe', 'set.ini' files were not packaged
That's what I was saying before. Your packages are probably being
conditioned out thus they won't be cached. Burn won't cache stuff that will
never be installed.
On Tue, Oct 8, 2013 at 12:40 PM, Dave Andersen d.ander...@gmail.com wrote:
I've tried using those attributes, but I think I'm
Search the archives. You'll find a bunch of others that have tried the same
plus a bunch of issues to worry about.
On Tue, Oct 8, 2013 at 9:54 PM, ak m wixak...@gmail.com wrote:
1. I have Setup.msi file
2. In the same location(where my Setup.msi is), i have two more files
'launch.exe',
I haven't found any solution in archives.
Anyone Help me on this?
On Wed, Oct 9, 2013 at 10:44 AM, Rob Mensching r...@robmensching.com wrote:
Search the archives. You'll find a bunch of others that have tried the same
plus a bunch of issues to worry about.
On Tue, Oct 8, 2013 at 9:54 PM,
2013/10/9 ak m wixak...@gmail.com:
1. I have Setup.msi file
2. In the same location(where my Setup.msi is), i have two more files
'launch.exe', 'set.ini' files
How to get the current directory of msi is running from?
and then
a) trigger 'launch.exe' file
b) use 'set.ini' file?
Note:
Verbose log does not show any errors, it is showing everything is fine.
This issue is happening when software is installed when its dependency software
is already present(installed) on m/c.
If dependency is removed first and then the software is removed, its trace
remains in Add/Remove Programs,
37 matches
Mail list logo
