subject:"\[WiX\-users\] Bootstrapper upgrade code detection"

Re: [WiX-users] Bootstrapper upgrade code detection

2011-07-05 Thread Vadym Verba

Hey, Alexander.

Try to use DetectRelatedMsiPackage. It detects installed products based on
Upgrade Code, but not on Product Code.

Best regards,
Vadym

--
Date: Mon, 4 Jul 2011 10:52:50 +0200
From: Alexander Kriv?cs Schr?deralexander.schro...@mermaid.no
Subject: [WiX-users] Bootstrapper upgrade code detection
To: wix-users@lists.sourceforge.net
wix-users@lists.sourceforge.net
Message-ID:
17860180d1bd8c41abece6ac6f36239c6e6ba7d...@htv-mail01.headline.tv
Content-Type: text/plain; charset=iso-8859-1

Hey.

According to the Windows Installer specifications, we change the Product Code
of our product with every release (We just use Product Id=* ... /) and we
keep the Upgrade Code the same. That way, when the individual MSIs are run,
if any previous versions exist, they are first uninstalled.

At the moment, we're making a bootstrapper for our products, and in this
process, we're also making a custom managed GUI. It detects if a product is
already installed (its PackageState is reported as PackageState.Present) or
not installed (PackageState.Absent). However, if a product is installed, but
the bootstrapper contains a newer version of the product, it is reported as
PackageState.Absent, not PackageState.Superseded, like one would expect.

Is there anything in particular we need to do in order to get this upgrade
detection mechanism to work?

Best regards

ALEXANDER K. SCHR?DER
SDL PLC confidential, all rights reserved.
If you are not the intended recipient of this mail SDL requests and requires 
that you delete it without acting upon or copying any of its contents, and we 
further request that you advise us.
SDL PLC is a public limited company registered in England and Wales.  
Registered number: 02675207.
Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, 
UK.


--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Bootstrapper upgrade code detection

2011-07-05 Thread Alexander Krivács Schrøder

I'm using Burn v3.6.1803.0.

Here's the detect section of the log file:

