[WiX-users] Enforcing installation dependencies

[admiristrator]

I know we can configure a Launch Condition to check for the existence of
another installed product before installing, but is there a way to enforce
or at least warn the user if they later attempt to uninstall the
prerequisite (especially if we author the prerequisite)?

I guess there could be a launch condition specific to uninstallation, but I
can't think how it would work - from what I can tell, there is no easy way
to increment or decrement a registry value as a custom reference count of
dependent MSIs, and the built-in reference counts only work for retaining
specific components.

Or, how do you increase a reference count on a component (or file or other
item) that you aren't currently installing?

Thanks.
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Tip: Version number updater

[admiristrator]

I was searching around for a solution to easily update my MSI version
numbers with each build, but I couldn't find one.  So I wrote this and now I
don't have to remember.  Thought I'd share...

A C# 3.5 console app:

using System;
using System.IO;

static class VersionUpdater
{
/// summary
///
/// Updates a .wxs or other text file containing a
/// ?define version=...? preprocessor directive
/// and increments the least-significant version
/// grouping present and applicable to Major Upgrades.
///
/// ?define version=3.0.0? becomes ?define version=3.0.1?
/// ?define version=3.0.0.0? becomes ?define version=3.0.1.0?
/// ?define version=3.0? becomes ?define version=3.1?
/// ?define version=3? becomes ?define version=4?
///
/// For reference within the WiX project as in this example: Product
Version=$(var.version) /
///
/// In Votive, a pre-build event of ...VersionUpdater.exe
$(ProjectDir)Product.wxs updates
/// the version number for each build.
///
/// /summary
/// param name=argsA single command-line parameter/param
static void Main(string[] args)
{
if (args.Length  1)
{
Console.WriteLine(Error: Expected the path to a file to update
as an argument);
Console.ReadKey();
Environment.Exit(1);
}

if (!File.Exists(args[0]))
{
Console.WriteLine(Error: File {0} not found, args[0]);
Console.ReadKey();
Environment.Exit(2);
}

using (var fs = File.Open(args[0], FileMode.Open,
FileAccess.ReadWrite, FileShare.None))
{
using (StreamReader sr = new StreamReader(fs))
{
string data = sr.ReadToEnd(); // Read in the entire file

fs.Seek(0, SeekOrigin.Begin); // Reset to the beginning of
the file

System.Text.RegularExpressions.Regex regEx = new
System.Text.RegularExpressions.Regex(

 
@\\?define\s+version\s*\=\s*\(?majorMinor(\d*\.){0,2})(?version\d*)(.\d*)?\\s*\?\);

var versionMatch = regEx.Match(data);
var version = versionMatch.Groups[version];
var majorMinor = versionMatch.Groups[majorMinor];

if (!version.Success || !majorMinor.Success)
{
Console.WriteLine(
Error: Version match not found.   +
Expected ?define version=\w.x.y\?
(Recommended),  +
?define version=\w\?, ?define
version=\w.x\?,  +
or ?define version=\w.x.y.z\?,
args[0]);
Console.ReadKey();
Environment.Exit(3);
}

int versionNumber;

int.TryParse(version.Value, out versionNumber);

Console.WriteLine(Updating {0}{1} to {0}{2},
majorMinor.Value,
versionNumber,
versionNumber + 1);

versionNumber++;

string newData = data.Substring(0, version.Index) +
versionNumber.ToString() +
data.Substring(version.Index + version.Length);

using (StreamWriter sw = new StreamWriter(fs))
{
sw.Write(newData);
sw.Flush();
fs.SetLength(newData.Length);
fs.Flush();
}
}
}
}
}
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Merge Module versioning, or equivalent

[admiristrator]

Hi Bob,

I guess I'm completely missing how to version files then.  I don't find any
attributes or child elements of component or file that seem related.  I'm
not aware of any consistent file-versioning aspect of the windows file
systems.  Also, I expect a need to version non-files, such as registry
entries.

In my current WiX project, shared items are overwritten with older versions
and removed without respect for shared dependencies.  I'm trying to correct
that.  I can't find an example of how versioning and sharing files 
registry settings is supposed to work.

Let's say I have two components: a Shared File.txt file and a Shared
Stuff Version Number registry entry, installed by potentially one, two, or
three otherwise independent MSIs.

How can I specify that these components are shared and that reference
counts(?) ought to be maintained so that installing any one MSI has
everything it needs to operate, that a second MSI with an older version of
the shared component does not overwrite the existing shared items but does
officially depend on the shared components, and that a third MSI with a
newer version of the shared items overwrites, maintaining MSI 1  MSI 2's
official dependency on them, AND that the MSIs may be uninstalled in any
order, leaving the newest version of the shared items in place until all
three MSIs have been uninstalled at which point no items remain.

