[WiX-users] Burn and uninstall condition for optional product

[robert_yang]

Hi all - I just changed one of our installers from the old VS2010 bootstrapper 
to the burn 3.7 and am generally liking it.  I do have a question about the 
best way to approach one scenario though.

The main product, let's call it "Q", can have another optional product 
installed, say "B".  Ideally Q should not be uninstalled before B is 
uninstalled.  The way this was done in the past is a launch condition in Q's 
MSI which looks for a registry entry set by B.  If Q was uninstalled before B, 
then an error message box would pop up.

The problem is that on uninstall with Burn the message box showing the error 
"Sorry you must uninstall B first" is suppressed.  The uninstall fails, and the 
user is prompted to look at the Burn log, which doesn't say much.   The MSI log 
does have the message, but the user would have to know to look there, and for 
end users we'd really prefer to have something more friendly.

Right now we are using the standard BA.  I know it's possible to have bundle 
conditions and MSI package conditions, but I'm not sure if we can detect the 
uninstall at that level.  I was thinking of moving the uninstall launch 
condition from Q's MSI into the bootstrapper, but am not sure if this would be 
the right way to go.

Thanks for any assistance/guidance !
-Rob

--
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=5127&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Uninstall bundle by name ?

[robert_yang]

Hi all - I've managed to upgrade some of our installs to Wix 3.7 with the burn 
bootstrapper, hooray !

One thing I haven't quite anticipated is this: after our automated build we 
need to push a newly-built installer to a test machine for an automated 
smoke/sanity test.  First we need to uninstall the old build and install the 
new one (silently, can't just use control panel).  I know it's possible to run 
the old Setup.exe with the "/quiet /uninstall" command-line params, but is that 
the only way ?

With MSI's we could run "msiexec /x {product ID}" to do the uninstall.  Is 
there some way to silently run the uninstall by product name or some other ID 
which doesn't change from build to build ?  It would be nice not to have to 
keep the old bundle around for the uninstall.

Thanks for any info !
-Rob

--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391&iu=/4140/ostg.clktrk
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Patch creation with Ngen ?

[robert_yang]

Hi all - we have an MSI with many DLL and a couple of EXE assemblies, the 
latter of which are nGen'd via netfx:NativeImage.

We are getting ready to create a patch MSP using torch/pyro and wondering if we 
need to do anything explicit to re-nGen these EXE's.  Thanks for any info !

-Rob 

--
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only - learn more at:
http://p.sf.net/sfu/learnmore_122512
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] heat extension - COM exe servers and 64-bit COM support

[robert_yang]

Hi all - about a year ago I wrote a heat extension (based on various code I 
found on the web) for our internal use which harvests 32-bit COM EXE servers 
and pre-initializes the registry with the ATL Registrar before harvesting.  
Lately I updated it with support for 64-bit COM servers (DLL and EXE).  I've 
gotten the go-ahead to clean it up and post it as an open-source project.  I 
need to remove the company-specific namespaces, make things a little more 
generic, add some better comments, perhaps an architecture doc, etc.

My question has to do with the open-source part of it, since I haven't done any 
of that before.  I notice there is a WiX-contrib project on codeplex.  Is that 
a good place to start for something like this ?  Thanks for any gotchas, 
pointers or other info !
-Rob

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Wix 3.6: disable upgrades in burn ?

[robert_yang]

Hi all - really glad to see 3.6 is out !  We have an MSI with upgrade-related 
logic implemented by the MajorUpgrade element: Specifically, we don't want 
upgrades or downgrades to occur automatically (the user is prompted to use 
Add/Remove Programs instead).  Here is an excerpt from Product.wxs :



With Wix 3.5 we were using the old Visual Studio bootstrapper (the app requires 
.NET 4.0).  Now that 3.6 is out, I came up with a bootstrapper (standard BA 
with custom theme) and noticed it implements auto-upgrade logic (assuming the 
upgrade code remains constant): if the version number is bumped up, the old 
version gets silently uninstalled.  Is there a way to declaratively prevent 
this, much like what we are doing in the MSI ?  I saw a post on stackoverflow 
about this from back in July regarding OnPlanRelatedBundle, but is there a way 
to do this without writing a custom BA ?

