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 install
Just to make sure I understand
The code as you have written it will be attempting to take the source
file c:\CabFilesInstaller\SchedulingServicesCAB.CAB, and use it for both
the installed file with long name ConfigurationService.svc and
DataListService.svc. Is this really what you want, or is
Quinton,
One thought... Yes Program Files is not browsable by default, but I have
seen quite a lot of installations create a shortcut that opens Explorer
to the right place for the samples. (I don't know if this causes
problems with UAC since I haven't yet had the chance to play with Vista.
:-(
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
Since
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
Kevin,
I don't know if it's the recommended way (it probably isn't) but here is
a brief description of what we do here:
We happen to use NAnt for our build scripts. You should be able to
accomplish similar results using a batch file, MSBuild or similar.
Our calls to Candle look somethin
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 element in the , and a
element in the .
I don't know if both are actually necessary, but I would imagine there
must be at least one element, otherwise you will never actually
be including the merge module -
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 help
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 installat
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 B
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 case
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
[!Featur
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:
&AMS = 3
Or
Hope this helps,
Regards,
Richard
From: Carl Quirion [mailto:[EMAIL PROTECTED]
How is the apostrophe getting into the TARGETDIR? Is it being entered /
selected by the user, or are you attempting to author a folder which
contains an apostrophe?
Personally, I would suggest that the best thing to do is stay away from
folders with odd names, but I understand that you may not
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
option.)
Rene,
Nested installs (running one MSI from within another) are not supported
by Microsoft Installer.
You need to use a bootstrapper. Check the archives of this mailing list
for suggestions.
Regards,
Richard
From: [EMAIL PROTECTED]
[mailto:[EMAIL P
Rene,
Sorry, I guess I should have been more clear. While support for nested
installs is mentioned in the SDK, the official word from the Microsoft
Installer team themselves is "Don't use them".
See
http://blogs.msdn.com/windows_installer_team/archive/2006/11/06/q-a-from
-latest-windows-ins
Lav,
Aside from the usual "Custom Actions are [nearly always] evil" type
statements, the best thing to do is code your custom action via some
other mechanism.
Ideally, a custom action should not have any dependencies, since you do
not know what will and will not be present on the machine wh
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 si
More likely that my memory is fuzzy. I thought GUID generation only got
added in Heat, but I've been wrong plenty of times before!
Regards,
Richard
From: Rob Mensching [mailto:[EMAIL PROTECTED]
Sent: Friday, May 11, 2007 11:40 AM
To: Foster, Richard - PAL
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
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
element, specifically the "Property" attribute) should be able to handle
what you need if the user just enters the server name. (I.e it
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 I
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
http://www.codeproject.com/install/dotNetI
Yeah, I agree that MSDN article really doesn't say much about how to do
it... I should probably have read it better before passing on the URL,
it was just one of the early results in the Google search I did!
As far as the better bootstrapper is concerned, I believe that is part
of the vision for C
I *really* hope this isn't for a "product" that is going anywhere but
inside your company.
If it is, then I'm sorry to say it but your boss is being idiotic (and
asking for trouble down the road when the time comes to update or
maintain whatever it is you are packaging).
If it is only an in
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 vali
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 clos
I believe the 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 Message-
From: [EMAIL PROTECTED]
[mai
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 ab
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 un
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
http://blogs.msdn.com/windows_installer_team/archive/2006/11/06/q-a
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
From:
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++) that
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 w
Since WiX effectively "wraps" Microsoft Installer technology in a more
user friendly form, almost any information associated with Windows
Installer is also applicable to WiX.
The main problem is typically working out which part of the XML schema
relates to the Microsoft Installer table (or column)
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 t
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 be
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. 1
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 fact
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 archi
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=642714&group_id=105970&func=browse
- I haven't checked to see if there is one entered already).
WiX i
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 elements
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 an
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 ag
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 11
Hina,
The $(env.Whatever) construct is used to pull a setting from the system
environment at build time.
The 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
accomplish. Ar
Hina,
It sounds as if what you really want is a standard preprocessor
variable.
Try something like this:
...
...
The mechanism shown above allows you to specify a
default value for the setting, and also override that setting from the
command line using (for example) candle
-dHelpSource
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 hina170
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 ma
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
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 prope
Dave,
You probably already identified the problem - the name needs to be
quoted. Try this:
Regards,
Richard
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of dave_c
Sent: Thursday, February 22, 2007 9:50 AM
To: wix-users@lists.sourceforge.net
Subject: Re
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 PROTECTED
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
here
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 i
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.d
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 choice
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 it/t
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 assi
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 wan
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 "", or the -d
prompt at the command line then you need to prefix them with "var."
whenever they are re
[Oops... resending to the list so it is present for future reference.]
Use the command line parameter -d=
For this and other helpful information on available options run the
appropriate tool (e.g. candle, or light) with the "-?" command line
option.
Regards,
Richard
__
Shayla,
An example from our own build process is as follows:
Candle -dMajorRev=1 -dMinorRev=2 -dPatchRev=3
-dBuildRev=4
Within the script, we use (for example)
I'm not sure if you are actually including the ( and ) characters in the
command line. If so, that's where you're goi
One other concern in making custom actions in C# (or anything else) is
that as Rob regularly observes, custom actions are very difficult to get
right - especially when considering installation failure (rollback) and
appropriate uninstall operation. Speaking for myself, I try to avoid
them whenever
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 us
Known, yes... Since they have been in the merge modules for a long time,
it seems that Business Objects aren't (or weren't) really bothered about
resolving them. I guess it worked "well enough". Fortunately with Vista
that's going to have to change, although perhaps not as much as it
should. It doe
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 h
Either calling regsvr32, or (more correctly and more in keeping with the
Windows Installer way of doing things) adding SelfRegCost to the appropriate
element(s) and making sure that and
is present where it needs to be in your InstallExecuteSequence.
I would STRONGLY recommend against doin
Could you not use 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: wix-users@lists.sourc
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 g
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 th
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 space
In response to Jason Van Eaton's question about deleting all files in a
folder on uninstall (including ones that were not initially installed)
Rob Mensching responded:
Personally, I would do work to describe all of the files to get the
confidence that my install costing/install/uninstall/repair/up
Jason,
Are you persisting the installation path somewhere (e.g. the registry)?
If not, then you will run into problems because Windows Installer won't
take care of that for you automatically.
Regards,
Richard
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
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. Unfo
Kevin,
Yup, Crystal have *not* fixed the problems with their merge modules,
even in CR XI R2.
If you can, I would strongly recommend using a bootstrapper and the MSI
version of the redistributable. If you don't, and you are using WiX V3
then you will almost certainly have to disable validation (o
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 whic
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 i
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 creatin
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 te
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
1 - 100 of 110 matches
Mail list logo