[1708:1F44][2011-07-05T12:35:51.683+01:00]: Detect 11 packages
[1708:1F44][2011-07-05T12:35:52.097+01:00]: Condition 'Netfx4FullVersion AND 
(NOT VersionNT64 OR Netfx4x64FullVersion)' evaluates to true.
[1708:1F44][2011-07-05T12:35:52.097+01:00]: Detected package: Netfx4Full, 
state: Present, cached: No
[1708:1F44][2011-07-05T12:35:52.117+01:00]: Detect 1 msi features for package: 
ReactiveFramework
[1708:1F44][2011-07-05T12:35:52.158+01:00]: Detected feature: ProductFeature, 
state: Local
[1708:1F44][2011-07-05T12:35:52.161+01:00]: Detected package: 
ReactiveFramework, state: Present, cached: No
[1708:1F44][2011-07-05T12:35:52.162+01:00]: Detect 1 msi features for package: 
SyncFramework.Synchronization
[1708:1F44][2011-07-05T12:35:52.174+01:00]: Detected feature: 
Feature_Synchronization_Core, state: Local
[1708:1F44][2011-07-05T12:35:52.174+01:00]: Detected package: 
SyncFramework.Synchronization, state: Present, cached: No
[1708:1F44][2011-07-05T12:35:52.175+01:00]: Detect 1 msi features for package: 
SyncFramework.ProviderServices
[1708:1F44][2011-07-05T12:35:52.176+01:00]: Detected feature: 
Feature_FileSync_Provider, state: Absent
[1708:1F44][2011-07-05T12:35:52.176+01:00]: Detected package: 
SyncFramework.ProviderServices, state: Absent, cached: No
[1708:1F44][2011-07-05T12:35:52.177+01:00]: Detect 1 msi features for package: 
SyncFramework.DatabaseProviders
[1708:1F44][2011-07-05T12:35:52.187+01:00]: Detected feature: OCS_v2.0_Core, 
state: Local
[1708:1F44][2011-07-05T12:35:52.187+01:00]: Detected package: 
SyncFramework.DatabaseProviders, state: Present, cached: No
[1708:1F44][2011-07-05T12:35:52.187+01:00]: Condition 'SqlCeVersion=v3.5.8080.0 
AND SqlCeServicePackLevel=2' evaluates to true.
[1708:1F44][2011-07-05T12:35:52.187+01:00]: Detected package: 
SqlCompactEdition, state: Present, cached: No
[1708:1F44][2011-07-05T12:35:52.190+01:00]: Detect 1 msi features for package: 
Headline.Operations
[1708:1F44][2011-07-05T12:35:52.190+01:00]: Detected feature: 
Operations.Feature, state: Absent
[1708:1F44][2011-07-05T12:35:52.190+01:00]: Detected package: 
Headline.Operations, state: Absent, cached: No
[1708:1F44][2011-07-05T12:35:52.192+01:00]: Detect 1 msi features for package: 
Headline.ChannelBuilder
[1708:1F44][2011-07-05T12:35:52.192+01:00]: Detected feature: 
ChannelBuilder.Feature, state: Absent
[1708:1F44][2011-07-05T12:35:52.214+01:00]: Detected package: 
Headline.ChannelBuilder, state: Absent, cached: No
[1708:1F44][2011-07-05T12:35:52.224+01:00]: Detect 3 msi features for package: 
Headline.Client
[1708:1F44][2011-07-05T12:35:52.224+01:00]: Detected feature: 
PublicEnvironmentVariable.Feature, state: Absent
[1708:1F44][2011-07-05T12:35:52.230+01:00]: Detected feature: 
ClientPDB.Feature, state: Absent
[1708:1F44][2011-07-05T12:35:52.230+01:00]: Detected feature: Client.Feature, 
state: Absent
[1708:1F44][2011-07-05T12:35:52.230+01:00]: Detected package: Headline.Client, 
state: Absent, cached: No
[1708:1F44][2011-07-05T12:35:52.235+01:00]: Detect 1 msi features for package: 
Headline.Agent
[1708:1F44][2011-07-05T12:35:52.235+01:00]: Detected feature: Agent.Feature, 
state: Absent
[1708:1F44][2011-07-05T12:35:52.243+01:00]: Detected package: Headline.Agent, 
state: Absent, cached: No
[1708:1F44][2011-07-05T12:35:52.248+01:00]: Detect 5 msi features for package: 
Headline.Player
[1708:1F44][2011-07-05T12:35:52.248+01:00]: Detected feature: DirectXRedist, 
state: Absent
[1708:1F44][2011-07-05T12:35:52.270+01:00]: Detected feature: 
AppConfig.Feature, state: Absent
[1708:1F44][2011-07-05T12:35:52.270+01:00]: Detected feature: 
Player.Plugins.Feature, state: Absent
[1708:1F44][2011-07-05T12:35:52.270+01:00]: Detected feature: Player.Feature, 
state: Absent
[1708:1F44][2011-07-05T12:35:52.271+01:00]: Detected feature: 
PlayerPDB.Feature, state: Absent
[1708:1F44][2011-07-05T12:35:52.274+01:00]: Detected package: Headline.Player, 
state: Absent, cached: No
[1708:1F44][2011-07-05T12:35:52.279+01:00]: Detect complete, result: 0x0

The relevant package here is Headline.Agent. It is installed with version 
3.5.10617 and this bootstrapper has version 3.5.10704.

Best regards

ALEXANDER K. SCHRØDER

-Original Message-
From: Rob Mensching [mailto:r...@robmensching.com] 
Sent: 4. juli 2011 19:27
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Bootstrapper upgrade code detection

What version of Burn are you using? Can you share out the detect section of the 
Burn log file?

On Mon, Jul 4, 2011 at 4:58 AM, Rob Hamflett r...@snsys.com wrote:

 Ah.  I haven't looked at Burn.  Sorry.  Hopefully someone else has the 
 answer to that one.

 Rob

 On 04/07/2011 12:13, Alexander Krivács Schrøder wrote:
  Hi Rob.
 
  I probably should have mentioned that the bootstrapper we're using 
  is
 WiX's burn, and the managed GUI we're making is for it. The 
 BootstrapperApplication class has an event

