This is an automatically generated Delivery Status Notification.
THIS IS A WARNING MESSAGE ONLY.
YOU DO NOT NEED TO RESEND YOUR MESSAGE.
Delivery to the following recipients has been delayed.
[EMAIL PROTECTED]
Reporting-MTA: dns;smtp.velocitynet.com.au
Received-From-MTA: dns;quantum
Arrival-Date: Fri, 1 Jun 2007 12:00:02 +1000
Final-Recipient: rfc822;peter@ifoley.id.au
Action: delayed
Status: 4.4.7
Will-Retry-Until: Sun, 3 Jun 2007 12:00:02 +1000
X-Display-Name: Peter Foley
--- Begin Message ---
Send WiX-users mailing list submissions to
wix-users@lists.sourceforge.net
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/wix-users
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of WiX-users digest..."
Today's Topics:
1. Re: v3 Simple Custom Action? (S C)
2. Re: upgradable merge modules (Mike Dimmick)
3. Re: Merge Modules Serialized and Stamped at Install Time
(Mike Dimmick)
4. Re: v3 Simple Custom Action? (Mike Dimmick)
5. Re: How to install files, run an action, then delete the
files?? ([EMAIL PROTECTED])
----------------------------------------------------------------------
Message: 1
Date: Thu, 31 May 2007 15:36:37 -0400
From: S C <[EMAIL PROTECTED]>
Subject: Re: [WiX-users] v3 Simple Custom Action?
To: <wix-users@lists.sourceforge.net>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="windows-1252"
Thanks for helping out. My MSI is supposed to install "silently", so the custom
action/event has to run every time. I got your sample to work when I do an
attended install, but trying to convert it to something that always runs after
the MSI "finalizes" is what is not working for me.
Thanks again.
_________________________________________________________________
Change is good. See what?s different about Windows Live Hotmail.
http://www.windowslive-hotmail.com/learnmore/default.html?locale=en-us&ocid=RMT_TAGLM_HMWL_reten_changegood_0507
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
Message: 2
Date: Thu, 31 May 2007 20:39:33 +0100
From: "Mike Dimmick" <[EMAIL PROTECTED]>
Subject: Re: [WiX-users] upgradable merge modules
To: "'Jerome Haltom'" <[EMAIL PROTECTED]>, "'Bob Arnson'"
<[EMAIL PROTECTED]>, <wix-users@lists.sourceforge.net>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="us-ascii"
Back to the original topic of merge modules:
Merge modules simply provide components to a larger install. There is no
concept of 'not installing if already installed' - the file versioning
mechanism covers this. The components are reference-counted so that the
component is maintained on the system until all products using the component
are removed. Installation packages should, as far as possible, be
self-contained.
If your component is completely compatible with the older version and
directly replaces it, you should keep the same file name and install
location (potentially retargetable) and keep the same component GUID, and
increment the file version number. If not completely compatible, you should
change the file name and/or install location and generate a new component
GUID. These rules are general for all Windows Installer packages but are
particularly important for components that will be shared among multiple
packages.
You probably do want to make your module retargetable - i.e. make the
install directory configurable - so that your clients can keep their own
private copies of the files, rather than installing to a shared folder. Only
install to a shared folder if the component can only tolerate one version
running on the system at a time, which is a very rare requirement - perhaps
they use a specific format of shared memory section or shared data file
format which cannot be made forwards- and backwards-compatible.
Once merged, the module's identity is lost. There is no sign, from a Windows
Installer level, that the module ever existed (there's a few traces in the
component/file/etc names, that there's a GUID attached to each original name
to ensure there aren't conflicts, but otherwise no sign, and nothing that
can be queried). This means that you cannot, as the merge module developer,
detect and patch files because you don't have the product GUID which is what
Windows Installer uses to track that information. To service the contents of
the module, you have to distribute the updated merge module to all the users
of that merge module, and they have to update their packages and distribute
them. This is one major reason why Microsoft are moving away from merge
modules.
The VS merge modules are OK to use because they rely on Windows'
side-by-side assemblies feature, where a publisher policy configuration file
can override the version specified in the application's manifest - the
publisher of the component can override which version of the library will be
used (although the application can then force the older version again
through its own configuration file!)
Windows Installer used to support nested MSIs but there's some reason that
feature was deprecated (the engine still supports it for legacy products but
the documentation now simply says 'don't'). Phil Wilson says in "The
Definitive Guide to Windows Installer" that minor upgrades and patches
aren't possible with nested installs - again the servicing problem raises
its ugly head.
--
Mike Dimmick
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jerome Haltom
Sent: 30 May 2007 03:13
To: Bob Arnson; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] upgradable merge modules
> That level of control isn't possible in a merge module. Provide an .msi
> package instead.
So, what's the point of merge modules then? If I can't distribute a
third party library that other people can use as a dependency, what good
are they for?
And I don't think one can reasonable say it can be used as a dependency
if two consumers installs will conflict.
If I provide a .msi file, how will their .msi file include it?
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
------------------------------
Message: 3
Date: Thu, 31 May 2007 20:40:58 +0100
From: "Mike Dimmick" <[EMAIL PROTECTED]>
Subject: Re: [WiX-users] Merge Modules Serialized and Stamped at
Install Time
To: "'Nick'" <[EMAIL PROTECTED]>, <wix-users@lists.sourceforge.net>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="us-ascii"
Their build process generates random GUIDs every time they run a build.
--
Mike Dimmick
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Nick
Sent: 31 May 2007 03:21
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Merge Modules Serialized and Stamped at Install Time
I sent an email to a third-party component vendor, asking them to give me a
merge module for their product (OCX goodies), citing this as my concern:
http://blogs.msdn.com/robmen/archive/2003/10/18/56497.aspx
Their answer:
"Also since the Modules are serialized and stamped at install time, we are
unable to create merge modules that are generic."
OK...what are they talking about?
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
------------------------------
Message: 4
Date: Thu, 31 May 2007 20:47:18 +0100
From: "Mike Dimmick" <[EMAIL PROTECTED]>
Subject: Re: [WiX-users] v3 Simple Custom Action?
To: "'Anthony Wieser'" <[EMAIL PROTECTED]>, "'S C'"
<[EMAIL PROTECTED]>, <wix-users@lists.sourceforge.net>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="us-ascii"
Conditions on custom actions are positive - the action runs if the condition
is true.
I think you simply want NOT Installed - which may seem counter-intuitive,
but I believe the Installed property is set at the beginning of the install
process and isn't updated during the process.
--
Mike Dimmick
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Anthony Wieser
Sent: 31 May 2007 06:26
To: S C; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] v3 Simple Custom Action?
I'm doing it like this:
<Property Id="SURVEYURL">explorer</Property>
<CustomAction Id="TakeSurvey" Property="SURVEYURL" Return="asyncNoWait"
ExeCommand="$(var.SurveyURL)"></CustomAction>
<InstallExecuteSequence>
<Custom Action="TakeSurvey" Sequence="101">REMOVE="ALL" AND NOT
UPGRADINGPRODUCTCODE</Custom>
</InstallExecuteSequence>
But this runs before a successful uninstallation that isn't an upgrade
Anthony Wieser
Wieser Software ltd
Pulling my hair out on this one... Can anyone show a simple set of snippets
that would allow a custom action (launching the default web browser to go to
'http://localhost/test/page.html') to run after successful installation? I
thought this would be straightforward, but for some reason it's just not.
Help?
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
------------------------------
Message: 5
Date: Thu, 31 May 2007 15:47:39 -0400
From: <[EMAIL PROTECTED]>
Subject: Re: [WiX-users] How to install files, run an action, then
delete the files??
To: <wix-users@lists.sourceforge.net>
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset="us-ascii"
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 a note not to touch any product your company
produces with a very long pole.
If the installation had been authored appropriately in the first place,
you could probably have created a patch (msp) file with very little
additional work after generating the "fixed" installation. (See
http://msdn2.microsoft.com/en-us/library/aa367816.aspx for a sample of
how it is supposed to work).
Given the situation you are in, using Windows Installer (and by
implication WiX) appears to be making your life harder for no good
reason. If anything, I believe the added complexity make it even more
likely that you will have trouble somewhere and end up with a situation
where you are trying to fix the fixes.
I suspect that what Aaron was suggesting was coding a custom c# tool to
(for example) extract NAnt from an embedded resource (e.g. an embedded
zip file) into a temp folder, trigger it (using System.Process.Start),
wait for NAnt to complete, then remove NAnt. I also suspect that Aaron
was thinking it would be simpler to do so outside of WiX.
Regards,
Richard
________________________________
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Thursday, May 31, 2007 3:12 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] How to install files, run an action, then
delete the files??
Yes - the product is a hotfix MSI.
All the hard work of moving files, copyin files, etc is done by Nant -
we just want to use WiX as the main GUI.
My C# is pretty solid. Do you have any examples or URLs that show what
you are suggesting?
Cheers,
-Mike
* 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 intended solely for the use of the individual or
entity to whom it is addressed. If you have received this communication in
error, be aware that forwarding it, copying it, or in any way disclosing its
content to any other person, is strictly prohibited. Peek Traffic Corporation
is neither liable for the contents, nor for the proper, complete and timely
transmission of (the information contained in) this communication. If you have
received this communication in error, please notify the author by replying to
this e-mail immediately and delete the material from any computer.
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
------------------------------
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
End of WiX-users Digest, Vol 12, Issue 239
******************************************
--- End Message ---
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
