MSI doesn't write to RunOnce because it is a system service that came
installed in the operating system. Pretty much all bootstrappers/chainers
will write to RunOnce if they need to do a reboot and come back
afterwards. Burn goes one step further to ensure robustness and registers
up front.
From: r...@robmensching.com
We'll need to teach this anti-virus program about Burn. Fortunately big
programs, like Visual Studio, are using Burn and if it kills them I hope we
can muster some change.
So are you saying we need to raise this as an issue with Trend Micro? Is the
program that
To sign the bundle and bundle engine you need to add the following to your
.wixproj:
Add SignOutputtrue/SignOutput to a PropertyGroup
Implement the targets like this:
Target Name=SignBundleEngine
SignFile TimestampUrl=... CertificateThumbprint=...
SigningTarget=@(SignBundleEngine) /
When examining the files with an administrative install, the files in the two
.msi files are definitely different.
When I change the file size of the text file, the file is included in the
patch. But if the file size is the same as the file size of the original file,
it isn't included into the
On 01/12/2012 09:46 AM, Peter Hull wrote:
From: r...@robmensching.com
We'll need to teach this anti-virus program about Burn. Fortunately big
programs, like Visual Studio, are using Burn and if it kills them I hope we
can muster some change.
So are you saying we need to raise this as an issue
Can you verify this by producing a minimum test case ? Create an MSI with
just 1 text file and an upgrade and a patch from that. It might help you
narrow down what's going wrong.
The .wixmst produced by torch is an xml file containing all the changes
between the two inputs, even if they are not
Examining the .wixmst confirms my suspicion: If the file size has changed, the
file is marked as modified in the .wixmst, else the file has no such markup.
-Ursprüngliche Nachricht-
Von: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com]
Gesendet: Donnerstag, 12. Januar 2012 10:51
An:
1. There are a couple of ways that might work for you. It depends if you have
to stick with your current upgrade strategy or if you have an opportunity to
alter it.
Firstly, most people find that producing major upgrade MSIs is by far the
easiest way to support upgrades. You cant apply these out
See this thread
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Extract-Binarie
s-at-Install-Time-td2301189.html#a2314132
-Original Message-
From: Naim Kingston [mailto:naim.kings...@ancamotion.com]
Sent: 12 January 2012 05:35
To: wix-users@lists.sourceforge.net
Subject:
From: r...@robmensching.com
Date: Wed, 11 Jan 2012 07:55:13 -0800
That looks right. Please file a bug if the command-line help wasn't
helpful.
OK, bug 3472564. I've also attached a patch to the bug report - hopefully you
can use it as a starting
Hi,
I haven't started using burn yet - but I'd like to - and signing will be an
issue for us. At the moment, I hand an unsigned MSI over to the release manager
for signing. He is the only person with access to the certificate. Can we still
do this with burn? From what I've seen of this
Hi,
I'm trying to find/replace text in an installed file without resorting to
vbscript. It's not an XML or INI file. I've tried the TemplateFile action
from the AppSecIn extensions on CodePlex, but it does not work in the way
that I want.
Does anybody have a C++ custom action dll for this they
I would start by digitally signing your burn bundle. Most anti-virus
software provides more leeway to signed executables. If your bundle is
static, then you could also submit it to Trend Micro as a false
positive. Most AV vendors will update their signatures to work around
false positives in a
On 10-Jan-12 17:48, John Cooper wrote:
Test NVPPTb.SetEditNetTcpBinding.Header failed with unknown operation.
That's bad. But thanks for the repro! Can you file a bug on SF?
--
sig://boB
http://joyofsetup.com/
--
On 12-Jan-12 05:47, Nick Ball wrote:
I haven't started using burn yet - but I'd like to - and signing will be an
issue for us. At the moment, I hand an unsigned MSI over to the release
manager for signing. He is the only person with access to the certificate.
Can we still do this with burn?
I see that it's set in the Designer as Output Name which is a MSBuild
Property. Is there any way (other than having the build edit the .wixproj or
copy/rename after the it's generated) to change the output MSI?
Thanks
Daniel P. Sniderman| Sr Consultant| Magenic
MCSD.NET, MCTS: Team Foundation
On 11-Jan-12 03:00, Ulrich Proeller wrote:
The switch -sf in the pyro command was added the get rid of a duplicate key
error.
That's likely the root cause of your problem. Fix the underlying bug
before trying workarounds.
--
sig://boB
http://joyofsetup.com/
Sure. I'll get on it right after lunch.
--
John M. Cooper
-Original Message-
From: Bob Arnson [mailto:b...@joyofsetup.com]
Sent: Thursday, January 12, 2012 8:39 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Possible bug in Lux
On 10-Jan-12 17:48, John Cooper wrote:
Bug is 3473007.
--
John M. Cooper
-Original Message-
From: John Cooper
Sent: Thursday, January 12, 2012 11:43 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Possible bug in Lux
Sure. I'll get on it right after lunch.
--
John M. Cooper
How do you want to generate your name? This will determine how we change
OutputName.
OutputName is just a MSBuild property but one that is used by all project
types. I believe (but have not verified) that if you build your solution from
the command line providing a different value for
The name would probably include the Configuration and version information .
However this would be part of a TFS 2010 Build - so passing an argument to
MSBuild is supported. Thanks - this is very helpful.
-Original Message-
From: Castro, Edwin G. (Hillsboro)
On Thu, Jan 12, 2012 at 6:03 PM, Hoover, Jacob
jacob.hoo...@greenheck.comwrote:
I would start by digitally signing your burn bundle.
The bundle is already signed with a Thawte code signing certificate
Most anti-virus
software provides more leeway to signed executables. If your bundle is
Hey All,
Is it possible to copy an .msi or .exe from within the bundle to the
install location?
I have a product included in my installer that I'd like to copy to the
install location in case the user wishes to run that installer manually
later.
TIA,
--
*Jammer*
http://www.jammer.biz**
I have been working on a new install where a context menu is added to the
Right-Click Menu within Internet Explorer.
Everything I have read regarding this requires the key be added to
HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer. This does work but the
issue I have is that our
The Registry element has a Root attribute that you can set to HKCU. If
your program has an advertised shortcut you can use this to trigger
resilency to complete the installation for each user who uses your app.
It's an ugly story though like the old Office install that popped up every
time
Or try applying the key to HKLM rather than HKCU in the first place. Many
Windows settings can apply to either key to give you the flexibility of
having each setting system-wide or per-user.
On Thu, Jan 12, 2012 at 9:34 PM, Christopher Painter chr...@iswix.comwrote:
The Registry element has
Then there's the case of Office AddIns that allowed either HKCU or HKLM in
2003, took away in 2007 ( and put it back with a hotfix and enabling
registry value ) and really put it back in 2010 leaving one hell of a mess
for us installer guys to deal with.
So, yes, YMMV... in the event it
Wix MSI newbie here.
My product requires JDK 1.6 installation, and I'm trying to come up with
Wix code to verify the system has JDK 1.5 installed before proceeding
installation of my product.
I thought this would work:
Property Id=JDKVER
RegistrySearch Id=NetFramework20
My memory of the way Java stores there version information in the registry
isn't very friendly to MSI's RegLocator pattern. You might need a custom
action.
From: T. Kuro Kurosaka k...@basistech.com
Sent: Thursday, January 12, 2012 6:21 PM
To:
I'm getting a strange bug where if I run a bootstrapper created with burn from
an administrator command line prompt AND specify a log file, then the
bootstrapper will hang before even opening up the UI.
It's strange, running without a log file works fine from the administrator
command line
Signing only the bundle would prove that it came from your organisation and
hadn't been tampered with - would that be enough?
When run it would unpack the unsigned burn engine and the unsigned MSIs. Does
anyone know if that would show the user a warning (or multiple warnings?)
Bob: would it be
Date: Thu, 12 Jan 2012 20:56:15 +0100
From: n...@panorama9.com
I would start by digitally signing your burn bundle.
The bundle is already signed with a Thawte code signing certificate
The reported file name looks more like it's the extracted engine than your
bundle itself. Have you signed
Hi folks,
as I read in the WiX 3.6 Beta release notes, burn does support package
ref-counting now, which according to my understanding should guarantee, that
shared packages are uninstalled only if all bundles sharing the packages
were removed.
Here is a little example:
- install
33 matches
Mail list logo
