Re: [WiX-users] Reopen Burn triggers virus checker - ID: 3431068

2012-01-12 Thread Rob Mensching
MSI doesn't write to RunOnce because it is a system service that came
installed in the operating system. Pretty much all bootstrappers/chainers
will write to RunOnce if they need to do a reboot and come back
afterwards.  Burn goes one step further to ensure robustness and registers
up front.

We'll need to teach this anti-virus program about Burn. Fortunately big
programs, like Visual Studio, are using Burn and if it kills them I hope we
can muster some change.

On Wed, Jan 11, 2012 at 11:50 PM, NIkolaj Steensgaard n...@panorama9.comwrote:

 On 01/11/2012 01:23 PM, Peter Hull wrote:
 
  Hi Nikolaj!
 
  Could you comment on whether your installer was signed (the bundle and
 the actual engine which is unpacked out of it - see this link
 https://sourceforge.net/mailarchive/forum.php?thread_name=CAHdHTVc1c2h3QuYsiXWcR8A1Xtk38Z3W2KCyAvuP3hMjYqKAiA%40mail.gmail.comforum_name=wix-users)
 Yes the Bundle is signed with Thawte code signing certificate and also
 the engine ( msi ) included is signed with same certificate.
 
  I'm glad someone else has seen this problem, especially as you have more
 control over your environment than I do!
 Me 2 as it is quite a problem not being able to install a exe created
 from Wix 3.6.
 Does anyone have a Idea how to debug this issue ?

 The MSI itself does not write to the RunOnce as far as i know 
 
  Peter
 
 
  Date: Wed, 11 Jan 2012 12:16:37 +0100
  From: n...@panorama9.com
  To: wix-users@lists.sourceforge.net
  Subject: [WiX-users] Reopen Burn triggers virus checker - ID: 3431068
 
  We have built a EXE with Wix 3.6 beta which are detected by Trend Micro
  as Malware behavior and
  we are looking for the reason for this.
 
  This is the log entry from Trend Micro
 
 ---
  Malware behavior blocking Terminate Registry High
  C:\Documents and Settings\administrator.ADTEST\Local
 
 Settings\Temp\{044fc46d-90ff-4769-9c96-28a774dcbd7a}\.be\copy-yvxrlsay.iz2-P9Agent.exe
 
 
  Write
 
 HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce\{044fc46d-90ff-4769-9c96-28a774dcbd7a}
 
 
 ---
 
  Snip from previous case:
 
 ---
  Burn-based installers trigger Trend OfficeScan (v.10.5) when they write
  to the RunOnce registry key.
  The virus checker terminates the installer immediately.
 
 ---
 
  We have a complete testing enviroment where we can tweak, monitor and
  reproduce this error and are more than
  willing to assist in debugging this issue.
 
  Please let me know anything we can provide to debug and solve this
 
  Regards
 
  Nikolaj Steensgaard
 
 
 
 --
  Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a
 complex
  infrastructure or vast IT resources to deliver seamless, secure access
 to
  virtual desktops. With this all-in-one solution, easily deploy virtual
  desktops for less than the cost of PCs and save 60% on VDI
 infrastructure
  costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
  ___
  WiX-users mailing list
  WiX-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wix-users
 
 
 --
  Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
  infrastructure or vast IT resources to deliver seamless, secure access to
  virtual desktops. With this all-in-one solution, easily deploy virtual
  desktops for less than the cost of PCs and save 60% on VDI infrastructure
  costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
  ___
  WiX-users mailing list
  WiX-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wix-users



 --
 RSA(R) Conference 2012
 Mar 27 - Feb 2
 Save $400 by Jan. 27
 Register now!
 http://p.sf.net/sfu/rsa-sfdev2dev2
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users




-- 
virtually, Rob Mensching - http://RobMensching.com LLC
--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Reopen Burn triggers virus checker - ID: 3431068

2012-01-12 Thread Peter Hull

 From: r...@robmensching.com
 We'll need to teach this anti-virus program about Burn. Fortunately big
 programs, like Visual Studio, are using Burn and if it kills them I hope we
 can muster some change.

So are you saying we need to raise this as an issue with Trend Micro? Is the 
program that actually writes the registry always the same? (I'm a bit confused 
about what the stages are when a burn exe is run, particularly what the burn 
engine is and what the burn agent is)

Pete

  
--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Signing the burn bootstrapper

2012-01-12 Thread Peter Hull

To sign the bundle and bundle engine you need to add the following to your 
.wixproj:
Add SignOutputtrue/SignOutput to a PropertyGroup
Implement the targets like this:
    Target Name=SignBundleEngine
        SignFile TimestampUrl=... CertificateThumbprint=... 
SigningTarget=@(SignBundleEngine) /
    /Target
    Target Name=SignBundle 
        SignFile TimestampUrl=... CertificateThumbprint=... 
SigningTarget=@(SignBundle) /
    /Target
You need to put these _after_ the Import Project=$(WixTargetsPath) /

Alternatively you can use Exec Command='signtool.exe sign ...' / for more 
control.

There is also a SignContainers target but I don't know quite what it does.

When buiding MSIs, to sign them you need to implement Target Name=SignMsi

If you have external CABs then also implement Target Name=SignCabs

The things you need to sign are in an itemgroup with the same name as the 
target (e.g. @(SignMsi))

Note that you can't use the SignFile task for this, as it will only sign exes 
and dlls. You have to use Exec Command=signtool sign ... /

Hope that helps,

Pete



  
--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Applying a patch (.msp) doesn't increase the product version

2012-01-12 Thread Ulrich Proeller
When examining the files with an administrative install, the files in the two 
.msi files are definitely different.
When I change the file size of the text file, the file is included in the 
patch.  But if the file size is the same as the file size of the original file, 
it isn't included into the patch.

As far as I can see now, torch.exe does the following:
1. If a file has a version (.exe, .dll), that version is checked to determine 
if the file has changed.
2. If a file has no version, it is simply checked if the file size has changed. 
If the size is unchanged, the file is considered as unchanged.

This appears to me to be a bug in torch.exe.
I would try to find and fix this bug in torch.exe now as I really need to 
reliably create patches.

Besides this, I think that in Wix 3.6 Beta, the patch creation is broken 
(torch.exe or pyro.exe). When I apply the 3.6 toolset to the same files which 
successfully created a patch file with WIX 3.5, I get an warning about an empty 
cabinet.

-Ursprüngliche Nachricht-
Von: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] 
Gesendet: Mittwoch, 11. Januar 2012 13:13
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] Applying a patch (.msp) doesn't increase the product 
version

It all looks reasonable. I'd probably go back and examine the text file in the 
2 MSIs that you're building the patch from. It could be a build problem.
Do an administrative install of both MSIs and the version of the text file from 
each admin install.

-Original Message-
From: Ulrich Proeller [mailto:ulr...@prosa.biz]
Sent: 11 January 2012 11:29
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Applying a patch (.msp) doesn't increase the product 
version

I think that the patch doesn't include this text file. At least ORCA shows only 
the file Szenariorechner.exe to be changed by the patch. The file 
Version.txt is marked as unchanged.

-Ursprüngliche Nachricht-
Von: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com]
Gesendet: Mittwoch, 11. Januar 2012 12:21
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] Applying a patch (.msp) doesn't increasethe product 
version

I'd generate a verbose log while installing the patch to try and work out why 
the text file is not updated.
 
The product version is just a property like any other and often seems not to be 
mentioned specially. That confused me when I wrote my first patch.