It would be acceptable if shared items had to be rolled back to the
next-most recent version upon un-installation of the most-recent version -
if that's just how it works.

Am I off my rocker?  It seems like complicated functionality, but it also
seems that this would be a capability of the Windows Installer.  Otherwise,
what is this file-versioning for and what are reference-counts for?

Thanks!


On Wed, Mar 3, 2010 at 6:38 PM, Bob Arnson b...@joyofsetup.com wrote:

 On 3/3/2010 4:14 PM, admiristra...@cox.net wrote:
  Can someone please detail how Merge Module versioning is supposed to
 work?
 

 There's no such thing. Merge modules are a collection of tables and rows
 that are merged into your .msi package, losing their identities in the
 process. All versioning is based on component state, which is based in
 part on the file versioning rules documented in the SDK.

 What problem are you having?

 --
 sig://boB
 http://joyofsetup.com/



 --
 Download Intel#174; Parallel Studio Eval
 Try the new software tools for yourself. Speed compiling, find bugs
 proactively, and fine-tune applications for parallel performance.
 See why Intel Parallel Studio got high marks during beta.
 http://p.sf.net/sfu/intel-sw-dev
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Merge Module versioning, or equivalent

[admiristrator]

Ok, thanks for the links.  I'm going to be working through them, but at
first glance, I can tell I still need a hint.

I can't tell if you're suggesting that if I understood Component Rules, I'd
know that what I'm looking to do violates those rules.  Is that what you're
saying?

More generally, is what I want to do possible?  If you could just outline
it, I'll know what to look for when I'm reading and researching.

Thanks

On Thu, Mar 4, 2010 at 8:21 AM, Pally Sandher pally.sand...@iesve.comwrote:

 You're basically asking if the Component Rules exist  if so how do they
 work.
 See http://msdn.microsoft.com/en-us/library/aa370561.aspx  the pages
 its last paragraph links to.

 Rob M wrote some very good blogs regarding the above which I'd recommend
 as further reading
 http://robmensching.com/blog/posts/2003/10/4/Windows-Installer-Component
 s-Introductionhttp://robmensching.com/blog/posts/2003/10/4/Windows-Installer-Component%0As-Introduction
 http://robmensching.com/blog/posts/2003/10/18/Component-Rules-101


 Palbinder Sandher
 Software Deployment  IT Administrator
 T: +44 (0) 141 945 8500
 F: +44 (0) 141 945 8501

 http://www.iesve.com
 **Design, Simulate + Innovate with the Virtual Environment**
 Integrated Environmental Solutions Limited. Registered in Scotland No.
 SC151456
 Registered Office - Helix Building, West Of Scotland Science Park,
 Glasgow G20 0SP
 Email Disclaimer


 -Original Message-
 From: admiristra...@cox.net [mailto:admiristra...@cox.net]
 Sent: 04 March 2010 16:02
 To: General discussion for Windows Installer XML toolset.;
 b...@joyofsetup.com
 Subject: Re: [WiX-users] Merge Module versioning, or equivalent

 Hi Bob,

 I guess I'm completely missing how to version files then.  I don't find
 any attributes or child elements of component or file that seem related.
 I'm not aware of any consistent file-versioning aspect of the windows
 file systems.  Also, I expect a need to version non-files, such as
 registry entries.

 In my current WiX project, shared items are overwritten with older
 versions and removed without respect for shared dependencies.  I'm
 trying to correct that.  I can't find an example of how versioning and
 sharing files  registry settings is supposed to work.

 Let's say I have two components: a Shared File.txt file and a Shared
 Stuff Version Number registry entry, installed by potentially one, two,
 or three otherwise independent MSIs.

 How can I specify that these components are shared and that reference
 counts(?) ought to be maintained so that installing any one MSI has
 everything it needs to operate, that a second MSI with an older version
 of the shared component does not overwrite the existing shared items but
 does officially depend on the shared components, and that a third MSI
 with a newer version of the shared items overwrites, maintaining MSI 1 
 MSI 2's official dependency on them, AND that the MSIs may be
 uninstalled in any order, leaving the newest version of the shared items
 in place until all three MSIs have been uninstalled at which point no
 items remain.

 It would be acceptable if shared items had to be rolled back to the
 next-most recent version upon un-installation of the most-recent version
 - if that's just how it works.

 Am I off my rocker?  It seems like complicated functionality, but it
 also seems that this would be a capability of the Windows Installer.
 Otherwise, what is this file-versioning for and what are
 reference-counts for?

 Thanks!


 On Wed, Mar 3, 2010 at 6:38 PM, Bob Arnson b...@joyofsetup.com wrote:

  On 3/3/2010 4:14 PM, admiristra...@cox.net wrote:
   Can someone please detail how Merge Module versioning is supposed to
  work?
  
 
  There's no such thing. Merge modules are a collection of tables and
  rows that are merged into your .msi package, losing their identities
  in the process. All versioning is based on component state, which is
  based in part on the file versioning rules documented in the SDK.
 
  What problem are you having?
 
  --
  sig://boB
  http://joyofsetup.com/
 
 
 
  --
   Download Intel#174; Parallel Studio Eval Try the new
  software tools for yourself. Speed compiling, find bugs proactively,
  and fine-tune applications for parallel performance.
  See why Intel Parallel Studio got high marks during beta.
  http://p.sf.net/sfu/intel-sw-dev
  ___
  WiX-users mailing list
  WiX-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wix-users
 
 
 --
 Download Intel#174; Parallel Studio Eval Try the new software tools for
 yourself. Speed compiling, find bugs proactively, and fine-tune
 applications for parallel performance.
 See why Intel Parallel Studio got high marks during beta.
 http://p.sf.net/sfu/intel-sw-dev
 ___
 

