Thanks Rob and Matt,
I think that gives me a better idea of where to go next - I'll probably
start with V2, build a simple project, and then take a look at WixCop...
with a view to moving to V3 as soon as we get a 'stable' build... I suspect
that for this release, anything I do will be V2 based.
In my experience (and who's experience other than mine would I have?) v3
is stable enough to do most tasks that the average installer needs to
do. Granted, most of our installers (currently in test/demo phase) copy
files around, register stuff in the GAC, create a web page or a virtual
directory or
This year? Stick to v2. I'm expecting there will be another bump or two in
the next few months in v3 that I would not want you to go through. WiX v2
isn't as "cool" as WiX v3 but it will behave consistently... which is probably
the most important thing for you in the next few months.
-Or
Hello,
I'm about to get started with WiX as a possible replacement for
InstallShield. I would like to get a view on what I should start with - V2
or V3? I want to use Votive, and I quite like the idea of a MSBuild
compliant project file, but I don't want to jump in using V3 if it has any
fundam
Hi Bob,
I have discovered a few hours ago that SetInstallLevel to 1 in an
upgrade will actually refresh the Features and install only the features
that I want. Your suggestion would help if the setup type had 3 options:
Typical, Full, Custom. This setup has more levels and tuning
INSTALLL
Scott Sam wrote:
> And I schedule RemoveExistingProducts with this
>
>
>
> I'm still getting the unresolved reference to symbol
> CustomAction:RemoveExistingProducts in section Product.
>
RemoveExistingProducts is a standard action, not a custom action. So you
should schedule it like this:
Calin Iaru wrote:
> It should be only Administration because the setup resets the level
> of all other features to 0 when "Typical" is selected like this:
>AllowAdvertise="no">
>
>
That's not going to work. MSI evaluates feature conditions only once,
during CostFinalize. U
Jarl Friis wrote:
> appropriate element). I have expected to be able to avoid
> that for the standard reasons:
> It's time consuming.
> It does not require intelligence.
> It's error prone; In half-a-year, when I actually do make an
>
Problem is: It does require intelligence. See, for example:
Hi
I know how to do it.
I just need to use the FroceReboot standard action.
Anyway is there any way to find out what error messasage (error
code) is used (trigered) by which action? (some kind of list...)
Thanks
Stefan
Stefan Pavlik wrote:
> Hi list
>
> I went through the Windows Install
I added this upgrade tag,
And I schedule RemoveExistingProducts with this
I'm still getting the unresolved reference to symbol
CustomAction:RemoveExistingProducts in section Product.
What else am I missing?
-
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Sigurd Stenersen
> Sent: Monday, October 02, 2006 6:22 PM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Installing machine-specific license files
>
> Arnette, Bill wrote:
> > th
[EMAIL PROTECTED] writes:
> Hello,
>
>
>
> My project generates documentation with doxygen and docflex for its library,
> which consists of a number of classes, resulting in a large number of HTML
> files, spread over a directory structure.
>
Could you use the itteration feature in the preproce
Hi list
I went through the Windows Installer error texts and found out that
some Errors are quite usefull.
My question is: What should I do to rise such error?
I know that I can create Custom Action type 19 but it will just
display the text and exit the installation.
For example:
I need (some
Hi,
Thanks for your answer. Changing to [PROWCINI_PATH] didn't work at first
glance, so after deeper investigations, I found the value returned by
RegistrySearch wasn't correct. Changing attribute Type to "raw" (and
removing $ sign before PROWCINI_PATH ! ) gives me a correct result.
So I now have
The tool Mallow should be able to help you
(http://www.infozoom.de/download/Mallow.zip). This isn't part of WiX but
you should be able to find the documentation and source for it with a
bit of Googling.
Neil
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf O
Hi Mike.
Thanks for the detailed answer (though it seems to drift off-topic).
"Mike Dimmick" <[EMAIL PROTECTED]> writes:
> Copy and paste into a .wxs file that describes your component,
> underneath the appropriate element. Tallow is not
> intended for use in automated build processes.
:-(
>
Hello,
My project generates documentation with doxygen and docflex for its library,
which consists of a number of classes, resulting in a large number of HTML
files, spread over a directory structure.
As I don't want to add each file individually to the installer by hand, I
wonder if there
Right now, I don't think so. Look for "!(wix." in the .wxs
files under src\ext\UIExtension\wixlib for other tunable variables in the
UI.
For 3.0.2015.0 this gives:
Searching for: !(wix.Common.wxs(15): Common.wxs(16): Common.wxs(17):
Common.wxs(18): Common.wxs(19):
Common.wxs(20): License
The $ symbol is used in the Target attribute to find a component's path.
You need to evaluate the value of the property, so your Target should be
[PROWCINI_PATH].
References:
Shortcut table:
http://msdn.microsoft.com/library/en-us/msi/setup/shortcut_table.asp
Shortcut data type:
http://msdn.micro
All the links down the right-hand side are broken when you're browsing the
Manual section. On the Manual index page itself,
http://wix.sourceforge.net/manual-wix2/wix_index.htm, all the links to other
sites (WiX on SourceForge, Bug and Feature trackers, Rob and Justin's blogs)
attempt to use re
Copy and paste into a .wxs file that describes your component, underneath the
appropriate element. Tallow is not intended for use in automated
build processes.
You need to keep your GUIDs stable, so that you don't need to keep generating
the .reg file. You can do this either using the [Guid] a
Hi Bob,
the package runs from the User Temp directory. The package code is
changed. I think there are two problems:
one - ADDLOCAL is not looking as expected when doing a typical
install because it's set to everything. But the typical
setup will actually install what I want. Maybe it's a
Thanks for the help Mike. I have a very pretty
looking installer now.
Is there any way to inspect what variables
can be set with out looking through the source code?
Graham
From:
Mike Dimmick [mailto:[EMAIL PROTECTED]
Sent: 29 September 2006 17:33
To: Mike Dimmick; Grah
Hi.
I have started a versy small project (very close to SampleFirst.ZIP).
However The build procedure is this:
regasme.exe /regfile MyAssembly.dll generates a MyAssembly.reg file.
The regfile is then processed by tallow.exe to produce a
MyAssemblyRegistry.wxs file.
I would like the registry entr
[2nd try, first one never appeared on mailing list]
Hi,
I have a problem in my installer with creating shortcuts : basically,
I need to create a shortcut where the executable isn't part of my
installer and I just need to provide parameters.
I retrieve the executable path using :
And I add i
Bob Arnson <[EMAIL PROTECTED]> writes:
> Jarl Friis wrote:
>> Maybe, but it is not installed when installing the Wix3.msi (latest
>> weekly build). Is that intentional?
>>
> Tallow is a WiX v2
> tool. Its replacement is
> Heat in WiX v3 but it
> doesn't currently
> support .reg translation.
Thank
26 matches
Mail list logo