-Original Message-
From: Ulrich Proeller [mailto:ulr...@prosa.biz]
Sent: 11 January 2012 11:00
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Applying a patch (.msp) doesn't increasethe product 
version

Thank you, this helps me a huge step forward.

Referencing the ProductVersion changes the version as desired.  Is this written 
in any documentation/book and I have overlooked it?
And I didn't know about the View Patch feature in Orca. This makes life a lot 
easier!

My patch family now looks like this:
PatchFamily Id='pfSzenariorechner' Version='1.2.7.0' Supersede='yes'
  ComponentRef Id=Szenariorechner /
  PropertyRef Id=ProductVersion/
  ComponentRef Id=VersionFile /
/PatchFamily

However, the text file with the version  string is still not replaced. This is 
a separate component, in the same component group as the managed assembly and 
both are in the same fragment. I read that it should be enough to reference one 
component in each fragment to trigger the inclusion of all components in that 
fragment.
Nevertheless, even referencing it explicitly doesn't help.

Below, you see the definition of the mentioned fragment:

  Fragment
ComponentGroup Id=Szenariorechner
  Component Id=Szenariorechner
Guid=c447f464-15ac-4dc3-8456-623197bd6a71 Directory=INSTALLFOLDER
File Id=Szenariorechner.exe
Name=$(var.Szenariorechner.TargetFileName) Vital='yes' Checksum='yes'
AssemblyApplication='Szenariorechner.exe'
  Source=$(var.Szenariorechner.TargetPath) DiskId=1
Assembly='.net' KeyPath=yes
  netfx:NativeImage Id=ngen.Szenariorechner Platform=all
Priority=1 AppBaseDirectory=INSTALLFOLDER/
/File
File Id=Szenariorechner.exe.config
Name=$(var.Szenariorechner.TargetFileName).config Vital='yes'
Source=$(var.Szenariorechner.TargetPath).config DiskId=1 /
File Id='Szenariorechner.ico' Name='Szenariorechner.ico' Vital='yes'
Source='$(var.Szenariorechner.ProjectDir)Resources\favicon.ico' DiskId='1' /
  /Component
  Component Id='VersionFile' Guid='037d742c-583f-414b-acad-f99907a4b7d1'
Directory=INSTALLFOLDER
File Id=FILE_Version
Source=$(var.Szenariorechner.TargetDir)Version.txt KeyPath=yes /
  /Component
/ComponentGroup

ComponentGroup Id='Shortcuts' 
.
/ComponentGroup

ComponentGroup Id=Telerik

/ComponentGroup

ComponentGroup Id=Misc
  

Re: [WiX-users] Reopen Burn triggers virus checker - ID: 3431068

2012-01-12 Thread NIkolaj Steensgaard
On 01/12/2012 09:46 AM, Peter Hull wrote:
 From: r...@robmensching.com
 We'll need to teach this anti-virus program about Burn. Fortunately big
 programs, like Visual Studio, are using Burn and if it kills them I hope we
 can muster some change.
 So are you saying we need to raise this as an issue with Trend Micro?
I have been trying to debug this issue to answer that exact question !
 Is the program that actually writes the registry always the same? (I'm a bit 
 confused about what the stages are when a burn exe is run, particularly what 
 the burn engine is and what the burn agent is)
I will explain the issue more detailed to better give insight in what we 
are seeing.

For about year we have been deploying our software build with the WIX 
installer as a MSI package and have not seen this issue.

To Months ago we created a Bundled version ( exe build with WIX 3.6 )  
that checked for .net 3.51 + Win install 3.1 and
installed if needed before installing our software

Then we got reports from client's about this issue occurring

The Bundled version is quite simple and only checks for the above 
mentioned software and downloads / installs if needed

A complete AD with Trend Micro Office Scan were established to reproduce 
the error which we can.

Some things that we so far have noticed :

It only seem to occur on Windows XP for some reason.  ( this machine 
already have the needed .net and Win install so it's not there installer 
that's creates the problem )
Our Code does not at anytime write or read from the RunOnce key
Also as the previous reporter of this issue ( ID: 3431068 )

We will be trying to use SysInternals tools to get a debug of whats 
happening when the issue occurs, and post the result here.

Hope this helps in explaining the issue we are seeing and we are more 
that happy to run any test's you suggest !!!

Nik



 Pete

   
 --
 RSA(R) Conference 2012
 Mar 27 - Feb 2
 Save $400 by Jan. 27
 Register now!
 http://p.sf.net/sfu/rsa-sfdev2dev2
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users


--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Applying a patch (.msp) doesn't increasethe product version

2012-01-12 Thread Peter Shirtcliffe
Can you verify this by producing a minimum test case ? Create an MSI with
just 1 text file and an upgrade and a patch from that. It might help you
narrow down what's going wrong. 
The .wixmst produced by torch is an xml file containing all the changes
between the two inputs, even if they are not referenced by the patch wxs
file. It might be worth looking through it for your text file name. It should
be in there.

-Original Message-
From: Ulrich Proeller [mailto:ulr...@prosa.biz] 
Sent: 12 January 2012 09:34
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Applying a patch (.msp) doesn't increasethe product
version

When examining the files with an administrative install, the files in the two
.msi files are definitely different.
When I change the file size of the text file, the file is included in the
patch.  But if the file size is the same as the file size of the original
file, it isn't included into the patch.

As far as I can see now, torch.exe does the following:
1. If a file has a version (.exe, .dll), that version is checked to determine
if the file has changed.
2. If a file has no version, it is simply checked if the file size has
changed. If the size is unchanged, the file is considered as unchanged.

This appears to me to be a bug in torch.exe.
I would try to find and fix this bug in torch.exe now as I really need to
reliably create patches.

Besides this, I think that in Wix 3.6 Beta, the patch creation is broken
(torch.exe or pyro.exe). When I apply the 3.6 toolset to the same files which
successfully created a patch file with WIX 3.5, I get an warning about an
empty cabinet.

-Ursprüngliche Nachricht-
Von: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] 
Gesendet: Mittwoch, 11. Januar 2012 13:13
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] Applying a patch (.msp) doesn't increase the product
version

It all looks reasonable. I'd probably go back and examine the text file in
the 2 MSIs that you're building the patch from. It could be a build problem.
Do an administrative install of both MSIs and the version of the text file
from each admin install.

-Original Message-
From: Ulrich Proeller [mailto:ulr...@prosa.biz]
Sent: 11 January 2012 11:29
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Applying a patch (.msp) doesn't increase the product
version

I think that the patch doesn't include this text file. At least ORCA shows
only the file Szenariorechner.exe to be changed by the patch. The file
Version.txt is marked as unchanged.

-Ursprüngliche Nachricht-
Von: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com]
Gesendet: Mittwoch, 11. Januar 2012 12:21
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] Applying a patch (.msp) doesn't increasethe product
version

I'd generate a verbose log while installing the patch to try and work out why
the text file is not updated.
 
The product version is just a property like any other and often seems not to
be mentioned specially. That confused me when I wrote my first patch.

-Original Message-
From: Ulrich Proeller [mailto:ulr...@prosa.biz]
Sent: 11 January 2012 11:00
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Applying a patch (.msp) doesn't increasethe product
version

Thank you, this helps me a huge step forward.

Referencing the ProductVersion changes the version as desired.  Is this
written in any documentation/book and I have overlooked it?
And I didn't know about the View Patch feature in Orca. This makes life a
lot easier!

My patch family now looks like this:
PatchFamily Id='pfSzenariorechner' Version='1.2.7.0' Supersede='yes'
  ComponentRef Id=Szenariorechner /
  PropertyRef Id=ProductVersion/
  ComponentRef Id=VersionFile /