Thanks for any info !
-Rob

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Burn: uninstalling an MSI

[robert_yang]

I'm not sure if my previous reply went through, so I'll try again.   My first 
try was using the standard bootstrapper, and after looking through more of the 
source found that the UI level is being set in the engine in 
MsiEngineCalculateInstallLevel.  There is related code in 
MsiEnginePlanAddPackage and WiuInitializeExternalUI.

Per RobM's suggestion I wrote a custom managed bootstrapper using WixBA as a 
guide, which was fun.  But I still can't figure out how to change the UI level 
used for the .msi, other than setting MsiPackage/DisplayInternalUI.  I did try 
adding an MsiProperty child to MsiPackage called CLIENTUILEVEL and set it to 2 
(vs. default value of 0), but the command line to the MSI came out as follows : 
(log excerpt)

Command Line: ALLUSERS=1 ARPSYSTEMCOMPONENT=1 MSIFASTINSTALL=7 CLIENTUILEVEL=2 
REBOOT=ReallySuppress CURRENTDIRECTORY=C:\wix\Bootstrapper1\bin\Debug 
CLIENTUILEVEL=0 MSICLIENTUSESEXTERNALUI=1 CLIENTPROCESSID=6876

But only the last instance of CLIENTUILEVEL was effective, as shown in the log 
below :

PROPERTY CHANGE: Adding CLIENTUILEVEL property. Its value is '2'.
[...]
PROPERTY CHANGE: Modifying CLIENTUILEVEL property. Its current value is '2'. 
Its new value: '0'.

Is there a way to set the MSI's UI level in a custom BA ?  If so, I can't seem 
to find it.  Should I open a feature request ?

Thanks for any assistance !
-Rob

From: YANG,ROBERT (Non-A-SantaClara,ex1)
Sent: Thursday, March 22, 2012 9:18 AM
To: 'wix-users@lists.sourceforge.net'
Subject: RE[2]: Burn: uninstalling an MSI

Some further research after looking at some logs : when I install the .msi via 
"msiexec /I msiFileName.msi", CLIENTUILEVEL=0, which I guess is full UI.  When 
uninstalling via the command line below, CLIENTUILEVEL=2 and UILevel=3 
(INSTALLUILEVEL_BASIC).

So I guess my question is how to get burn to use a different CLIENTUILEVEL for 
installation vs. uninstallation ?

From: YANG,ROBERT
Sent: Thursday, March 22, 2012 8:51 AM
To: 'wix-users@lists.sourceforge.net'
Subject: Burn: uninstalling an MSI

Hi all -- I've been tinkering with Wix 3.6 (build 2719), and set up a test 
bundle which installs a .msi package.  I wanted the msi's user interface to be 
displayed, so I specified DisplayInternalUI="yes" in MsiPackage.  This all 
seems to work fine for installation.

On uninstallation I wanted to disable change/modify, so I specified 
DisableModify="yes" in the bundle.  When I go to uninstall the bundle, rather 
unexpectedly I see the Resume dialog.  The .msi uses the stock version found in 
Mondo, which apparently is shown on condition "Installed AND (RESUME OR 
Preselected)".

The Resume dialog is not shown if I simply run "msiexec /x msiFileName.msi" or 
do an uninstall of the MSI from Add/Remove Programs.  Is there something else I 
should be doing ?  It would be fine to run the uninstall silently, but we need 
to have the UI shown on installation.

Thanks for any advice or pointers !
-Rob

--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Burn: uninstalling an MSI

[robert_yang]

Some further research after looking at some logs : when I install the .msi via 
"msiexec /I msiFileName.msi", CLIENTUILEVEL=0, which I guess is full UI.  When 
uninstalling via the command line below, CLIENTUILEVEL=2 and UILevel=3 
(INSTALLUILEVEL_BASIC).

So I guess my question is how to get burn to use a different CLIENTUILEVEL for 
installation vs. uninstallation ?