Re: [WiX-users] Bootstrapper upgrade code detection

2011-07-05 Thread Rob Mensching

 and this bootstrapper has version 3.5.10704.

 Best regards

 ALEXANDER K. SCHRØDER

 -Original Message-
 From: Rob Mensching [mailto:r...@robmensching.com]
 Sent: 4. juli 2011 19:27
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] Bootstrapper upgrade code detection

 What version of Burn are you using? Can you share out the detect section of
 the Burn log file?

 On Mon, Jul 4, 2011 at 4:58 AM, Rob Hamflett r...@snsys.com wrote:

  Ah.  I haven't looked at Burn.  Sorry.  Hopefully someone else has the
  answer to that one.

  Rob

  On 04/07/2011 12:13, Alexander Krivács Schrøder wrote:
   Hi Rob.

   I probably should have mentioned that the bootstrapper we're using
   is
  WiX's burn, and the managed GUI we're making is for it. The
  BootstrapperApplication class has an event called
  DetectPackageComplete. In this event, one gets the following EventArgs
 class:

public class DetectPackageCompleteEventArgs
{
public string PackageId { get; }
public PackageState State { get; }
}

   It is this PackageState I am talking about; it doesn't get set to
   what we
  expect, as I mentioned in my first mail.

   Best regards

   ALEXANDER K. SCHRØDER

   -Original Message-
   From: Rob Hamflett [mailto:r...@snsys.com]
   Sent: 4. juli 2011 11:25
   To: wix-users@lists.sourceforge.net
   Subject: Re: [WiX-users] Bootstrapper upgrade code detection

   If you were using native code, then you'd want
 MsiEnumRelatedProducts().
   A Google search provides a bunch of links with info on how to call it
  from C#.  I don't know if you're using C# or VB, but a bit of
  searching around that function name should get you there.

   Rob

   On 04/07/2011 09:52, Alexander Krivács Schrøder wrote:
   Hey.

   According to the Windows Installer specifications, we change the
   Product
  Code of our product with every release (We just useProduct Id=* ...
  /) and we keep the Upgrade Code the same. That way, when the
  individual MSIs are run, if any previous versions exist, they are first
 uninstalled.

   At the moment, we're making a bootstrapper for our products, and in
   this
  process, we're also making a custom managed GUI. It detects if a
  product is already installed (its PackageState is reported as
  PackageState.Present) or not installed (PackageState.Absent). However,
  if a product is installed, but the bootstrapper contains a newer
  version of the product, it is reported as PackageState.Absent, not
 PackageState.Superseded, like one would expect.

   Is there anything in particular we need to do in order to get this
  upgrade detection mechanism to work?

   Best regards

   ALEXANDER K. SCHRØDER

   ---
   ---
    All of the data generated in your IT infrastructure is
   seriously valuable.
   Why? It contains a definitive record of application performance,
   security threats, fraudulent activity, and more. Splunk takes this
   data and makes sense of it. IT sense. And common sense.
   http://p.sf.net/sfu/splunk-d2d-c2

  --

   All of the data generated in your IT infrastructure is seriously
  valuable.
   Why? It contains a definitive record of application performance,
   security
  threats, fraudulent activity, and more. Splunk takes this data and
  makes sense of it. IT sense. And common sense.
   http://p.sf.net/sfu/splunk-d2d-c2
   ___
   WiX-users mailing list
   WiX-users@lists.sourceforge.net
   https://lists.sourceforge.net/lists/listinfo/wix-users

  --

   All of the data generated in your IT infrastructure is seriously
  valuable.
   Why? It contains a definitive record of application performance,
   security threats, fraudulent activity, and more. Splunk takes this
   data and makes sense of it. IT sense. And common sense.
   http://p.sf.net/sfu/splunk-d2d-c2

  --
   All of the data generated in your IT infrastructure is
  seriously valuable.
  Why? It contains a definitive record of application performance,
  security threats, fraudulent activity, and more. Splunk takes this
  data and makes sense of it. IT sense. And common sense.
  http://p.sf.net/sfu/splunk-d2d-c2
  ___
  WiX-users mailing list
  WiX-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wix-users

 --
 virtually, Rob Mensching - http://RobMensching.com LLC

 --
 All of the data generated in your IT infrastructure is seriously valuable.
 Why? It contains a definitive record of application