/PatchFamily

However, the text file with the version  string is still not replaced. This
is a separate component, in the same component group as the managed assembly
and both are in the same fragment. I read that it should be enough to
reference one component in each fragment to trigger the inclusion of all
components in that fragment.
Nevertheless, even referencing it explicitly doesn't help.

Below, you see the definition of the mentioned fragment:

  Fragment
ComponentGroup Id=Szenariorechner
  Component Id=Szenariorechner
Guid=c447f464-15ac-4dc3-8456-623197bd6a71 Directory=INSTALLFOLDER
File Id=Szenariorechner.exe
Name=$(var.Szenariorechner.TargetFileName) Vital='yes' Checksum='yes'
AssemblyApplication='Szenariorechner.exe'
  Source=$(var.Szenariorechner.TargetPath) DiskId=1
Assembly='.net' KeyPath=yes
  netfx:NativeImage Id=ngen.Szenariorechner Platform=all
Priority=1 AppBaseDirectory=INSTALLFOLDER/
/File
File Id=Szenariorechner.exe.config
Name=$(var.Szenariorechner.TargetFileName).config Vital='yes'

Re: [WiX-users] Applying a patch (.msp) doesn't increasethe product version

2012-01-12 Thread Ulrich Proeller
Examining the .wixmst confirms my suspicion: If the file size has changed, the 
file is marked as modified in the .wixmst, else the file has no such markup.

-Ursprüngliche Nachricht-
Von: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com]
Gesendet: Donnerstag, 12. Januar 2012 10:51
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] Applying a patch (.msp) doesn't increasethe product 
version

Can you verify this by producing a minimum test case ? Create an MSI with just 
1 text file and an upgrade and a patch from that. It might help you narrow down 
what's going wrong.
The .wixmst produced by torch is an xml file containing all the changes between 
the two inputs, even if they are not referenced by the patch wxs file. It might 
be worth looking through it for your text file name. It should be in there.

-Original Message-
From: Ulrich Proeller [mailto:ulr...@prosa.biz]
Sent: 12 January 2012 09:34
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Applying a patch (.msp) doesn't increasethe product 
version

When examining the files with an administrative install, the files in the two 
.msi files are definitely different.
When I change the file size of the text file, the file is included in the 
patch.  But if the file size is the same as the file size of the original file, 
it isn't included into the patch.

As far as I can see now, torch.exe does the following:
1. If a file has a version (.exe, .dll), that version is checked to determine 
if the file has changed.
2. If a file has no version, it is simply checked if the file size has changed. 
If the size is unchanged, the file is considered as unchanged.

This appears to me to be a bug in torch.exe.
I would try to find and fix this bug in torch.exe now as I really need to 
reliably create patches.

Besides this, I think that in Wix 3.6 Beta, the patch creation is broken 
(torch.exe or pyro.exe). When I apply the 3.6 toolset to the same files which 
successfully created a patch file with WIX 3.5, I get an warning about an empty 
cabinet.

-Ursprüngliche Nachricht-
Von: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com]
Gesendet: Mittwoch, 11. Januar 2012 13:13
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] Applying a patch (.msp) doesn't increase the product 
version

It all looks reasonable. I'd probably go back and examine the text file in the 
2 MSIs that you're building the patch from. It could be a build problem.
Do an administrative install of both MSIs and the version of the text file from 
each admin install.

-Original Message-
From: Ulrich Proeller [mailto:ulr...@prosa.biz]
Sent: 11 January 2012 11:29
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Applying a patch (.msp) doesn't increase the product 
version

I think that the patch doesn't include this text file. At least ORCA shows only 
the file Szenariorechner.exe to be changed by the patch. The file 
Version.txt is marked as unchanged.

-Ursprüngliche Nachricht-
Von: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com]
Gesendet: Mittwoch, 11. Januar 2012 12:21
An: General discussion for Windows Installer XML toolset.
Betreff: Re: [WiX-users] Applying a patch (.msp) doesn't increasethe product 
version

I'd generate a verbose log while installing the patch to try and work out why 
the text file is not updated.

The product version is just a property like any other and often seems not to be 
mentioned specially. That confused me when I wrote my first patch.

-Original Message-
From: Ulrich Proeller [mailto:ulr...@prosa.biz]
Sent: 11 January 2012 11:00
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Applying a patch (.msp) doesn't increasethe product 
version

Thank you, this helps me a huge step forward.

Referencing the ProductVersion changes the version as desired.  Is this written 
in any documentation/book and I have overlooked it?
And I didn't know about the View Patch feature in Orca. This makes life a lot 
easier!

My patch family now looks like this:
PatchFamily Id='pfSzenariorechner' Version='1.2.7.0' Supersede='yes'
  ComponentRef Id=Szenariorechner /
  PropertyRef Id=ProductVersion/
  ComponentRef Id=VersionFile /
/PatchFamily

However, the text file with the version  string is still not replaced. This is 
a separate component, in the same component group as the managed assembly and 
both are in the same fragment. I read that it should be enough to reference one 
component in each fragment to trigger the inclusion of all components in that 
fragment.
Nevertheless, even referencing it explicitly doesn't help.

Below, you see the definition of the mentioned fragment:

  Fragment
ComponentGroup Id=Szenariorechner
  Component Id=Szenariorechner
Guid=c447f464-15ac-4dc3-8456-623197bd6a71 Directory=INSTALLFOLDER
File Id=Szenariorechner.exe

Re: [WiX-users] Patching

2012-01-12 Thread Peter Shirtcliffe
1. There are a couple of ways that might work for you. It depends if you have
to stick with your current upgrade strategy or if you have an opportunity to
alter it. 

Firstly, most people find that producing major upgrade MSIs is by far the
easiest way to support upgrades. You cant apply these out of order though.

This blog post describes your scenario
http://blogs.msdn.com/b/heaths/archive/2006/06/14/cumulative-service-packs-wi
th-minorupdatetargetrtm.aspx
This also won't allow you to apply patches out of order. You can apply a
later patch first but, being cumulative, the earlier patch is included. It
does however simplify the problem of supporting a product with many possible
combinations of patches involved. 

You could also create patches that target multiple versions of the MSI. That
fits your requirement better but problem with those is that, if you produce
many patches that can be applied in any order, the number of possible
installed products that need to be targeted increases rapidly. This increases
patch size and testing complexity. If the patches are independent and don't
change the product version, that may not be a problem.

I believe you could also create small updates that do not alter the product
version and could be combined freely. As long as all your files are versioned
and backwards compatible, then you could mix these freely and the MSI
versioning rules would always ensure the highest is installed.
 
The number of possible combinations you allow could grow quickly and will be
inherently tricky to support. Finding the best solution is really only
something you can decide, knowing what your constraints are. Whatever you
decide on, you should definitely make some test patches. I also strongly
recommend reading the MS whitepaper. Its long and dry but explains many ways
in which you can use patching and has some example scenarios too. 

3. I think heat automatically generates components in fragments unless you
use the -sfrag switch.

Torch works with all kinds of files. Windows Installer works best if your
executable files have a version resource that specifies the file version but
it'll will handle unversioned binaries too.


-Original Message-
From: Sanjay Poria [mailto:sanjay.po...@xanalys.com] 
Sent: 11 January 2012 23:09
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Patching

Thanks for the information Peter. Some follow up:

1) In previous versions of our app, we distributed patches to the customer as
a set of files in a zip that the customer simply unzips into the application
directory. While this isn't ideal (because of the problems associated with
uninstalling patches etc.) it is very flexible in that we can distribute any
number of patches that are not dependant on each other, and the customer can
install and test the features in any order.