From: YANG,ROBERT
Sent: Thursday, March 22, 2012 8:51 AM
To: 'wix-users@lists.sourceforge.net'
Subject: Burn: uninstalling an MSI

Hi all -- I've been tinkering with Wix 3.6 (build 2719), and set up a test 
bundle which installs a .msi package.  I wanted the msi's user interface to be 
displayed, so I specified DisplayInternalUI="yes" in MsiPackage.  This all 
seems to work fine for installation.

On uninstallation I wanted to disable change/modify, so I specified 
DisableModify="yes" in the bundle.  When I go to uninstall the bundle, rather 
unexpectedly I see the Resume dialog.  The .msi uses the stock version found in 
Mondo, which apparently is shown on condition "Installed AND (RESUME OR 
Preselected)".

The Resume dialog is not shown if I simply run "msiexec /x msiFileName.msi" or 
do an uninstall of the MSI from Add/Remove Programs.  Is there something else I 
should be doing ?  It would be fine to run the uninstall silently, but we need 
to have the UI shown on installation.

Thanks for any advice or pointers !
-Rob

--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Burn: uninstalling an MSI

[robert_yang]

Hi all -- I've been tinkering with Wix 3.6 (build 2719), and set up a test 
bundle which installs a .msi package.  I wanted the msi's user interface to be 
displayed, so I specified DisplayInternalUI="yes" in MsiPackage.  This all 
seems to work fine for installation.

On uninstallation I wanted to disable change/modify, so I specified 
DisableModify="yes" in the bundle.  When I go to uninstall the bundle, rather 
unexpectedly I see the Resume dialog.  The .msi uses the stock version found in 
Mondo, which apparently is shown on condition "Installed AND (RESUME OR 
Preselected)".

The Resume dialog is not shown if I simply run "msiexec /x msiFileName.msi" or 
do an uninstall of the MSI from Add/Remove Programs.  Is there something else I 
should be doing ?  It would be fine to run the uninstall silently, but we need 
to have the UI shown on installation.

Thanks for any advice or pointers !
-Rob

--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] BootStrapper Package for SQL CE 3.5?

[robert_yang]

Found under

C:\Program Files\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages\SQL Server 
Compact Edition

This is part of the SDK for Win 7 & .NET 3.5 
SP1.  
I would think it would be part of 
7.1 (for .NET 4.0) 
as well.

-Rob

--
From: John Bergman
Date: Fri, 28 Oct 2011 11:39:15 -0700

Has anyone created a Boot strapper package for SQL CE3.5 SP2?  I need both the
x64 and the x86 versions.

I've not created a boot strapper package before, so I was hoping someone could
help point me in the right direction.

Thanks,
John

--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Error 1619

[robert_yang]

Hi, we have a .MSI created with Wix 3.5 which seems to work well for US 
computers.  However, someone in Taiwan tried installing it from our intranet 
and received this error message box :

"This installation package could not be opened. Verify that the package exists 
and is accessible, or contact the application vendor to verify that this is a 
valid Windows Installer package."

My first thought for them is to get a verbose log and try installing locally 
(vs. the network share) to see exactly what's wrong.  But could there also be a 
localization issue ?  I would have thought if we didn't provide a suitable 
Chinese translation, the UI strings would simply appear in US English.  Just 
wondering if there could be another issue.  Thanks !
-Rob
--
Get your Android app more play: Bring it to the BlackBerry PlayBook 
in minutes. BlackBerry App World™ now supports Android™ Apps 
for the BlackBerry® PlayBook™. Discover just how easy and simple 
it is! http://p.sf.net/sfu/android-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Patches: torch MSI or WIXPDB ?

[robert_yang]