[WiX-users] Bootstrapper upgrade code detection

2011-07-04 Thread Alexander Krivács Schrøder

Hey.

According to the Windows Installer specifications, we change the Product Code 
of our product with every release (We just use Product Id=* ... /) and we 
keep the Upgrade Code the same. That way, when the individual MSIs are run, if 
any previous versions exist, they are first uninstalled.

At the moment, we're making a bootstrapper for our products, and in this 
process, we're also making a custom managed GUI. It detects if a product is 
already installed (its PackageState is reported as PackageState.Present) or not 
installed (PackageState.Absent). However, if a product is installed, but the 
bootstrapper contains a newer version of the product, it is reported as 
PackageState.Absent, not PackageState.Superseded, like one would expect.

Is there anything in particular we need to do in order to get this upgrade 
detection mechanism to work?

Best regards

ALEXANDER K. SCHRØDER

--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Bootstrapper upgrade code detection

2011-07-04 Thread Rob Hamflett

If you were using native code, then you'd want MsiEnumRelatedProducts().  A 
Google search provides a 
bunch of links with info on how to call it from C#.  I don't know if you're 
using C# or VB, but a 
bit of searching around that function name should get you there.

Rob

On 04/07/2011 09:52, Alexander Krivács Schrøder wrote:
 Hey.

 According to the Windows Installer specifications, we change the Product Code 
 of our product with every release (We just useProduct Id=* ... /) and we 
 keep the Upgrade Code the same. That way, when the individual MSIs are run, 
 if any previous versions exist, they are first uninstalled.

 At the moment, we're making a bootstrapper for our products, and in this 
 process, we're also making a custom managed GUI. It detects if a product is 
 already installed (its PackageState is reported as PackageState.Present) or 
 not installed (PackageState.Absent). However, if a product is installed, but 
 the bootstrapper contains a newer version of the product, it is reported as 
 PackageState.Absent, not PackageState.Superseded, like one would expect.

 Is there anything in particular we need to do in order to get this upgrade 
 detection mechanism to work?

 Best regards

 ALEXANDER K. SCHRØDER

 --
 All of the data generated in your IT infrastructure is seriously valuable.
 Why? It contains a definitive record of application performance, security
 threats, fraudulent activity, and more. Splunk takes this data and makes
 sense of it. IT sense. And common sense.
 http://p.sf.net/sfu/splunk-d2d-c2


--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Bootstrapper upgrade code detection

2011-07-04 Thread Alexander Krivács Schrøder

Hi Rob.

I probably should have mentioned that the bootstrapper we're using is WiX's 
burn, and the managed GUI we're making is for it. The BootstrapperApplication 
class has an event called DetectPackageComplete. In this event, one gets the 
following EventArgs class:

public class DetectPackageCompleteEventArgs
{
public string PackageId { get; }
public PackageState State { get; }
}

It is this PackageState I am talking about; it doesn't get set to what we 
expect, as I mentioned in my first mail. 

Best regards

ALEXANDER K. SCHRØDER

-Original Message-
From: Rob Hamflett [mailto:r...@snsys.com] 
Sent: 4. juli 2011 11:25
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Bootstrapper upgrade code detection

If you were using native code, then you'd want MsiEnumRelatedProducts().  A 
Google search provides a bunch of links with info on how to call it from C#.  I 
don't know if you're using C# or VB, but a bit of searching around that 
function name should get you there.

Rob