For example, If we deliver patch P1 and P2 to the customer in that order,
they may decide to install P2 first because it requires a smaller test effort
than P1. I'm not sure how I achieve the same using the MSI patching. Let's
say we have 3 wixpdb files: mainprod.wixpdb, patch1.wixpdb, patch2.wixpdb.
When release Patch1 we use the transform (mainprod-patch1). Then we release
patch2 which is not dependant on patch1 so we use the transforms
(mainprod-patch2 and patch1-patch2) to generate it. But that wouldn't work
if the customer decided to install patch2 first and then patch1 would it?
Might be that i'm missing something obvious here!

3) I think I prefer to segment my components into different fragments and use
the wixpdb to generate the mappings as doing admin install is a bit of a pain
and potentially more error prone for us. Does anyone know if there is an easy
way to do this (eg, if I harvest files using heat for my initial release, can
it generate a different fragment for each component?).

Another question and potential issue I thought of:

Most of the files we distribute are binary (PowerBuilder) files. Will torch
be able to generate the transform correctly for these?

thanks
sanjay

 -Original Message-
 From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com]
 Sent: 11 January 2012 10:49
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] Patching
 
 I'll try and answer this but it's best to seek some other opinions too.
 
 1. The order of patch installation wont usually matter. When you create
 a
 patch, you target it at a particular version or even multiple versions
 (eg
 patched/upgraded installations) and MSI works out the right sequence.
 See the
 MS patching whitepaper at
 http://www.microsoft.com/download/en/details.aspx?id=19013
 You do this by creating one or more transforms (diffs) with the torch
 tool
 and passing them when you create the patch with pyro.
 
 2. The 4th version field of the MSI product version is ignored by
 Windows
 installer. You can use it for information but we don't - some APIs will
 retrieve the 4th field however. We 

Re: [WiX-users] Run exe in BinaryTable from custom action dll

2012-01-12 Thread Peter Shirtcliffe
See this thread
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Extract-Binarie
s-at-Install-Time-td2301189.html#a2314132


-Original Message-
From: Naim Kingston [mailto:naim.kings...@ancamotion.com] 
Sent: 12 January 2012 05:35
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Run exe in BinaryTable from custom action dll

Hey,

I have a 3rd party executable to detect some hardware, and since it's a
general purpose exe, not detecting the hardware isn't a condition that has
the exe return a failure (I guess, to be expected and completely fair).

So, in order to determine whether the hardware I'm looking for is present on
the system, I need to be able to catch the output that this exe outputs to
the standard output stream, so I'm trying to create a C# custom action dll to
run the exe using System.Diagnostics.Process and redirect its output to a
string where I can parse it to look for certain values to ensure the hardware
is present and correctly configured.

My problem is that the tool isn't going to be present on the system prior to
installation, and actually isn't needed by the final product, only to
determine the hardware state of the machine to make a decision on what to
install (which will actually be one of two other msi files, but running
multiple msi files is a problem for another day), so it's not going to be
installed with the rest of the product.

So, I've used the Binary tag to embed the exe into the installer, and I can
run it directly via custom action, but how do I run it from a dll custom
action? Can I somehow access it and run it while embedded? Or do I need to
write it out to the temp folder, run it, and then delete it?

And then, I need to set a variable or property so the data will be passed
back to the installer from the dll custom action.

But running the embedded exe from a custom action is what's giving me issues
right now. Has anyone done anything like this before? I've tried googling for
most of the day but haven't found anything particularly useful.

-Naim
-
-
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
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.


--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Insignia in 3.6

2012-01-12 Thread Peter Hull


 From: r...@robmensching.com
 Date: Wed, 11 Jan 2012 07:55:13 -0800
 That looks right. Please file a bug if the command-line help wasn't
 helpful. 
OK, bug 3472564. I've also attached a patch to the bug report - hopefully you 
can use it as a starting point at least.

Pete

  
--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Signing the burn bootstrapper

2012-01-12 Thread Nick Ball
Hi,

I haven't started using burn yet - but I'd like to - and signing will be an 
issue for us. At the moment, I hand an unsigned MSI over to the release manager 
for signing. He is the only person with access to the certificate. Can we still 
do this with burn? From what I've seen of this discussion so far, I must sign 
as part of the build process - something that will cause us a bit of an issue. 
Is that right?

-Nick

-Original Message-
From: Peter Hull [mailto:peterhul...@hotmail.com] 
Sent: 12 January 2012 08:58
To: WiX Users
Subject: Re: [WiX-users] Signing the burn bootstrapper


To sign the bundle and bundle engine you need to add the following to your 
.wixproj:
Add SignOutputtrue/SignOutput to a PropertyGroup Implement the targets like 
this:
    Target Name=SignBundleEngine
        SignFile TimestampUrl=... CertificateThumbprint=... 
SigningTarget=@(SignBundleEngine) /
    /Target
    Target Name=SignBundle 
        SignFile TimestampUrl=... CertificateThumbprint=... 
SigningTarget=@(SignBundle) /
    /Target
You need to put these _after_ the Import Project=$(WixTargetsPath) /

Alternatively you can use Exec Command='signtool.exe sign ...' / for more 
control.

There is also a SignContainers target but I don't know quite what it does.

When buiding MSIs, to sign them you need to implement Target Name=SignMsi

If you have external CABs then also implement Target Name=SignCabs

The things you need to sign are in an itemgroup with the same name as the 
target (e.g. @(SignMsi))

Note that you can't use the SignFile task for this, as it will only sign exes 
and dlls. You have to use Exec Command=signtool sign ... /

Hope that helps,

Pete



  


--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Custom action to search and replace text in a file?

2012-01-12 Thread Dan Gough
Hi,

I'm trying to find/replace text in an installed file without resorting to
vbscript.  It's not an XML or INI file.  I've tried the TemplateFile action
from the AppSecIn extensions on CodePlex, but it does not work in the way
that I want.

Does anybody have a C++ custom action dll for this they can share or point
me to?

Thanks,
Dan
--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Reopen Burn triggers virus checker - ID: 3431068

2012-01-12 Thread Hoover, Jacob
I would start by digitally signing your burn bundle. Most anti-virus
software provides more leeway to signed executables. If your bundle is
static, then you could also submit it to Trend Micro as a false
positive.  Most AV vendors will update their signatures to work around
false positives in a timely manner.

The RunOnce key, from what I read in Rob's response, is written to from
the bundling framework of burn. It is done proactively rather than as
needed.

-Original Message-
From: NIkolaj Steensgaard [mailto:n...@panorama9.com] 
Sent: Thursday, January 12, 2012 3:37 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Reopen Burn triggers virus checker - ID:
3431068

On 01/12/2012 09:46 AM, Peter Hull wrote:
 From: r...@robmensching.com
 We'll need to teach this anti-virus program about Burn. Fortunately
big
 programs, like Visual Studio, are using Burn and if it kills them I
hope we
 can muster some change.
 So are you saying we need to raise this as an issue with Trend Micro?
I have been trying to debug this issue to answer that exact question !
 Is the program that actually writes the registry always the same? (I'm
a bit confused about what the stages are when a burn exe is run,
particularly what the burn engine is and what the burn agent is)
I will explain the issue more detailed to better give insight in what we

are seeing.

For about year we have been deploying our software build with the WIX 
installer as a MSI package and have not seen this issue.

To Months ago we created a Bundled version ( exe build with WIX 3.6 )  
that checked for .net 3.51 + Win install 3.1 and
installed if needed before installing our software

