Hi,
I've just posted the following comment to Rob's blog.
--
Hi all,
the first thing I do with an MSI log is to open with the Microsoft tool
Windows Installer Verbose Log Analyzer (WiLogUtl.exe).
One Problem is that WiLogUtl.exe support only MSI logs up to MSI version
3.0.0.0.
So if I
burn supports a Burn bundle inside a Burn bundle. netfx supports netfx
4+. SQL Server doesn't expose a protocol today, IIRC.
Maybe they can move to Burn? :)
On Wed, Jan 25, 2012 at 8:56 PM, Romeo S. dfox.mxyzp...@gmail.com wrote:
Hi,
I'm just curious what can burn and netfx protocols
Too much work. :)
On Thu, Jan 26, 2012 at 12:05 AM, thomas.debo...@rohde-schwarz.com wrote:
Hi,
I've just posted the following comment to Rob's blog.
--
Hi all,
the first thing I do with an MSI log is to open with the Microsoft tool
Windows Installer Verbose Log Analyzer
Blair,
While I never knew you were doing it at the time, thank you soo much for
your efforts on this sneakly little critter of a bug. DTF has a special
place in my heart ( I'm sure you saw all my blog posts over the years
evangelizing the need for managed code custom actions ) and your
I'm creating a patch, I'm not sure that the patch includes all of my
files even though I'm passing the -p flag to the torch.exe.
Can someone please explain to me the logic that torch uses to determine
what files are included in the patch.
Thanks.
I know that a bug currently exists when using burn that it errors rather
than asking for elevated rights. I thought that then I could add a
condition to prevent setup running is the user is not an admin or if they
have not selected Run as admin. My attempt follows but I never seem to be
able to
Hello Peter,
Thank you for responding to my email. I applied the patch install again on a
much faster machine and it still took a long time to finish. The step that took
the most time was Validating install. It took 13 minutes out of the total 17
minutes, as recorded in the install log shown
If I build a use msbuild to create the bootstrapper I just end up with an
executable again. Isn't there someway to build the bootstrapper as an MSI and
the other MSIs are run as subprocesses under the main MSI?
- Original Message -
From: Bob Arnson
Sent: 01/25/12 08:37 PM
To:
Is the Privileged property even defined for non-privileged installers?
Generally, you're testing for set if the user is privileged and cleared when
the user is not. So, maybe you're looking for NOT Privileged.
--
John Merryweather Cooper
Build Install Engineer - ESA
Jack Henry Associates,
In that case I'd actually want the test to pass if the user was privileged.
But if I use:
bal:Condition Message=You must be an administrator to install this
application
Privileged
/bal:Condition
The install errors regardless of whether I'm an admin with this in the log
Thanks for the advice Dave. We definitely need different flavours of the
product for different customers. I think we will take your advice and produce
different MSIs (one the core product and one for the parts that vary) and chain
them together using an appropriate bootstrapper.
Regards
Hi Miaohsi,
We are currently having a very similar problem where I work. Torch.exe
seems to be detecting all of our .NET assemblies as changed, even though
only a few of them are actually different in source code. Hence, all of the
.NET assemblies are going into the patch, making it is huge and
As a follow up to my last email here, it turns out signing was /not/ the
issue after all. If we compile a .NET assembly twice in a row (same source
code each time) the second DLL is binary-different than the first. Maybe
it's putting a time stamp in there. So I'm guessing Torch is doing a
We recently implemented patch building using Torch/Pyro. We are keeping the
old MSI and totally rebuilding a new one for Torch to diff with. The
problem is that Torch sees all of our .NET assemblies as changed even though
the source code only changed in a few. We did some digging and it turns
Hey,
I am using Wix COMPlus extension to register my complus
application, here is the code:
Component Id=Test.dll Guid=MyGUID Win64=yes DiskId=1
File Id=Test.dll ShortName=TST.dll Source=PATH KeyPath=yes
Class Description=TEST
Class Id=ClassGUID
Hey everyone,
I'm trying to build a bundled installer from several MSIs. I'm using the
branding instructions here:
http://wix.sourceforge.net/manual-wix3/wixstdba_branding.htm. The
resulting logo is appearing very boxish and completely black (i.e. looks
like it's not reading my png). Do I
In my main .wxs file that is based on the WixUI_InstallDir dialog set,
I set WIXUI_EXITDIALOGOPTIONALTEXT so that the final dialog
after successful installation has an extra information.
This is done like this:
Wix xmlns=
Product
...
UIRef Id=WixUI_InstallDir /
Property
Hello all,
Have a Bundle which is installing several MsiPackage(s) which we have set the
MsiProperty Name=ALLUSERS Value=1/ to load the individual packages under
all users, but it isn't installing the Bundle itself under ALLUSERS. I can't
seem to find a setting which allows me to set this. So
Hi there,
I've been seeing this error Failed to cache bundle/Failed to begin
registration session quite a bit recently. I've updated to the newest
build v3.6.2520, is this a known bug or am I doing something wrong?
Below are two separate log files:
*Windows 7*
[1F6C:1E74][2012-01-26T14:49:
53]:
Read up on the Secure attribute to the Property element in the Wix schema.
Only secure properties are visible in both the UI and Execute sequences.
--
John Merryweather Cooper
Build Install Engineer - ESA
Jack Henry Associates, Inc.(r)
Shawnee Mission, KS 66227
Office: 913-341-3434 x791011
My initial guess is that your assembly's versions are changing between builds.
I'm very interested in a proposed approach to this as we have a build that
results in changed versions on every build. I haven't personally investigated
an approach to handle this yet. I haven't had the time yet to
That's a good thought, so I checked and verified that leaving the file's
version number the same between builds still produces different binary
files.
Unless we hear a better suggestion we're going to try this: Each time we
build an assembly we will leave all the intermediate files in place
For future readers, this sentence from my last email looks to be wrong: We
fully-sign our assemblies after they are built, so we might have to make
sure MSBuild is looking at pre-signed copies or it might rebuild them.
I tried fully signing the outputted DLL and did another Build, and MSBuild
did
On 1/26/12 12:13 PM, John Cooper wrote:
Read up on the Secure attribute to the Property element in the Wix schema.
Only secure properties are visible in both the UI and Execute sequences.
I'm not sure if the security is the problem because I am not seeing the
errors like Ignoring disallowed
A bootstrapper needs to be an executable. MSIs cannot launch other MSIs.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Wix-Bootstrapping-Issues-tp7225413p7228980.html
Sent from the wix-users mailing list archive at Nabble.com.
On 26-Jan-12 11:18, Boyd Ludlow wrote:
I know that a bug currently exists when using burn that it errors rather
than asking for elevated rights.
What bug is that?
--
sig://boB
http://joyofsetup.com/
--
Try before you
On 25-Jan-12 21:52, Josh Suereth wrote:
Actually, I caught the pre-processor docs. Replacing every $ with $$
works. I just had to get my regex replacement correct. Sorry for the bum
email.
I think it's still a bug. $ introduces a preprocessor variable reference
but $$ should be necessary
On 26-Jan-12 15:02, DuBois, Joseph wrote:
Have aBundle which is installing severalMsiPackage(s) which we have set
theMsiProperty Name=ALLUSERS Value=1/ to load the individual packages
under all users, but it isn't installing the Bundle itself under ALLUSERS.
If your packages are all per-user
On 26-Jan-12 14:37, T. Kuro Kurosaka wrote:
I thought properties named with all uppercase letters are in
global effect, and passed between the server and the client, back and
forth.
It's one-way only, client to server. There's no way to set a property in
the server and have it available for
29 matches
Mail list logo