On 04/07/2011 09:52, Alexander Krivács Schrøder wrote:
 Hey.

 According to the Windows Installer specifications, we change the Product Code 
 of our product with every release (We just useProduct Id=* ... /) and we 
 keep the Upgrade Code the same. That way, when the individual MSIs are run, 
 if any previous versions exist, they are first uninstalled.

 At the moment, we're making a bootstrapper for our products, and in this 
 process, we're also making a custom managed GUI. It detects if a product is 
 already installed (its PackageState is reported as PackageState.Present) or 
 not installed (PackageState.Absent). However, if a product is installed, but 
 the bootstrapper contains a newer version of the product, it is reported as 
 PackageState.Absent, not PackageState.Superseded, like one would expect.

 Is there anything in particular we need to do in order to get this upgrade 
 detection mechanism to work?

 Best regards

 ALEXANDER K. SCHRØDER

 --
  All of the data generated in your IT infrastructure is 
 seriously valuable.
 Why? It contains a definitive record of application performance, 
 security threats, fraudulent activity, and more. Splunk takes this 
 data and makes sense of it. IT sense. And common sense.
 http://p.sf.net/sfu/splunk-d2d-c2


--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes sense 
of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Bootstrapper upgrade code detection

2011-07-04 Thread Rob Hamflett

Ah.  I haven't looked at Burn.  Sorry.  Hopefully someone else has the answer 
to that one.

Rob

On 04/07/2011 12:13, Alexander Krivács Schrøder wrote:
 Hi Rob.

 I probably should have mentioned that the bootstrapper we're using is WiX's 
 burn, and the managed GUI we're making is for it. The BootstrapperApplication 
 class has an event called DetectPackageComplete. In this event, one gets the 
 following EventArgs class:

  public class DetectPackageCompleteEventArgs
  {
  public string PackageId { get; }
  public PackageState State { get; }
  }

 It is this PackageState I am talking about; it doesn't get set to what we 
 expect, as I mentioned in my first mail.

 Best regards

 ALEXANDER K. SCHRØDER

 -Original Message-
 From: Rob Hamflett [mailto:r...@snsys.com]
 Sent: 4. juli 2011 11:25
 To: wix-users@lists.sourceforge.net
 Subject: Re: [WiX-users] Bootstrapper upgrade code detection

 If you were using native code, then you'd want MsiEnumRelatedProducts().  A 
 Google search provides a bunch of links with info on how to call it from C#.  
 I don't know if you're using C# or VB, but a bit of searching around that 
 function name should get you there.

 Rob

 On 04/07/2011 09:52, Alexander Krivács Schrøder wrote:
 Hey.

 According to the Windows Installer specifications, we change the Product 
 Code of our product with every release (We just useProduct Id=* ... /) 
 and we keep the Upgrade Code the same. That way, when the individual MSIs 
 are run, if any previous versions exist, they are first uninstalled.

 At the moment, we're making a bootstrapper for our products, and in this 
 process, we're also making a custom managed GUI. It detects if a product is 
 already installed (its PackageState is reported as PackageState.Present) or 
 not installed (PackageState.Absent). However, if a product is installed, but 
 the bootstrapper contains a newer version of the product, it is reported as 
 PackageState.Absent, not PackageState.Superseded, like one would expect.

 Is there anything in particular we need to do in order to get this upgrade 
 detection mechanism to work?

 Best regards

 ALEXANDER K. SCHRØDER

 --
  All of the data generated in your IT infrastructure is
 seriously valuable.
 Why? It contains a definitive record of application performance,
 security threats, fraudulent activity, and more. Splunk takes this
 data and makes sense of it. IT sense. And common sense.
 http://p.sf.net/sfu/splunk-d2d-c2


 --
 All of the data generated in your IT infrastructure is seriously valuable.
 Why? It contains a definitive record of application performance, security 
 threats, fraudulent activity, and more. Splunk takes this data and makes 
 sense of it. IT sense. And common sense.
 http://p.sf.net/sfu/splunk-d2d-c2
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users



 --
 All of the data generated in your IT infrastructure is seriously valuable.
 Why? It contains a definitive record of application performance, security
 threats, fraudulent activity, and more. Splunk takes this data and makes
 sense of it. IT sense. And common sense.
 http://p.sf.net/sfu/splunk-d2d-c2


--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Bootstrapper upgrade code detection

2011-07-04 Thread Rob Mensching

What version of Burn are you using? Can you share out the detect section of
the Burn log file?