Thanks John for prodding me in the right direction.  After looking around a bit 
more (particularly Peter Marcu's blog entry of 30-May-2008) I did admin 
installs such as the following :

"msiexec /a orig\setupproject1.msi TARGETDIR=c:\wix\admin"

"msiexec /a new\setupproject1.msi TARGETDIR=c:\wix\admin2"

Then I ran torch with the -ax option :

"torch -ax c:\wix\admin2 -p -xo c:\wix\admin\setupproject1.msi 
c:\wix\admin2\setupproject1.msi -out patch\diff2.wixmst"

This seemed to work as desired.
-Rob

--
As the error message implies, you need to do an /admin install of the MSI 
before running pyro/torch so that it has access to the files if you don't want 
to use wixpdb's.

--
John Merryweather Cooper
Jack Henry & Associates, Inc. (Premier Tech, Inc.)
Build & Install Engineer - jXchange
Office:  913-341-3434 x791011
JoCooper@...




-Original Message-
From: robert_yang@... [mailto:robert_yang@...]
Sent: Tuesday, September 20, 2011 12:18 PM
To: wix-users@...
Subject: [WiX-users] Patches: torch MSI or WIXPDB ?

Hi all - I've been experimenting with torch/pyro/patching on our Wix installer, 
which I'm proud to say has completely replaced InstallShield for our 
application.

The thing I'm wondering about is this: do you have to use .wixpdb files as 
input to torch, or can you use .msi's instead ?  The docs imply the answer is 
"yes".  Everything works fine if I try using .wixpdb's but if I use .msi's I 
get the following error from pyro :

"pyro.exe : error PYRO0315 : Source information is required for the product 
'{GUID omitted}'. If you ran torch.exe with both target and updated .msi files, 
you must first perform an administrative installation of both  .msi files then 
pass -a when running torch.exe."

Here's how I invoked torch :

"torch -p -xo orig\SetupProject1.msi new\SetupProject1.msi -out 
patch\diff2.wixmst"

Are .wixpdb's really necessary to get this to work ?  Do the .MSI's not contain 
enough info by themselves ?  Thanks for any info !
-Rob

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Patches: torch MSI or WIXPDB ?

[robert_yang]

Hi all - I've been experimenting with torch/pyro/patching on our Wix installer, 
which I'm proud to say has completely replaced InstallShield for our 
application.

The thing I'm wondering about is this: do you have to use .wixpdb files as 
input to torch, or can you use .msi's instead ?  The docs imply the answer is 
"yes".  Everything works fine if I try using .wixpdb's but if I use .msi's I 
get the following error from pyro :

"pyro.exe : error PYRO0315 : Source information is required for the product 
'{GUID omitted}'. If you ran torch.exe with both target and updated .msi files, 
you must first perform an administrative installation of both  .msi files then 
pass -a when running torch.exe."

Here's how I invoked torch :

"torch -p -xo orig\SetupProject1.msi new\SetupProject1.msi -out 
patch\diff2.wixmst"

Are .wixpdb's really necessary to get this to work ?  Do the .MSI's not contain 
enough info by themselves ?  Thanks for any info !
-Rob

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Heat failing with HEAT5151

[robert_yang]

It seems to have been fixed on the build machine by swapping the order of the 
following lines in heat.exe.config :




I'm mystified, since this same config file works on my development box .. any 
ideas ?  Anyway, hope this helps !

-Original Message-
From: YANG,ROBERT (Non-A-SantaClara,ex1) 
Sent: Tuesday, August 23, 2011 2:16 PM
To: 'wix-users@lists.sourceforge.net'
Subject: Heat failing with HEAT5151

Hi all - we are suddenly having a problem with our build machine; Heat.exe is 
failing with HEAT5151 ("could not load assembly"), but only for assemblies 
which are exposed to COM.  Regular COM DLL's, OCX's and typelibs are harvesting 
just fine.

Someone installed .NET 4.0 on the build machine recently, but I have 4.0 on my 
development machine and Heat works fine there.  I saw a tracker defect # 
3078541 which seems possibly related (?)  Regasm is working on the build 
machine, too.  As I understand it, heat and regasm use the same class to get 
the registration info (System.Runtime.InteropServices.RegistrationServices).

Anyone ever seen this before ?  Easy fix ?  I'm hoping not to have to re-image 
the build machine .. thanks for any info !
-Rob


--
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management 
Up to 160% more powerful than alternatives and 25% more efficient. 
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Heat failing with HEAT5151

[robert_yang]

Hi all - we are suddenly having a problem with our build machine; Heat.exe is 
failing with HEAT5151 ("could not load assembly"), but only for assemblies 
which are exposed to COM.  Regular COM DLL's, OCX's and typelibs are harvesting 
just fine.

Someone installed .NET 4.0 on the build machine recently, but I have 4.0 on my 
development machine and Heat works fine there.  I saw a tracker defect # 
3078541 which seems possibly related (?)  Regasm is working on the build 
machine, too.  As I understand it, heat and regasm use the same class to get 
the registration info (System.Runtime.InteropServices.RegistrationServices).

Anyone ever seen this before ?  Easy fix ?  I'm hoping not to have to re-image 
the build machine .. thanks for any info !
-Rob


--
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management 
Up to 160% more powerful than alternatives and 25% more efficient. 
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] MajorUpgrade vs. InstallShield

