Mike,
Given what you describe, I assume you are using a property for the
shortcut name (and that property can be modified by the user interface).
Unfortunately, Microsoft installer does not retain any knowledge of
properties from one execution to the next, and that is why the value for
that
Dave,
You probably already identified the problem - the name needs to be
quoted. Try this:
Property Id=QtExecCmdLine Value=perl
quot;[INSTALLDIR]first.plquot; install/
Regards,
Richard
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of dave_c
Sent:
I assume you're using Wix 3? If not, I can at least confirm that Wix 2
can be used under CCNet (we use it). You might want to check and see if
any anti-virus software is getting in your way.
Regards,
Richard
From: [EMAIL PROTECTED]
[mailto:[EMAIL
I'd say you need to find out what those registry items are for. You're
right that there should be a better way, and that is Heat should not
be including them (unless they really are needed).
Since they are appearing, it sounds as if either you have:
A) Found a bug in Heat
B) There
Robert,
One thing I'm not sure about... Are you saying that you want to be able
to change the property at runtime? If so, then I think what you are
suggesting may actually break the component rules (you would have the
same component, but multiple different filenames). I'm sure someone else
In that case, look at the Preprocessor section in the WiX help, it
describes the preprocessor variables (which was what I mentioned), and
also how a similar technique can be used to access environment variables
and system variables.
Be aware though, that the $(var.) format I mentioned is
Bob,
As far as features / components are concerned, you probably want to look
at the Microsoft installer documentation.
Very basically though, Features are what the end user sees (e.g.
Word, Excel, etc), and have a one-to-many mapping with the
Components (word.exe, wordsupportfile.dll,
Bob,
Since I have not (yet) needed to deploy a web application, take the
following with caution!
Because it is an in-house application, and not intended for widespread
distribution to potentially remote sites you might be able to get away
with a single component (assuming no optional
Scott,
If I understand you correctly, you are saying that you currently have
the same source file included in multiple components. Is that right?
If so, presumably there is something stopping you from putting the
file(s) in as many components as you need and including a ComponentRef
to
Rory,
One thing to be aware of (which caught me, and continues to be a source
of frustration from time to time) is that Windows Installer only looks
at the first 3 parts of the version information.
Lesson 4 in the tutorial (http://www.tramontana.co.hu/wix/lesson4.php)
should offer some
ALLUSERS is an installation level property. (I.e. you can run the
installation for the current user - ALLUSERS = 0, or for all users -
ALLUSERS = 1). It is not associated with the directory.
Beware - the property is a public one, and therefore needs to be all
uppercase.
You really don't
Jason,
The error message is actually more helpful than it might seem at first.
The names you have provided for the preprocessor to use are simply not
valid.
If you are defining those items using ? define ?, or the -d
prompt at the command line then you need to prefix them with var.
whenever
Shayla,
An example from our own build process is as follows:
Candle SourceScript -dMajorRev=1 -dMinorRev=2 -dPatchRev=3
-dBuildRev=4
Within the script, we use (for example)
Package Id=----
Description=Description Comments=Product
We certainly are getting ICE warnings (with CR 11). Fortunately, we are
currently using WiX 2, so the ICE errors, while annoying, don't cause a
build failure. They also don't cause the specific error you mention.
I coded my WiX script with conditional inclusion of the Crystal merge
module. I
Friedrich,
Adding runtime components to the installation (e.g. the merge files)
will usually not help because they typically won't be installed until
after your custom action has run. Since your custom action needs them,
it will fail and so they never will get installed.
The most important thing
Jacquet,
If you have binary compatibility enabled for the DLL then you should
only need to regenerate the registry keys if you modify the public
interface. This would probably significantly reduce the number of times
you have to change the keys in question.
You could use SelfReg... but as
Either calling regsvr32, or (more correctly and more in keeping with the
Windows Installer way of doing things) adding SelfRegCost to the appropriate
File element(s) and making sure that SelfRegModules and SelfUnregModules
is present where it needs to be in your InstallExecuteSequence.
I
Could you not use RemoveFile if the files in question should be
removed on uninstall?
Regards,
Richard
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Levi
Wilson
Sent: Wednesday, March 21, 2007 10:59 AM
To: [EMAIL PROTECTED]
Cc:
A type library is almost exactly what it sounds like. It is a library
(i.e. can be referenced by a development tool such as Visual Studio)
containing information about COM (and possibly other, I haven't really
investigated) types.
Typically, type libraries have a .tlb extension. Visual Studio
In his response, Friedrich asked: Well couldn't I run the custom action
when I like for what good should be the After, Before etc stuff then?
Yes, up to a point you can run a custom action whenever you want. I say
up to a point because doing so after InstallFinalize is not usually
a good idea,
Original message from Friedrich [trimmed in places] with my comments
inline and prefixed by RJF:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Friedrich
Dominicus
Sent: Thursday, March 22, 2007 3:27 AM
To: wix-users@lists.sourceforge.net
Subject: Re:
Justin Dearing wrote:
So it seems like I have broken WiX rules and cannot properly fix them.
More accurately, you have broken Windows Installer component rules. (WiX
is only used to build the MSI file, and multiple files within the same
component can be valid in some scenarios.)
The mechanism
You didn't mention which version of WiX you are using.
I am still using version 2, and I have an additional LongName
attribute on the shortcut. If you are using version 2 as well (and I
suspect you're not), you may want to try adding one of those.
I also notice that you seem to have spaces
Jason,
The problem is that Windows Installer doesn't know that the user
selected a different folder at installation time. It is up to you, as
the author of the installation to ensure that INSTALLDIR is set to the
same value when the application is removed as it was when the
application was
Quinton,
If you haven't encountered it, Microsoft's Patterns and Practices group
provides a great set of resources.
The entry point for all the information is (assuming I still have the
right shortcut in my browser favorites)
http://msdn2.microsoft.com/en-us/practices/default.aspx
D'oh! Sorry! I hit reply to all then failed to take out everyone except
the group.
Please forgive the double mailing you'll get. :-(
Regards,
Richard
* C O N F I D E N T I A L I T Y N O T I C E *
---
The content of this e-mail is
Anthony,
I think the reason you see it so much is that giving out a sample this
way is safe. You are perfectly correct that you don't need it unless
there are XML reserved items, but it seems that (unfortunately) huge
numbers of developers don't understand the requirement to encapsulate
those
Carl,
I did a quick check in our code... (WiX V2 BTW)
We appear to be using a Merge element in the Directory, and a
MergeRef element in the Feature.
I don't know if both are actually necessary, but I would imagine there
must be at least one Merge element, otherwise you will never
It depends what type of text file.
If the files are XML, the wixca.wixlib includes a custom action which
may accomplish what you need.
If the file is an older style .ini file, then there may be support for
what you need built into Microsoft Installer (see the IniFile element in
the WiX
Arguably, yes... if you append text to a file on installation, that text
should be removed when you uninstall.
If you have several installations that perform similar operations on the
same file things will get really messy!
Again, it may help if we know the problem you are trying to solve.
Ah! So we're talking about user specific data huh.
Generally speaking, users take a very dim view of an installation
modifying anything they have modified, so I think that supporting
rollback is probably not appropriate in this instance.
My next question would be this. Why is your
So, what we're talking about is something like the way VB6 used to
handle add-in tools... only less structured.
You have my sympathy. :-)
If the file you are appending to really is unstructured text (as opposed
to something with an ini file structure, but with a txt extension), I
think you
VBScript? Absolutely not!
Why do I say that? Because among other reasons you then place an
additional dependency on the installation (the scripting runtime). True,
VBScript custom actions are supported, but I think you'll find comments
from people who should know (E.g. Rob Mensching - see his
Nathan Lee wrote:
Running the VBScript outside of the MSI works, and I'd expect it to work
inside the MSI.
Nope. As others have already observed the sequencing is probably just
plain wrong (the MSI's may not exist on the disk at the time you try to
install them). Even if that were not the
Carl,
If I understand correctly, you're using a single registry item, and need
it to have a different value based on which feature(s) are installed.
I suspect what you probably want is to use the feature installation
state and/or feature action state property (e.g [FeatureKey] and
Carl,
That problem confused me for a couple of minutes too Then I
remembered my XML encoding rules!
The correct syntax would be one of the following:
amp;AMS = 3
Or
![CDATA[AMS = 3]]
Hope this helps,
Regards,
Richard
From: Carl Quirion
Michael,
One constraint of Windows Installer is that it is not possible to run
one MSI from within another (also known as a nested install). If you
have two MSI files, you need an external application (the bootstrapper)
to trigger the installation of each MSI in turn. (I.e. your second
Venkatesh,
No version of Tallow exists that automatically generates GUID's. The
reasoning behind this is that automatic GUID generation leads very
easily to breaking component rules. Tallow is intended for *one time*
generation of a basic file which is then modified manually.
Mallow is a
Chris,
Just for stupidity's sake, make sure you have changed that setting for
the correct build. I spent almost an hour one morning wondering why
something wasn't linking the way I expected, only to find that I had
made the change in the release settings and was trying to use the debug
build!
Scott stated [Heat] obviously should be [usable in an automated build
process]
To which I would reply, Should it really?
From my point of view, using Heat (or its WiX V2 predecessor Tallow) is
akin to using a radio controlled rifle from several hundred miles away
without the benefit of a
To clarify Rennie's comment...
Yes, you will need a custom action, but not one that you code manually.
The already available Type 51 custom action (see the CustomAction
element, specifically the Property attribute) should be able to handle
what you need if the user just enters the server name.
It may be a stupid question, but do you have any anti-virus software
running? If so, that can completely cripple performance of an
installation, and since you indicate that it is the File copying phase
I would be interested to see what the difference is versus installing on
a non-protected system.
Bob,
I guess I still need to learn more about Windows Installer...
It was my understanding that formatted text expansion would typically
occur before the user interface is shown. In this specific case, the
user conducting the installation will be modifying the values, hence the
reason why
Jerome,
There are several readily available bootstrappers. If you are developing
using Visual Studio 2005, this article may be helpful:
http://msdn.microsoft.com/msdnmag/issues/04/10/Bootstrapper/
For other open source options (like dotNetInstaller - see
I'm sorry... Using NAnt as the engine for applying a patch, in a
scenario where NAnt is probably not present on the user's machine?!
That's just ugly! (My personal opinion, of course.) It's just as well
you're using a personal email address rather than a company one because
otherwise I'd be making
Sadly (and Rob M has commented on this several times) the VB Team seem
to feel that generating correct merge modules is not a priority. (For
them, perhaps it's not, but for those of us who live in the real world
where VB6 applications are still very much in use it does make things
challenging.)
D'oh! I had forgotten about the EnsureTable fix (referenced in earlier
messages). All but one of my VB installations had been updated to use
that. Naturally, the one I looked at before sending the previous message
was the one that wasn't (but contains assorted comments about building
without
I think my question would be why the user is forced into a (somewhat
unfriendly) specification of command line parameters as opposed to a
friendlier scenario using (for example) a configuration file, or a
configuration interface that stores things somewhere appropriate.
You may want to take a
I believe the IgnoreModularization Name=SS_INSTALL_COM element is
what you need to use.
For merge modules, appending the GUID is the standard operation since it
allows independently created merge modules to use properties etc. with
the same name.
Hope this helps,
Regards,
Richard
-Original
It seems you didn't look very hard. There is an example right there in
the tutorial: http://www.tramontana.co.hu/wix/lesson3.php#3.2
Look specifically at the notepad example, and you will see that the
command line parameters would go in the ExeCommand attribute.
As far as your complaints
Jeroen,
A bootstrapper (also known in some places as a chainer) is the option to
use.
Microsoft Installer does not support two simultaneous installations.
(There was a custom action intended to support nested installations, but
it was deprecated long ago. Based on comments from others, I
Bernd,
While it is not documented in the article you reference (but probably should
be) custom action types 7, 23 and 39 are deprecated.
For more details, see the various blog entries by the windows installer team -
especially
I don't know if it was actually the case, or if it was an email
formatting thing, but it looked almost as if the original MSI name had
spaces in it, and the one that works didn't. Could that possibly be the
root cause of the problem?
Regards,
Richard
Baladji,
Be very careful using C# within a Microsoft Installer based installation
(like those generated using WiX). By doing so, you place an additional
dependency on the .NET framework, and has been discussed many times this
is a *bad thing*. Ideally you should choose something (e.g. C++)
Thanks for the clarification. (As I have mentioned previously on this
list, I personally do my best to steer clear from *all* non Microsoft
Custom Actions and was unaware of the special CustomActionData
property.)
I would agree that unless you are familiar with the quirks C# is much
easier to
Bob effectively already answered that.
The ALLUSERS property should not be set to anything by default.
In your user interface, if the user chooses Everyone, set ALLUSERS to
1.
I can't remember off the top of my head if the ALLUSERS setting is
persisted anywhere. If not, you may need to
John,
It may be a silly question (and hopefully is), but does the application
itself have any path-related dependencies? I.e. can you use the same
command line as Installer would use successfully, bearing in mind that
the working directory and the application's installation directory may
not
John,
The 210 is a little misleading, I admit.
Expressed in hexadecimal, 210 = 0xD2
From http://msdn2.microsoft.com/en-us/library/aa368071.aspx we can see
that this decodes as follows:
0x80 = Run operation asynchronously
0x40 = Ignore exit code
That leaves us with 0X12 - i.e.
John,
Glad to hear you sorted it out (even if the solution is arguably less
than optimal - but at least it's a solution).
I'm still going to try and work out what the sample in the documentation
*should* be, since sooner or later I'll need it myself! :-)
Regards,
Richard
Matt,
Heat is the tool for WiX V3, and will probably continue to be developed.
Tallow is the V2 equivalent, and should be supported for some time to
come but will probably not be enhanced further.
Be very careful of using Heat (or Tallow) to automatically generate your
installation files. In
John,
At first glance, I suspect you're using the wrong type of parenthesis.
If it's WiX 2.x you need ( and ), not { and }. I don't remember it
having been changed for WiX 3, but it may have.
Regards,
Richard
* C O N F I D E N T I A L I T Y N O T I C E *
Glen,
Some of the prerequisites you mention (specifically the .NET runtime)
are packaged using Microsoft Installer technology themselves. As a
result, you cannot automatically install them from within your MSI - all
you can do is make your MSI verify that they have been installed.
The
Peter,
If Heat is exiting with an ArgumentNullException it seems likely that
you have caught a bug. I suggest making sure it is added to the tracker
(at
http://sourceforge.net/tracker/?atid=642714group_id=105970func=browse
- I haven't checked to see if there is one entered already).
WiX is
Glen,
I agree, documentation on this is all over the place. Unfortunately like
many open source projects any work people do on WiX is almost invariably
in their spare time.
My understanding is that your understanding is correct. Your MSI should
include checks (coded in Wix as as condition
Thanks for the clarification Christopher!
It was my (apparently inaccurate) understanding that most SMS users
preferred using MSI's directly (and managing dependencies themselves)
because of the risks associated with a bootstrapper potentially doing
something that could not easily be repared
DongFang,
Breaking the limitations you have observed is probably not possible in
WiX since WiX is just a mechanism for authoring files which are then
handled by Microsoft Installer. Unfortunately, if what you are
attempting to accomplish is not handled by Microsoft Installer itself
(and I would
I had so much hassle with the Business Objects merge modules I moved to
using their MSI file and triggering it from a bootstrapper.
The Runtime MSI file can be found in the following locations (assuming
you chose the default installation path):
C:\Program Files\Business Objects\Crystal Reports
Hina,
The $(env.Whatever) construct is used to pull a setting from the system
environment at build time.
The Environment element is used to configure an environment setting on
the machine where the installation is performed.
The correct answer will depend on what you are actually trying to
Hina,
It sounds as if what you really want is a standard preprocessor
variable.
Try something like this:
?xml version=1.0 encoding=utf-8?
?ifndef HelpSourceFolder?
?define HelpSourceFolder=C:\SomeFolder\Path?
?endif ?
...
File Id='tutorial' Name='tutorial.pdf' DiskId='1'
Hina,
Looks like a small typo - your error indicates ($var.HelpSourceFolder),
the correct format is $(var.HelpSourceFolder). The dollar sign needs to
be outside the parenthesis. :-)
Regards,
Richard
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Russ,
I believe you're possibly missing the fact that (if I remember
correctly) Windows Installer only looks as major, minor and revision
(fields 1 - 3) when deciding if the version has changed... not the
fourth (typically build number) field in the product version
information.
Check the mailing
Nick,
I've had good success using NSIS (http://nsis.sourceforge.net) to create
my bootstrapper. It can easily launch any application you may need. I've
also heard good things about InnoSetup
(http://www.jrsoftware.org/isinfo.php), but I have not used it myself.
Hope this helps.
Regards,
Richard
I was under the impression that while it is only permitted to *trigger*
one NewDialog operation, it is permitted to include definitions for
several trigger operations as long as the conditions under which the
separate dialogs are shown are mutually exclusive.
I agree however that is not what the
Pedro,
My first recommendation would be to use a bootstrapper and the Crystal
reports runtime MSI file instead of the merge modules. The merge modules
are IMHO almost useless, not to mention the fact that if you use WiX 3
you'll have to turn off verification because the CR merge modules have
so
Pedro,
I'm not sure where (or if) there is a runtime MSI for the original XI
release. There is for XI R2 (typically in C:\Program Files\Business
Objects\Crystal Reports 11.5\Samples\en\CR .NET\.NET 2 Runtime
Setup\CrystalReports11_5_NET_2005.msi for the .NET 2.0 version. There
may be something in
One of the other Richard's wrote:
How do you know that your service starts properly at all?
Since you're installing it, I assume that you've written and debugged
it already, but you didn't say.
A very common problem (which appears frequently on the mailing list)
related to installation of
But it is possible to start services using MSI / WiX. I know. My installation
does (I'm assuming it works for me because while the service is a .NET one, it
is not installed in or dependent on the GAC).
I guess what I'm trying to say is that there is merit to the ServiceControl
element.
Yike!
Just the concept is scary. I don't want anything happening to my machine
without my permission!
The answer, however, is no. Any handling of expiration needs to be done
outside of WiX / Microsoft Installer. The best you can hope for as part
of the installation is to write a CustomAction
Hi Chris,
Oops... no I didn't mean to reply just to you. Bringing the list back in
on the conversation!
I'm certainly not trying to imply that all custom actions are evil, but
a significant amount of time and effort have gone into the built-in
Microsoft custom actions, and the ones so far
Christopher Painter wrote:
I never understood why MSI doesn't have this automatic state saver
pattern built in.
Me either. Does anyone inside MS know why there isn't a mechanism to
accomplish this?
Regards
Richard
* C O N F I D E N T I A L I T Y N O T I C E *
The other Richard wrote:
Haven't you ever worked on a project where some enhancements are
postponed in favor of working on More Important Things?
All the time. I'm just surprised at how few of those More Important
Things in Windows Installer appear to offer a significant benefit to
those creating
It's a slightly unusual option, but if I was in your shoes I might
consider supplying the application packaged as a wixlib (containing the
main application installation), together with a utility which allows the
reseller to select their template folder. After verifying that the
contents of the
Adam Majer wrote:
You are making it too complicated. Wix is a great toolkit as it allows
the generation of the installer files directly from the command line.
To
me at least, the obvious solution to create *many* semi-customized MSI
files and to be sane is automation.
That is pretty much what I
Another Richard wrote:
There are times when I think the unzip files approach is legitimate.
For instance, suppose you have a bunch of data files that represent a
snapshot in time for a dynamically updating service. The service,
when run, will consume the initial snapshot of files to build
Ben Greenberg wrote:
I can't understand why anyone would want to add the complexity of an unzip
call into an MSI. It doesn't make sense.
Most of the time, you're right it doesn't.
I can see scenarios where an application is distributed to resellers who then
rebrand the software (hopefully
Jeremy,
Just for stupidity's sake, is everything OK if you reverse the order of
the second test?
I.e. the second test would become:
?if $(var.type) = msm ?
/module
?elseif $(var.type) = msi ?
/product
?endif ?
Unless I'm missing something, the file would then be valid again,
since
My guess would be that the intention was that wix input files should be
valid xml. In your case, the initial file wasn't (even though the
effective file, after post-processing, would have been).
Personally, I wouldn't consider that a defect, more a case of that's
how it works. :-)
Regards,
John Vottero asked:
What will keep the spammers from joining the list?
Absolutely nothing, but spammers are (generally) a lazy bunch and won't
do anything more than they have to. Most of the other SourceForge based
groups I subscribe to are locked to subscriber only posting, and they
have
Bob,
From my POV, I'd say that having the option on should be the default,
but allow for it to be disabled.
I don't know if it is a good idea or not... but it might also be nice to
have a way to disable the option easily for multiple files, but not
necessarily all files, in a WiX fragment - I.e.
I'd say there's a 90+% chance we'd be getting that support call anyway,
just because the message appeared in the first place!
For some reason our customers always assume that because it's our
installation, anything that goes wrong *has* to be our fault... even
when they haven't followed the
90 matches
Mail list logo
