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
On 26-Jan-12 15:02, DuBois, Joseph wrote:
> Have a the 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 the bundle will be per-user as well.
Is there a reason you're not putting ALLUSERS in the packages
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 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 yo
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 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 disallow
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
di
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 (.pdb
When I was at SCX (Microsoft), we went so far as to investigate tools to
compare only the "code" parts of an assembly--but in the end, that proved too
cumbersome and unreliable, and so we just lived with the diff's between build.
At ESA-JHA, a significant number of assemblies are checked into so
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 do
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
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]
Hello all,
Have a 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 another user comes along
and only sees the individual packages, and uninstalls them leaving the rogue
Bun
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:
...
This works fine. The text stored in this property is shown.
I wanted
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 nee
Hey,
I am using Wix COMPlus extension to register my complus
application, here is the code:
and Here is the MSI log:
ComPlu
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 ou
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 binary
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
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
sanjay
In that case I'd actually want the test to pass if the user was privileged.
But if I use:
Privileged
The install errors regardless of whether I'm an admin with this in the log
[0B98:0C48][2012-01-26T17:21:00]: Condition 'Privileged' evaluates to false.
It seems like Privileged may never
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, I
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: wix-users@l
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
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 g
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.
---
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 eff
Too much work. :)
On Thu, Jan 26, 2012 at 12:05 AM, 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" (WiLogUtl.exe).
>
> One Problem 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. wrote:
> Hi,
>
> I'm just curious what can "burn" and "netfx" protocols supports? I need to
>
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
30 matches
Mail list logo