[robert_yang]

Hi all - this is our company's first Wix installer, and so far it is working 
out very well.  The older products have an upgrade code which we can use in the 
Wix Product element to detect major upgrades.  There is just one problem: these 
older products use InstallShield (11.5 I think) and when the Windows Installer 
major upgrade goes to do RemoveExistingProducts the older .MSI gets removed, 
but the InstallShield "stuff" remains.

I looked in the archives, and it sounds like the InstallShield registry entry 
can be removed, as can the "\InstallShield Installation 
Information\{product code}" folder, presumably as a custom action scheduled 
after RemoveExistingProducts.

Our older IS setups were apparently not made to run silent uninstalls 
unfortunately.  I am unsure if this approach is the right one, and just 
wondering if anyone has done this and found any "gotchas" with it.  Thanks for 
any info!
-Rob

--
Get a FREE DOWNLOAD! and learn more about uberSVN rich system, 
user administration capabilities and model configuration. Take 
the hassle out of deploying and managing Subversion and the 
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Major upgrade opt-out ?

[robert_yang]

Just wanted to say thanks for all the advice : the WIX_UPGRADE_DETECTED 
condition worked well.

Sent: Monday, August 01, 2011 9:31 AM
To: 'wix-users@lists.sourceforge.net'
Subject: Major upgrade opt-out ?

We would like to be able to uninstall an older product, and install the new 
version.  I tried out the MajorUpgrade element, and it works well.  The only 
problem is that it seems to work silently  .. apparently we need to be able to 
prompt the user and ask them if it's OK to perform the upgrade.  Is this 
possible in Wix 3.5 ?

Thanks !
-Rob

--
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts. 
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Major upgrade opt-out ?

[robert_yang]

We would like to be able to uninstall an older product, and install the new 
version.  I tried out the MajorUpgrade element, and it works well.  The only 
problem is that it seems to work silently  .. apparently we need to be able to 
prompt the user and ask them if it's OK to perform the upgrade.  Is this 
possible in Wix 3.5 ?

Thanks !
-Rob

--
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] HEAT5150 and ATL registrar

[robert_yang]

Hi all - I'm working on an install with a somewhat large number of older COM 
objects and .NET classes exposed to COM.  For the most part, heat.exe works 
very well to move away from self-registration; very impressive.

We have had some issues, like how to deal with the inability of heat to harvest 
EXE servers.  For those I used RegSpy2 (the one on installsite.org) to create 
.reg files, which can then be used to create .wxs files.

The other issue is how to deal with the infamous HEAT5150 warning.  Admittedly 
we have only a few legacy DLL's which are affected.  Regspy2 harvests registry 
entries for these just fine, and I was curious to know why..

After looking through the regspy2 code, and then the Wix UtilExtension code, I 
realized that they were doing basically the same things -- registry redirection 
using RegOverridePredefKey.  The difference was that regspy2 was initializing 
the redirected registry with entries for the ATL Registrar COM object (see 
CreateAtlRegistrar in the regspy2 source code), which enabled these ancient 
DLL's to self-register.

I might modify my copy of UtilExtension, and perhaps add some hack like an -atl 
switch to enable a similar feature in heat.exe (if I make any progress on 
getting the source to build :), but primarily wanted to share this observation. 
 Cheers !
-Rob


--
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