For the "uninstall handler" (meaning the application which uninstalls
the MSIs) I'd recommend to use the UpgradeCode to query the
ProductCode to get more flexibility. Following DTF code sample
illustrates that and uninstalls here the Microsoft SQL Server Compact
3.5 (or other versions sharing the UpgradeCode
{F44C4920-99B1-4F6E-9B75-1B22A3AC908A}):
[CustomAction]
public static ActionResult CustomAction1(Session session)
/// <example>
/// Sample how this could be used in WiX file:
/// <code lang="xml">
/// <![CDATA[
/// <Wix>
/// <Product>
///
/// <!-- Add dll library of CA to binary stream -->
/// <Binary Id="CADLL"
SourceFile="$(var.SolutionDir)\CustomAction1\bin\Debug\CustomAction1.CA.dll"/>
///
/// <!-- Definition and sequencing of the CA -->
/// <CustomAction Id="CustomAction1" BinaryKey="CADLL"
DllEntry="CustomAction1" Execute="firstSequence"/>
/// <InstallUISequence>
/// <Custom Action="CustomAction1" Before="FindRelatedProducts"/>
/// </InstallUISequence>
/// </Product>
/// </Wix>
/// ]]>
/// </code>
/// </example>
///
{
// use debugger ?
// System.Diagnostics.Debugger.Launch();
session.Log("Begin CustomAction1");
foreach (ProductInstallation product in
ProductInstallation.GetRelatedProducts("{F44C4920-99B1-4F6E-9B75-1B22A3AC908A}"))
{
DialogResult dr = MessageBox.Show("Microsoft SQL
Server Compact detected. Should it be uninstalled?",
"Question", MessageBoxButtons.YesNo);
switch (dr)
{
case DialogResult.Yes:
{
// get for the product with the above
stated UpgradeCode the ProductCode and uninstall it
Installer.ConfigureProduct(product.ProductCode.ToString(), 0,
InstallState.Absent, "");
MessageBox.Show("Application uninstalled!");
}
break;
case DialogResult.No:
break;
}
}
return ActionResult.Success;
}
2011/2/17 Pally Sandher <pally.sand...@iesve.com>:
> 1 - What I would like is for the extension installers to refuse being
> installed if the main application isn't installed.
> This is easily supported using LaunchConditions in an MSI. Simply use
> something like a RegistrySearch to populate a property with something
> your main product installs then use this Property for the Condition. If
> your main product is installed, the RegistrySearch succeeds, sets the
> Property & the LaunchCondition evaluates to true to allow installation
> of the extension.
>
> 2 - Furthermore I would like the extension installers to be removed if
> the main application is removed, but NOT if it is being upgraded.
> I don't think this is supported using an MSI (Concurrent Installation
> isn't supported so I don't expect Concurrent Uninstallation to be
> supported either, could be wrong but I highly doubt it).
> You could however manually write your Add/Remove Programs entries & use
> an executable to handle this. Essentially you're circumventing the
> normal uninstall process from the Control Panel & inserting an
> executable in between. That is a lot more work to do properly as you'd
> need some central location listing all the extensions installed on a
> system which the executable then uninstalls along with your main
> product. Not too difficult as all you really need is the GUID stored in
> the registry so you can run "msiexec /x {ProductGUID}" from your
> executable for each extension & the main product it self.
>
> That's probably the easiest way to achieve what you want to do if you
> want to continue using Major Upgrades for the main product and/or
> extensions. There are ways you could achieve this using patching but
> depending on the number of extensions you ship it could become very
> unwieldy very quickly.
>
> Palbinder Sandher
> Software Deployment Engineer
> 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: Thomas Due [mailto:t...@scanvaegt.dk]
> Sent: 17 February 2011 12:49
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Best practice for making dependent installers
>
> No one?
>
> /Thomas Due
>
> -----Original Message-----
> From: Thomas Due [mailto:t...@scanvaegt.dk]
> Sent: 11. februar 2011 09:00
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Best practice for making dependent installers
>
> Hi,
>
> I am maintaining the installer for our main product. This product is
> extensible and I was wondering how I would go about making installers
> for our extensions?
>
> What I would like is for the extension installers to refuse being
> installed if the main application isn't installed.
> Furthermore I would like the extension installers to be removed if the
> main application is removed, but NOT if it is being upgraded.
> Currently I am not using patching or minor upgrades, only major upgrades
> for our main product.
>
> What we do today is essentially copying the extension assemblies into
> the folder of the main application, and then it automatically detects
> the new extensions and loads them (after a restart). Sometimes we need
> to tweak or change some settings which we then do either by hand, or by
> a small application designed to handle the specific settings.
>
> I would really like a general scheme for deployment extensions, but my
> knowledge and understanding of WiX and MSI is not so complete that I can
> think my way through the problem on my own. So I turn to you for some
> tips, guidelines and suggestions?
>
> I am happy to provide more information should it be needed.
>
> /Thomas Due
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------
> ------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio
> XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