Then we got reports from client's about this issue occurring

The Bundled version is quite simple and only checks for the above 
mentioned software and downloads / installs if needed

A complete AD with Trend Micro Office Scan were established to reproduce

the error which we can.

Some things that we so far have noticed :

It only seem to occur on Windows XP for some reason.  ( this machine 
already have the needed .net and Win install so it's not there installer

that's creates the problem )
Our Code does not at anytime write or read from the RunOnce key
Also as the previous reporter of this issue ( ID: 3431068 )

We will be trying to use SysInternals tools to get a debug of whats 
happening when the issue occurs, and post the result here.

Hope this helps in explaining the issue we are seeing and we are more 
that happy to run any test's you suggest !!!

Nik



 Pete

   


--
 RSA(R) Conference 2012
 Mar 27 - Feb 2
 Save $400 by Jan. 27
 Register now!
 http://p.sf.net/sfu/rsa-sfdev2dev2
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users



--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Possible bug in Lux

2012-01-12 Thread Bob Arnson
On 10-Jan-12 17:48, John Cooper wrote:
 Test NVPPTb.SetEditNetTcpBinding.Header failed with unknown operation.

That's bad. But thanks for the repro! Can you file a bug on SF?

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


--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Signing the burn bootstrapper

2012-01-12 Thread Bob Arnson
On 12-Jan-12 05:47, Nick Ball wrote:
 I haven't started using burn yet - but I'd like to - and signing will be an 
 issue for us. At the moment, I hand an unsigned MSI over to the release 
 manager for signing. He is the only person with access to the certificate. 
 Can we still do this with burn? From what I've seen of this discussion so 
 far, I must sign as part of the build process - something that will cause us 
 a bit of an issue. Is that right?

You can't just sign the final output; you have to sign the bits that 
make up the bundle. But you can make signing a separate project that 
uses WiX just to assemble the signed bits into a bundle.

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


--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Generated MSI Name

2012-01-12 Thread Daniel Sniderman
I see that it's set in the Designer as Output Name which is a MSBuild 
Property.  Is there any way (other than having the build edit the .wixproj or 
copy/rename after the it's generated) to change the output MSI?

Thanks

Daniel P. Sniderman| Sr Consultant| Magenic
MCSD.NET, MCTS: Team Foundation Server 2010 Administration

333 E. Butterfield Rd. Suite 100, Lombard, IL 60148
Mobile: 847-668-4882  | eFax 847-390-7810
magenic.com | dani...@magenic.commailto:dani...@magenic.com


--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Applying a patch (.msp) doesn't increase the product version

2012-01-12 Thread Bob Arnson
On 11-Jan-12 03:00, Ulrich Proeller wrote:
 The switch -sf in the pyro command was added the get rid of a duplicate key 
 error.

That's likely the root cause of your problem. Fix the underlying bug 
before trying workarounds.

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


--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Possible bug in Lux

2012-01-12 Thread John Cooper
Sure.  I'll get on it right after lunch.
--
John M. Cooper

-Original Message-
From: Bob Arnson [mailto:b...@joyofsetup.com] 
Sent: Thursday, January 12, 2012 8:39 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Possible bug in Lux

On 10-Jan-12 17:48, John Cooper wrote:
 Test NVPPTb.SetEditNetTcpBinding.Header failed with unknown operation.

That's bad. But thanks for the repro! Can you file a bug on SF?

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


--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
NOTICE: This electronic mail message and any files transmitted with it are 
intended
exclusively for the individual or entity to which it is addressed. The message, 
together with any attachment, may contain confidential and/or privileged 
information.
Any unauthorized review, use, printing, saving, copying, disclosure or 
distribution 
is strictly prohibited. If you have received this message in error, please 
immediately advise the sender by reply email and delete all copies.


--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Possible bug in Lux

2012-01-12 Thread John Cooper
Bug is 3473007.
--
John M. Cooper

-Original Message-
From: John Cooper 
Sent: Thursday, January 12, 2012 11:43 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Possible bug in Lux

Sure.  I'll get on it right after lunch.
--
John M. Cooper

-Original Message-
From: Bob Arnson [mailto:b...@joyofsetup.com] 
Sent: Thursday, January 12, 2012 8:39 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Possible bug in Lux

On 10-Jan-12 17:48, John Cooper wrote:
 Test NVPPTb.SetEditNetTcpBinding.Header failed with unknown operation.

That's bad. But thanks for the repro! Can you file a bug on SF?

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


--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
NOTICE: This electronic mail message and any files transmitted with it are 
intended
exclusively for the individual or entity to which it is addressed. The message, 
together with any attachment, may contain confidential and/or privileged 
information.
Any unauthorized review, use, printing, saving, copying, disclosure or 
distribution 
is strictly prohibited. If you have received this message in error, please 
immediately advise the sender by reply email and delete all copies.


--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
NOTICE: This electronic mail message and any files transmitted with it are 
intended
exclusively for the individual or entity to which it is addressed. The message, 
together with any attachment, may contain confidential and/or privileged 
information.
Any unauthorized review, use, printing, saving, copying, disclosure or 
distribution 
is strictly prohibited. If you have received this message in error, please 
immediately advise the sender by reply email and delete all copies.


--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Generated MSI Name

2012-01-12 Thread Castro, Edwin G. (Hillsboro)
How do you want to generate your name? This will determine how we change 
OutputName.

OutputName is just a MSBuild property but one that is used by all project 
types. I believe (but have not verified) that if you build your solution from 
the command line providing a different value for OutputName you'll end up with 
all of your projects in that solution with the same name.

msbuild sample.sln /p:OutputName=GeneratedName /t:build

You'll probably want to define a new custom property in your .wixproj  so that 
you can change only the OutputName in the .wixproj.

Project ...
  PropertyGroup
...
SetupNameDefaultValue/SetupName
OutputName$(SetupName)/OutputName
...
  /PropertyGroup
  ...
/Project

In the sample above I define a new property, SetupName, before OutputName. I 
use the value of SetupName as the value for OutputName. Note that you'll need 
to hand edit the .wixproj.

Now we should be able to set SetupName on the command line to whatever 
generated name we want and not affect OutputName for any other projects.

msbuild sample.sln /p:SetupName=GeneratedName /t:build

This all assumes that the name is generated before the solution begins building.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail

 -Original Message-
 From: Daniel Sniderman [mailto:dani...@magenic.com]
 Sent: Thursday, January 12, 2012 9:24 AM
 To: wix-users@lists.sourceforge.net
 Subject: [WiX-users] Generated MSI Name
 
 I see that it's set in the Designer as Output Name which is a MSBuild
 Property.  Is there any way (other than having the build edit the .wixproj or
 copy/rename after the it's generated) to change the output MSI?
 
 Thanks
 
 Daniel P. Sniderman| Sr Consultant| Magenic MCSD.NET, MCTS: Team
 Foundation Server 2010 Administration
 
 333 E. Butterfield Rd. Suite 100, Lombard, IL 60148
 Mobile: 847-668-4882  | eFax 847-390-7810 magenic.com |
 dani...@magenic.commailto:dani...@magenic.com
 
 
 --
 RSA(R) Conference 2012
 Mar 27 - Feb 2
 Save $400 by Jan. 27
 Register now!
 http://p.sf.net/sfu/rsa-sfdev2dev2
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users
--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Generated MSI Name

2012-01-12 Thread Daniel Sniderman
The name would probably include the Configuration and version information .

However this would be part of a TFS 2010 Build - so passing an argument to 
MSBuild is supported.  Thanks - this is very helpful.

-Original Message-
From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] 
Sent: Thursday, January 12, 2012 12:02 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Generated MSI Name

How do you want to generate your name? This will determine how we change 
OutputName.

OutputName is just a MSBuild property but one that is used by all project 
types. I believe (but have not verified) that if you build your solution from 
the command line providing a different value for OutputName you'll end up with 
all of your projects in that solution with the same name.

msbuild sample.sln /p:OutputName=GeneratedName /t:build

You'll probably want to define a new custom property in your .wixproj  so that 
you can change only the OutputName in the .wixproj.

Project ...
  PropertyGroup
...
SetupNameDefaultValue/SetupName
OutputName$(SetupName)/OutputName
...
  /PropertyGroup
  ...
/Project

In the sample above I define a new property, SetupName, before OutputName. I 
use the value of SetupName as the value for OutputName. Note that you'll need 
to hand edit the .wixproj.

Now we should be able to set SetupName on the command line to whatever 
generated name we want and not affect OutputName for any other projects.

msbuild sample.sln /p:SetupName=GeneratedName /t:build

This all assumes that the name is generated before the solution begins building.

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
P Please consider the environment before printing this e-mail

 -Original Message-
 From: Daniel Sniderman [mailto:dani...@magenic.com]
 Sent: Thursday, January 12, 2012 9:24 AM
 To: wix-users@lists.sourceforge.net
 Subject: [WiX-users] Generated MSI Name
 
 I see that it's set in the Designer as Output Name which is a 
 MSBuild Property.  Is there any way (other than having the build edit 
 the .wixproj or copy/rename after the it's generated) to change the output 
 MSI?
 
 Thanks
 
 Daniel P. Sniderman| Sr Consultant| Magenic MCSD.NET, MCTS: Team 
 Foundation Server 2010 Administration
 
 333 E. Butterfield Rd. Suite 100, Lombard, IL 60148
 Mobile: 847-668-4882  | eFax 847-390-7810 magenic.com | 
 dani...@magenic.commailto:dani...@magenic.com
 
 
 --
 
 RSA(R) Conference 2012
 Mar 27 - Feb 2
 Save $400 by Jan. 27
 Register now!
 http://p.sf.net/sfu/rsa-sfdev2dev2
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users
--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Reopen Burn triggers virus checker - ID: 3431068

2012-01-12 Thread Nikolaj Steensgaard
On Thu, Jan 12, 2012 at 6:03 PM, Hoover, Jacob
jacob.hoo...@greenheck.comwrote:

 I would start by digitally signing your burn bundle.


The bundle is already signed with a Thawte code signing certificate


 Most anti-virus
 software provides more leeway to signed executables. If your bundle is
 static, then you could also submit it to Trend Micro as a false
 positive.  Most AV vendors will update their signatures to work around
 false positives in a timely manner.


Yes, but our bundle is dynamic as the version of the software changes.


 The RunOnce key, from what I read in Rob's response, is written to from
 the bundling framework of burn. It is done proactively rather than as
 needed.


So isn't that really the issue then ?

Either should Trend Micro change there detection mechanism regarding the
RunOnce key or
 the  bundling framework of burn should change its default behavior .

I have already tried to get in contact to Trend Micro through several
channels without luck and
have also submitted a  request to get access to Reputation Service and
Verification Portal (RSVP).

Looking in the Trend Micro software there does'nt seem to be a way to turn
the Malware detection feature



 -Original Message-
 From: NIkolaj Steensgaard [mailto:n...@panorama9.com]
 Sent: Thursday, January 12, 2012 3:37 AM
 To: General discussion for Windows Installer XML toolset.
 Subject: Re: [WiX-users] Reopen Burn triggers virus checker - ID:
 3431068

 On 01/12/2012 09:46 AM, Peter Hull wrote:
  From: r...@robmensching.com
  We'll need to teach this anti-virus program about Burn. Fortunately
 big
  programs, like Visual Studio, are using Burn and if it kills them I
 hope we
  can muster some change.
  So are you saying we need to raise this as an issue with Trend Micro?
 I have been trying to debug this issue to answer that exact question !
  Is the program that actually writes the registry always the same? (I'm
 a bit confused about what the stages are when a burn exe is run,
 particularly what the burn engine is and what the burn agent is)
 I will explain the issue more detailed to better give insight in what we

 are seeing.

 For about year we have been deploying our software build with the WIX
 installer as a MSI package and have not seen this issue.

 To Months ago we created a Bundled version ( exe build with WIX 3.6 )
 that checked for .net 3.51 + Win install 3.1 and
 installed if needed before installing our software

 Then we got reports from client's about this issue occurring

 The Bundled version is quite simple and only checks for the above
 mentioned software and downloads / installs if needed

 A complete AD with Trend Micro Office Scan were established to reproduce

 the error which we can.

 Some things that we so far have noticed :

 It only seem to occur on Windows XP for some reason.  ( this machine
 already have the needed .net and Win install so it's not there installer

 that's creates the problem )
 Our Code does not at anytime write or read from the RunOnce key
 Also as the previous reporter of this issue ( ID: 3431068 )

 We will be trying to use SysInternals tools to get a debug of whats
 happening when the issue occurs, and post the result here.

 Hope this helps in explaining the issue we are seeing and we are more
 that happy to run any test's you suggest !!!

 Nik


 
  Pete
 
 
 
 
 --
  RSA(R) Conference 2012
  Mar 27 - Feb 2
  Save $400 by Jan. 27
  Register now!
  http://p.sf.net/sfu/rsa-sfdev2dev2
  ___
  WiX-users mailing list
  WiX-users@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wix-users


 
 --
 RSA(R) Conference 2012
 Mar 27 - Feb 2
 Save $400 by Jan. 27
 Register now!
 http://p.sf.net/sfu/rsa-sfdev2dev2
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users


 --
 RSA(R) Conference 2012
 Mar 27 - Feb 2
 Save $400 by Jan. 27
 Register now!
 http://p.sf.net/sfu/rsa-sfdev2dev2
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users




-- 
Best Regards
Nikolaj Steensgaard

Panorama9 A/S
Langebrogade 5
1411 Copenhagen K
Phone: +45 7020 3565
Mobile: +45 2124 3040
n...@panorama9.com

Panorama9 is an IT management platform that shows you everything you need
to know about your assets, IT availability, security vulnerabilities, and
non-compliant systems – from a single Dashboard that’s amazingly easy to
monitor and interpret. Your organization can cut IT costs through improved
uptime and as a cloud-based solution, there is no infrastructure to deploy
or manage. For more information 

[WiX-users] Copy Files from Bundle to Disk

2012-01-12 Thread Jammer
Hey All,

Is it possible to copy an .msi or .exe from within the bundle to the 
install location?

I have a product included in my installer that I'd like to  copy to the 
install location in case the user wishes to run that installer manually 
later.

TIA,

-- 
*Jammer*
http://www.jammer.biz**
--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install

2012-01-12 Thread McCain, Jon
I have been working on a new install where a context menu is added to the 
Right-Click Menu within Internet Explorer.

Everything I have read regarding this requires the key be added to 
HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer. This does work but the 
issue I have is that our installs are run as per-machine installs and this 
causes other users that login to not have this menu.

Links to MSDN articles explaining context menu additions for Internet Explorer: 
http://msdn.microsoft.com/en-us/library/aa753589%28VS.85%29.aspx

The wxs code is quite simple for this addition:

RegistryValue Id=ctd_classinfo_183 Action=write Type=string 
Root=HKCU Key=Software\Microsoft\Internet Explorer\MenuExt\keyName 
Value=[#FileID]/
RegistryValue Id=ctd_classinfo_184 Action=write Type=string 
Root=HKCU Key=Software\Microsoft\Internet Explorer\MenuExt\ keyName 
\Contexts Value=1/

Has anyone run into this or another issue where a per-machine install is 
performed but features or other items need to exist for all users in the above 
fashion?

Thanks,

Jon
--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install

2012-01-12 Thread Christopher Painter
The Registry element  has a Root attribute that you can set to HKCU.  If 
your program has an advertised shortcut you can use this to trigger 
resilency to complete the installation for each user who uses your app.  
It's an ugly story though like the old Office install that popped up every 
time you went to a new conference room and logged in.


http://wix.sourceforge.net/manual-wix3/wix_xsd_registry.htm


Here's an alternative approach that avoids all that:


http://blogs.flexerasoftware.com/installtalk/2011/11/using-active-setup-to-r
epair-user-settings.html



From: McCain, Jon jon.mcc...@inin.com

Sent: Thursday, January 12, 2012 3:28 PM

To: General discussion for Windows Installer XML toolset. 
(wix-users@lists.sourceforge.net) wix-users@lists.sourceforge.net

Subject: [WiX-users] Adding Internet Explorer Context Menu item for all 
users in a per machine install


I have been working on a new install where a context menu is added to the 
Right-Click Menu within Internet Explorer.


Everything I have read regarding this requires the key be added to 
HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer. This does work but 
the issue I have is that our installs are run as per-machine installs and 
this causes other users that login to not have this menu.


Links to MSDN articles explaining context menu additions for Internet 
Explorer: http://msdn.microsoft.com/en-us/library/aa753589%28VS.85%29.aspx


The wxs code is quite simple for this addition:


RegistryValue Id=ctd_classinfo_183 Action=write Type=string 
Root=HKCU Key=Software\Microsoft\Internet Explorer\MenuExt\keyName 
Value=[#FileID]/

RegistryValue Id=ctd_classinfo_184 Action=write Type=string 
Root=HKCU Key=Software\Microsoft\Internet Explorer\MenuExt\ keyName 
\Contexts Value=1/


Has anyone run into this or another issue where a per-machine install is 
performed but features or other items need to exist for all users in the 
above fashion?


Thanks,


Jon


--

RSA(R) Conference 2012

Mar 27 - Feb 2

Save $400 by Jan. 27

Register now!

http://p.sf.net/sfu/rsa-sfdev2dev2

___

WiX-users mailing list

WiX-users@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/wix-users


--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install

2012-01-12 Thread Dan Gough
Or try applying the key to HKLM rather than HKCU in the first place.  Many
Windows settings can apply to either key to give you the flexibility of
having each setting system-wide or per-user.


On Thu, Jan 12, 2012 at 9:34 PM, Christopher Painter chr...@iswix.comwrote:

 The Registry element  has a Root attribute that you can set to HKCU.  If
 your program has an advertised shortcut you can use this to trigger
 resilency to complete the installation for each user who uses your app.
 It's an ugly story though like the old Office install that popped up every
 time you went to a new conference room and logged in.


 http://wix.sourceforge.net/manual-wix3/wix_xsd_registry.htm


 Here's an alternative approach that avoids all that:



 http://blogs.flexerasoftware.com/installtalk/2011/11/using-active-setup-to-r
 epair-user-settings.html

 

 From: McCain, Jon jon.mcc...@inin.com

 Sent: Thursday, January 12, 2012 3:28 PM

 To: General discussion for Windows Installer XML toolset.
 (wix-users@lists.sourceforge.net) wix-users@lists.sourceforge.net

 Subject: [WiX-users] Adding Internet Explorer Context Menu item for all
 users in a per machine install


 I have been working on a new install where a context menu is added to the
 Right-Click Menu within Internet Explorer.


 Everything I have read regarding this requires the key be added to
 HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer. This does work but
 the issue I have is that our installs are run as per-machine installs and
 this causes other users that login to not have this menu.


 Links to MSDN articles explaining context menu additions for Internet
 Explorer: http://msdn.microsoft.com/en-us/library/aa753589%28VS.85%29.aspx


 The wxs code is quite simple for this addition:


 RegistryValue Id=ctd_classinfo_183 Action=write Type=string
 Root=HKCU Key=Software\Microsoft\Internet Explorer\MenuExt\keyName
 Value=[#FileID]/

 RegistryValue Id=ctd_classinfo_184 Action=write Type=string
 Root=HKCU Key=Software\Microsoft\Internet Explorer\MenuExt\ keyName
 \Contexts Value=1/


 Has anyone run into this or another issue where a per-machine install is
 performed but features or other items need to exist for all users in the
 above fashion?


 Thanks,


 Jon


 
 --

 RSA(R) Conference 2012

 Mar 27 - Feb 2

 Save $400 by Jan. 27

 Register now!

 http://p.sf.net/sfu/rsa-sfdev2dev2

 ___

 WiX-users mailing list

 WiX-users@lists.sourceforge.net

 https://lists.sourceforge.net/lists/listinfo/wix-users



 --
 RSA(R) Conference 2012
 Mar 27 - Feb 2
 Save $400 by Jan. 27
 Register now!
 http://p.sf.net/sfu/rsa-sfdev2dev2
 ___
 WiX-users mailing list
 WiX-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wix-users

--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install

2012-01-12 Thread Christopher Painter
Then there's the case of Office AddIns that allowed either HKCU or HKLM in 
2003, took away in 2007 ( and put it back with a hotfix and enabling 
registry value ) and really put it back in 2010 leaving one hell of a mess 
for us installer guys to deal with.


So, yes, YMMV... in the event it really needs to be HKCU like the poster 
asserted then my response below will help.



From: Dan Gough goug...@gmail.com

Sent: Thursday, January 12, 2012 5:21 PM

To: chr...@iswix.com, General discussion for Windows Installer XML 
toolset. wix-users@lists.sourceforge.net

Subject: Re: [WiX-users] Adding Internet Explorer Context Menu item for all 
users in a per machine install


Or try applying the key to HKLM rather than HKCU in the first place.  Many 
Windows settings can apply to either key to give you the flexibility of 
having each setting system-wide or per-user.

On Thu, Jan 12, 2012 at 9:34 PM, Christopher Painter chr...@iswix.com 
wrote:

The Registry element  has a Root attribute that you can set to HKCU.  If

your program has an advertised shortcut you can use this to trigger

resilency to complete the installation for each user who uses your app.

It's an ugly story though like the old Office install that popped up every

time you went to a new conference room and logged in.


http://wix.sourceforge.net/manual-wix3/wix_xsd_registry.htm


Here's an alternative approach that avoids all that:


http://blogs.flexerasoftware.com/installtalk/2011/11/using-active-setup-to-r


epair-user-settings.html





From: McCain, Jon jon.mcc...@inin.com


Sent: Thursday, January 12, 2012 3:28 PM


To: General discussion for Windows Installer XML toolset.

(wix-users@lists.sourceforge.net) wix-users@lists.sourceforge.net


Subject: [WiX-users] Adding Internet Explorer Context Menu item for all

users in a per machine install


I have been working on a new install where a context menu is added to the

Right-Click Menu within Internet Explorer.


Everything I have read regarding this requires the key be added to

HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer. This does work but

the issue I have is that our installs are run as per-machine installs and

this causes other users that login to not have this menu.


Links to MSDN articles explaining context menu additions for Internet

Explorer: http://msdn.microsoft.com/en-us/library/aa753589%28VS.85%29.aspx


The wxs code is quite simple for this addition:


RegistryValue Id=ctd_classinfo_183 Action=write Type=string

Root=HKCU Key=Software\Microsoft\Internet Explorer\MenuExt\keyName

Value=[#FileID]/


RegistryValue Id=ctd_classinfo_184 Action=write Type=string

Root=HKCU Key=Software\Microsoft\Internet Explorer\MenuExt\ keyName

\Contexts Value=1/


Has anyone run into this or another issue where a per-machine install is

performed but features or other items need to exist for all users in the

above fashion?


Thanks,


Jon





--


RSA(R) Conference 2012


Mar 27 - Feb 2


Save $400 by Jan. 27


Register now!


http://p.sf.net/sfu/rsa-sfdev2dev2


___


WiX-users mailing list


WiX-users@lists.sourceforge.net


https://lists.sourceforge.net/lists/listinfo/wix-users



--

RSA(R) Conference 2012

Mar 27 - Feb 2

Save $400 by Jan. 27

Register now!

http://p.sf.net/sfu/rsa-sfdev2dev2

___

WiX-users mailing list

WiX-users@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/wix-users


--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Writing JDK version verification code, and Wix debugging tip

2012-01-12 Thread T. Kuro Kurosaka
Wix  MSI newbie here.

My product requires JDK 1.6 installation, and I'm trying to come up with 
Wix code to verify the system has JDK 1.5 installed before proceeding 
installation of my product.

I thought this would work:

Property Id=JDKVER
RegistrySearch Id=NetFramework20
 Root=HKLM
 Key=SOFTWARE\JavaSoft\Java Development Kit
 Name=CurrentVersion
 Type=raw /
/Property

Condition Message=This application requires Java Developer Kit 1.5 (or 
higher).
![CDATA[Installed OR (JDKVER  1.5 )]] !-- test with 1.6, 1.7, 
1.8, etc. will be added later. --
/Condition


But this didn't work.  Even if JDK 1.5 is installed, this message is 
displayed.

Anybody has experience doing JDK version check?


In an attempt to debug this, I wanted to display the value of property 
JDKVER, and inserted this code.  This is a modified version of the 
code I've found in the Internet:
CustomAction Id=ShowProperty Script=vbscript Execute=immediate
![CDATA[
   MsgBox JDKVER = + Session.Property(JDKVER)
   ]]
/CustomAction

InstallExecuteSequence
Custom Action=ShowProperty Before=InstallFinalizeTrue/Custom 
!-- Not Installed didn't work either. --
/InstallExecuteSequence

But no popup came out.  What am I doing wrong here?

Thank you in advance.

T. Kuro Kurosaka


--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Writing JDK version verification code, and Wix debugging tip

2012-01-12 Thread Christopher Painter
My memory of the way Java stores there version information in the registry 
isn't very friendly to MSI's RegLocator pattern.  You might need a custom 
action.



From: T. Kuro Kurosaka k...@basistech.com

Sent: Thursday, January 12, 2012 6:21 PM

To: wix-users@lists.sourceforge.net

Subject: [WiX-users] Writing JDK version verification code, and Wix 
debugging tip


Wix  MSI newbie here.


My product requires JDK 1.6 installation, and I'm trying to come up with 

Wix code to verify the system has JDK 1.5 installed before proceeding 

installation of my product.


I thought this would work:


Property Id=JDKVER

RegistrySearch Id=NetFramework20

Root=HKLM

Key=SOFTWARE\JavaSoft\Java Development Kit

Name=CurrentVersion

Type=raw /

/Property


Condition Message=This application requires Java Developer Kit 1.5 (or 

higher).

![CDATA[Installed OR (JDKVER  1.5 )]] !-- test with 1.6, 1.7, 

1.8, etc. will be added later. --

/Condition


But this didn't work.  Even if JDK 1.5 is installed, this message is 

displayed.


Anybody has experience doing JDK version check?


In an attempt to debug this, I wanted to display the value of property 

JDKVER, and inserted this code.  This is a modified version of the 

code I've found in the Internet:

CustomAction Id=ShowProperty Script=vbscript Execute=immediate

![CDATA[

MsgBox JDKVER = + Session.Property(JDKVER)

]]

/CustomAction


InstallExecuteSequence

Custom Action=ShowProperty Before=InstallFinalizeTrue/Custom 

!-- Not Installed didn't work either. --

/InstallExecuteSequence


But no popup came out.  What am I doing wrong here?


Thank you in advance.


T. Kuro Kurosaka



--

RSA(R) Conference 2012

Mar 27 - Feb 2

Save $400 by Jan. 27

Register now!

http://p.sf.net/sfu/rsa-sfdev2dev2

___

WiX-users mailing list

WiX-users@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/wix-users


--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Burn bootstrapper administrator mode log file bug

2012-01-12 Thread Naim Kingston
I'm getting a strange bug where if I run a bootstrapper created with burn from 
an administrator command line prompt AND specify a log file, then the 
bootstrapper will hang before even opening up the UI.

It's strange, running without a log file works fine from the administrator 
command line prompt, but attempting to use a log file causes it to hang and not 
return (for at least a couple of minutes). The bootstrapper in question is just 
to get used to burn and only installs 2 installers of 32kb each (a single, 
practically empty text file per installer).

So, I'm assuming that's a bug of some sort? Is it already known?

-Naim
--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Signing the burn bootstrapper

2012-01-12 Thread Peter Hull

Signing only the bundle would prove that it came from your organisation and 
hadn't been tampered with - would that be enough?
When run it would unpack the unsigned burn engine and the unsigned MSIs. Does 
anyone know if that would show the user a warning (or multiple warnings?)

Bob: would it be possible to have the burn engine signed (by Microsoft) in the 
released WiX 3.6 or have an option to specify the burn engine in the .wxs file 
- as I understand it you currently have to sign the burn engine every time the 
bundle is built, even though it's the same executable.
Pete
  
--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Reopen Burn triggers virus checker - ID: 3431068

2012-01-12 Thread Peter Hull

 Date: Thu, 12 Jan 2012 20:56:15 +0100
 From: n...@panorama9.com
  I would start by digitally signing your burn bundle.


 The bundle is already signed with a Thawte code signing certificate
The reported file name looks more like it's the extracted engine than your 
bundle itself. Have you signed the engine.
 Either should Trend Micro change there detection mechanism regarding the
 RunOnce key or
 the bundling framework of burn should change its default behavior .
From the Trend docs I saw it seemed to suggest that 'Malware Behaviour 
Monitoring' could be turned off (indeed, terminating programs like this was 
not the default) and also that signed executables were exempt. So it maybe is 
a bug in Trend that means it doesn't work as documented?
The other thing is that other installers (InstallShield) don't seem to do this 
so does anyone understand how InstallShield handles the reboot issue?
Pete
  
--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Burn: package ref-counting not working

2012-01-12 Thread Kryschan
Hi folks,

as I read in the WiX 3.6 Beta release notes, burn does support package
ref-counting now, which according to my understanding should guarantee, that
shared packages are uninstalled only if all bundles sharing the packages
were removed.

Here is a little example:

- install Bundle1(containing SharedPackage, Package1)
- install Bundle2(containing SharedPackage, Package2)
- uninstall Bundle1 
-- results in removal of SharedPackage and Package1

I would expect that only Package1 gets removed.

Am I just misunderstanding the feature or may I miss something in my bundle
definitions?

Best regards
Christian


--
View this message in context: 
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-package-ref-counting-not-working-tp7183258p7183258.html
Sent from the wix-users mailing list archive at Nabble.com.

--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users