On Mon, Jul 4, 2011 at 4:58 AM, Rob Hamflett r...@snsys.com wrote:

 Ah.  I haven't looked at Burn.  Sorry.  Hopefully someone else has the
 answer to that one.

 Rob

 On 04/07/2011 12:13, Alexander Krivács Schrøder wrote:
  Hi Rob.
 
  I probably should have mentioned that the bootstrapper we're using is
 WiX's burn, and the managed GUI we're making is for it. The
 BootstrapperApplication class has an event called DetectPackageComplete. In
 this event, one gets the following EventArgs class:
 
   public class DetectPackageCompleteEventArgs
   {
   public string PackageId { get; }
   public PackageState State { get; }
   }
 
  It is this PackageState I am talking about; it doesn't get set to what we
 expect, as I mentioned in my first mail.
 
  Best regards
 
  ALEXANDER K. SCHRØDER
 
  -Original Message-
  From: Rob Hamflett [mailto:r...@snsys.com]
  Sent: 4. juli 2011 11:25
  To: wix-users@lists.sourceforge.net
  Subject: Re: [WiX-users] Bootstrapper upgrade code detection
 
  If you were using native code, then you'd want MsiEnumRelatedProducts().
  A Google search provides a bunch of links with info on how to call it from
 C#.  I don't know if you're using C# or VB, but a bit of searching around
 that function name should get you there.
 
  Rob
 
  On 04/07/2011 09:52, Alexander Krivács Schrøder wrote:
  Hey.
 
  According to the Windows Installer specifications, we change the Product
 Code of our product with every release (We just useProduct Id=* ... /)
 and we keep the Upgrade Code the same. That way, when the individual MSIs
 are run, if any previous versions exist, they are first uninstalled.
 
  At the moment, we're making a bootstrapper for our products, and in this
 process, we're also making a custom managed GUI. It detects if a product is
 already installed (its PackageState is reported as PackageState.Present) or
 not installed (PackageState.Absent). However, if a product is installed, but
 the bootstrapper contains a newer version of the product, it is reported as
 PackageState.Absent, not PackageState.Superseded, like one would expect.
 
  Is there anything in particular we need to do in order to get this
 upgrade detection mechanism to work?
 
  Best regards
 
  ALEXANDER K. SCHRØDER
 
  --
   All of the data generated in your IT infrastructure is
  seriously valuable.
  Why? It contains a definitive record of application performance,
  security threats, fraudulent activity, and more. Splunk takes this
  data and makes sense of it. IT sense. And common sense.
  http://p.sf.net/sfu/splunk-d2d-c2
 
 
 
 --
  All of the data generated in your IT infrastructure is seriously
 valuable.
  Why? It contains a definitive record of application performance, security
 threats, fraudulent activity, and more. Splunk takes this data and makes
 sense of it. IT sense. And common sense.
  http://p.sf.net/sfu/splunk-d2d-c2
  ___
  WiX-users mailing list
  WiX-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wix-users
 
 
 
 
 --
  All of the data generated in your IT infrastructure is seriously
 valuable.
  Why? It contains a definitive record of application performance, security
  threats, fraudulent activity, and more. Splunk takes this data and makes
  sense of it. IT sense. And common sense.
  http://p.sf.net/sfu/splunk-d2d-c2



 --
 All of the data generated in your IT infrastructure is seriously valuable.
 Why? It contains a definitive record of application performance, security
 threats, fraudulent activity, and more. Splunk takes this data and makes
 sense of it. IT sense. And common sense.
 http://p.sf.net/sfu/splunk-d2d-c2
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users




-- 
virtually, Rob Mensching - http://RobMensching.com LLC
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Bootstrapper upgrade code detection

Re: [WiX-users] Bootstrapper upgrade code detection

Re: [WiX-users] Bootstrapper upgrade code detection

[WiX-users] Bootstrapper upgrade code detection

Re: [WiX-users] Bootstrapper upgrade code detection

Re: [WiX-users] Bootstrapper upgrade code detection

Re: [WiX-users] Bootstrapper upgrade code detection

Re: [WiX-users] Bootstrapper upgrade code detection

8 matches

Site Navigation

Mail list logo

Footer information