[WiX-users] Merge Module versioning, or equivalent

[admiristrator]

Can someone please detail how Merge Module versioning is supposed to work?
I cannot find guidance anywhere for Merge Module versioning (especially in
WiX).  I've seen WiXLibraries, so if that would work better, please tell me
how.

The scenario, which I believe is common:  Certain shared files and registry
settings ought to always be the most up-to-date, installed by any of three
MSIs that contain the shared files.  Any one MSI may be installed alone OR
multiple MSIs may be installed to the same machine.  Uninstallation should
not remove components if they are still used by other installations.
Installation with older shared file/registry settings (as a whole) should
not overwrite newer versions.

I believe that Merge Modules exist for this purpose.  I don't believe that I
need a separate MSI and boot-strapper executable to achieve this
functionality.

I feel pretty comfortable in WiX generally, but I am really struggling with
this.

Thanks.
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] WiX and shared, versioned components

[admiristrator]

This has to be a common need yet I find hardly ANY references to it on the
web...

I've got a product that has three sets of components, one installed on the
server, one on the web head, and one on the developer's machine. All three
sets could be installed on one machine and should peacefully coexist.

As I had it yesterday, each component was installing to a different place
and working ok, but that was just temporary as some files, gac'd assemblies,
and registry settings ought to be shared. Now I've made a merge module out
of the shared components and this new merge-module scenario is working fine
during install under ideal conditions and I've got major upgrades of a
single msi all figured out.

The problem is during installation of an msi when the version of the merge
module within the installing msi is lower than that of the already installed
version (of a different msi) - the newer version is overwritten with the
older version! Furthermore, upon un-installation routine of any of the three
msis, the shared stuff is removed even though it is still in use by the
other installed components.

For the most part I understand why I'm getting this behavior, but I don't
understand how I'm supposed to be configuring my installers so that these
components can be shared WITHOUT having a separate installer for the shared
components. Also, I don't want one big installer either - this won't scale
well.

What I want is that the three installers contain whatever latest version of
the components in the merge module were available at build-time. At install
time, if a newer version of the shared components is installed, don't
overwrite them. At uninstall(and upgrade) time, the reference counts that
should have been tracked would determine whether the shared items should be
removed.

In case I'm just missing something, here are the important parts of the
merge file: My merge module's version number (the y in w.x.y) is
incremented with each build, the package ID remains fixed, and each
component has Shared=yes (although I've tried it without this as well).

I've started storing the various version numbers in the registry, and I
figured maybe I could conditionally install the merge module feature only if
the version number in the registry were absent or lower. But the conditional
arguments can't evaluate w.x.y.z properly, as says the documentation. The
documentation then suggests AppSearch, but AppSearch RegistrySearch can only
check for existence, not version number comparison either. Apparently the
FileSearch can, but the assembly file version numbers will not be
incremented with each build.

And I've read that MergeModules have many problems - maybe these are them -
but wixlibs don't seem to offer any solutions to these problems either.

So what is the right way to do merge module versioning??? I found a book
that has a TOC entry called merge module versioning on Amazon but the book
is out of print. :-P

(Also posted to
http://stackoverflow.com/questions/2329845/wix-and-shared-versioned-components
)
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users