Rob Mensching-7 wrote
> You are responsbile for ensuring that the seed changes when the
> Directory's path changes.
Okay, then I assume this feature is incompatible with a user-defined
location since its path can change at install-time.
--
View this message in context:
http://windows-installer
Rob Mensching-7 wrote
> Yes, feature is good to go now.
Great, thanks Rob! The help doc for Directory/@ComponentGuidGenerationSeed
says, "once a directory is assigned a Component Guid Generation Seed the
value must not change until the directory name changes". Is that really
referring to just th
I'm converting some InstallShield installers to Wix. I was planning to use
Heat to harvest the "dynamic directories" so our process can remain the
same. I wanted to use the -ag flag to generate component guids at compile
time.
The directory is to be installed under the IIS wwwroot folder. Becau
r XML (WiX) toolset]"
10/24/2012 10:30 PM
Send To:
"john.burak"
cc:
Subject:
Re: Differences in Heat output when run on 32 vs 64 bit build machine
Heat simply calls the entry point and captures the
data. The DLL must be writing different values on different OSs.
On Wed
Hi,
We recently automated Heat on our COM-registered libraries. I ran it on the
same DLLs on a 64-bit machine and a 32-bit machine and noticed a couple
differences in the .wxs output. Heat on the 32-bit machine added
ProxyStubClassId32 attributes to the elements, and added
ThreadingModel="apart
The original issue was that we wanted to specify which configuration builds
by default after launching the IDE with no preexisting .suo file. Turns out
this is dictated by the names of the configurations in the solution.
--
View this message in context:
http://windows-installer-xml-wix-toolset
This is an old thread, but I finally got around to figuring out an answer.
There may be a Votive bug, or a VisualStudio bug/feature. Maybe you guys can
tell me.
When you fire up VisualStudio (I'm using 2010) and hit Build/F6 it does not,
per se, build the Default Build Configuration (the one that
My installer receives credentials from the user then starts a service under
them. If the user enters bad credentials or if the specified account
doesn't have permission to install a Service, the installer rolls back with
no error message. I think it's a long shot, but am I doing something wrong
t
Bob Arnson-6 wrote
>
> Not sure what the writer was smoking that day but there's nothing like
> that in the WiX code and it's not supported by MSI. Could you file a
> bug? Doc needs fixing.
>
Thanks, Bob. I figured it was probably something like that. Probably just
hasn't been implemented y
The docs for the ServiceDependency Element say:
Id: The value of this attribute should be one of the following:
1. The name (not the display name) of a previously installed service.
*2. A foreign key referring to another ServiceInstall/@Id.*
3. A group of services (in which case the Group attribu
It's my understanding that with MSBuild, the configuration and platform used
when none are specified is defined near the top of the project file in the
elements with "blank" conditions, like this:
http://schemas.microsoft.com/developer/msbuild/2003";>
*Debug
x86
*
This doesn't seem to
As Edwin could have more tactfully pointed out, his script does have some
advantages over mine. Thanks, Edwin. Mine is intended to get you in the
right direction, while his is more production ready except for one point: I
still suggesting using Start-Process to launch msbuild so that you can get
I've done it and it works fine. One tricky thing was working with
PowerShell's parsing modes to get the arguments passed-in correctly (notice
the back-tick-escaped double quotes in the $msBuildArgs parameter, below).
If you manually use Candle/Light you have to worry about compiling fragments
ah
The topic of automating Heat has come up several times on the Users list. I
haven't seen anyone post an implementation. At work I'm about to write such
an extension but /only/ concerning harvesting specific COM visible DLLs.
I'm reading about Wix Extensions and brushing up on the Component Rules
I'm creating my first MSPs. It appears that if a single component changes
then all other components in the same Feature are reinstalled/repaired when
the patch is applied. Is that correct behavior?
Backstory: I have some components that install Services. These components
do not change in the ne
Hi all,
We're using Torch/Pyro to create MSP patches for an installer originally
from InstallShield (haven't converted it to Wix yet) and we're ending up
with a negative number for the patch CAB's LastSequence number. This seems
to cause a 2920 "source directory not specified" error during instal
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
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
Bob Arnson-6 wrote:
>
> In addition to admin images, you can use Melt.exe to build an image you
> can use without -ax.
>
I thought Melt only http://wix.sourceforge.net/manual-wix3/AllTools.htm
dealt with merge modules (.msm). Special use, maybe?
- John
--
View this message in context:
ht
move -xi flag, add -xo flag to torch.
- Point torch to "1.0\admin\product.msi" (and "1.1\admin\product.msi")
instead of the original "1.0\product.wixpdb" (and "1.1\product.wixpdb").
- John Burak
john.burak wrote:
>
> I browsed the bug database and
ange
> Office: 913-341-3434 x791011
> JoCooper@
>
>
>
>
> -Original Message-
> From: john.burak [mailto:john.burak@]
> Sent: Thursday, November 03, 2011 1:39 PM
> To: wix-users@.sourceforge
> Subject: Re: [WiX-users] Patch with a simple file change
>
I browsed the bug database and eventually found out "
https://sourceforge.net/tracker/index.php?func=detail&aid=2086871&group_id=105970&atid=642714
pyro actually diffs the files on disk " and not from inside the MSIs. In
other words, the 'before' and 'after' copy of files have to exist at the
same
[Sorry if you got this twice, I think I botched posting via Nabble the
previous time]
Hi,
I tried the patching example given at
http://wix.sourceforge.net/manual-wix3/wix_patching.htm but I changed it so
the source-path points to a single file in both versions (1.0 vs 1.1), and I
just change the
Edwin G. Castro wrote:
>
> ARP/P&F can and does list things that are not MSI products. Could some of
> those non-MSI products use an external API to perform the wholesale
> refresh?
>
That was the only guess I had. On closer inspection, I bet Notepad++ isn't
using Windows Installer. I guess t
Bob Arnson-6 wrote:
>
> Nope. ARP/P&F doesn't do a wholesale refresh of the program list for MSI
> packages. When you click Uninstall and it succeeds, it just deletes that
> one entry.
>
Okay. I wonder what the difference is between doing an uninstall via the
usual method and doing an uninst
Not a huge deal I know, but I did get an internal bug about how "Add/Remove
Programs" (aka "Programs and Features") doesn't refresh after doing a
"Change" and picking "Remove". A straight uninstall causes the refresh, but
picking Change and navigating to Remove doesn't. I'm using a UI based on
Wi
Just to follow up for future readers, it looks like there was no problem to
begin with. I tried smoke.exe and got no errors, except for on two merge
modules. I think that my merge modules are just in better shape than I
thought. Wow. :) I am used to getting some sort of output, at least Info
me
Right now when I try to view any pages in the Wix manual (v2 or v3) I get
this from SourceForge:
This project has been temporarily blocked for exceeding its bandwidth
threshold
Projects and users who host on SourceForge.net are given web space to
augment their communities and interact with their
Bob Arnson wrote:
>
> It does by default. Look at verbose build output to make sure -sval
> isn't being passed.
>
I checked and I'm not suppressing any ICE validation. I tried again in Orca
and realized I was running the full test suite and not just the Merge Module
validations. It tried aga
Hi,
I'm compiling some merge modules in Visual Studio and getting no ICE errors,
even though I get ICE errors when validating the resulting msm in Orca. The
http://msdn.microsoft.com/en-us/library/windows/desktop/aa372423(v=vs.85).aspx
Using Internal Consistency Evaluators page on MSDN talks ab
hers don't. Not
because Advanced is still in a state of flux.
- John
Bob Arnson-6 wrote:
>
> On 07-Sep-11 13:24, john.burak wrote:
>> I'm curious why WixUI_Advanced uses APPLICATIONFOLDER instead of the
>> well-known INSTALLDIR property which Mondo and other popular ms
john.burak wrote:
>
> I like the Advanced UI more than Mondo for most things. It cuts down on
> clicks and superfluous dialogs for the most common use cases.
>
> I'm curious why WixUI_Advanced uses APPLICATIONFOLDER instead of the
> well-known INSTALLDIR property which
I like the Advanced UI more than Mondo for most things. It cuts down on
clicks and superfluous dialogs for the most common use cases.
I'm curious why WixUI_Advanced uses APPLICATIONFOLDER instead of the
well-known INSTALLDIR property which Mondo and other popular msi build
technologies use?
I'm
Bob Arnson-6 wrote:
>
> WixUI_Advanced is the only dialog set that includes something in
> InstallExecuteSequence. So it pulls in some values that conflict with
> the bad sequences from the merge module.
>
If the merge modules alone (without the Advanced UI) don't produce these ICE
validation
Thanks, that seems to have worked.
I'm curious why sequencing was altered by the Advanced UI + particular merge
modules. With Mondo the sequence numbers were correct even with the same
merge modules. If this might be a bug in the Advanced UI let me know there
is anything you'd like me to test.
I've successfully I added the "WixUI_Advanced" UI to my installer and it
works. But now I get these errors:
Error 293 ICE27: 'StopServices' Action in InstallExecuteSequence table in
wrong place. Current: Costing, Correct: Execution light.exe 0
1
Error 294 ICE27: Act
Strange, still broken for me. Maybe there is something wrong with the
SourceForge server I'm getting in my area. Thanks!
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Broken-link-to-Mondo-documentation-page-tp6754555p6755175.html
Sent from the wi
Is anyone else getting a server error in the following situation? I clicked
the "Mondo" link on the page
http://wix.sourceforge.net/manual-wix3/WixUI_dialog_library.htm
http://wix.sourceforge.net/manual-wix3/WixUI_dialog_library.htm and got the
error:
/An error has been encountered in accessing
Okay, thanks. I thought that must be an OS icon.
Does anyone know an example of where the WiX exclamation icon is used? I'm
replacing the graphics listed in the table half way down this page:
http://wix.sourceforge.net/manual-wix3/WixUI_customizations.htm
One of them is known as "WixUIExclamat
Hi,
I'm trying to build an installer using the Mondo UI with custom graphics.
They seem to work except for the "exclamation icon", which instead uses a
graphic that is neither what I specified or the stock Mondo exclamation
icon. Is this a bug I should report?
The issue is shown in the screen s
43 matches
Mail list logo
