Heat and .exe COM objects

[JK E-Lists]

I have an old out-of-process COM object that is wrapped in an EXE. It uses the /regserver and /unregserver command line parameters to register and unregister the COM object.

Heat appears to treat this as an ordinary executable, ignoring the fact that it's a COM object.

Can Heat extract the COM information, or do I just need to do it manually?

Thanks a lot!

jk

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users

[Blair-2]

Short answer: manually.

Long answer and call to action (if there is enough interest):

Unlike the import methods that RegSvr32.exe calls in DLLs, the /regserver
and /unregserver command line arguments are a convention that while common
is not universal. In addition, it is dangerous to run an unknown executable
since you never know if it even checks command-lines or not (that danger of
running foreign code also exists with DLLs, but the likelihood of trouble is
reduced since there isn't a lot you can do in DllMain and it is unlikely
that DllRegisterServer will be something else).

It would be possible to extend heat to call the /regserver commandline
although that would require some testing and not-so-conventional process
bootstrapping, but the largest difficulty is in how to communicate to the
tool which EXEs it should probe this way in a scalable fashion.

If list members wish to propose ways to identify EXE files that should be
harvested for COM, I am open to compiling them and distilling some proposals
back to the group for further refinement. Send them to [hidden email] with a
subject of "COM .exe harvesting".

-----Original Message-----
From: JK E-Lists [mailto:[hidden email]]
Sent: Wednesday, October 28, 2009 11:07 AM
To: [hidden email]
Subject: [WiX-users] Heat and .exe COM objects

I have an old out-of-process COM object that is wrapped in an EXE. It uses
the /regserver and /unregserver command line parameters to register and
unregister the COM object.

Heat appears to treat this as an ordinary executable, ignoring the fact that
it's a COM object.

Can Heat extract the COM information, or do I just need to do it manually?

Thanks a lot!

jk

----------------------------------------------------------------------------
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users

[Pally Sandher]

Heat can't extract the COM information from your executable but never
fear, all is not lost quite yet.
I've used a tool called RegSpy2 to harvest the /regserver information
from an out-of-process COM server executable in the past. It's available
at http://www.installsite.org/pages/en/msi/tips.htm (scroll down to the
section labelled "Capture Self-Registration Information")
It will output a .reg file which you'll need either manually convert
into WiX code or if you want to save yourself some time you can use
tallow.exe in WiX v2.0 then use WiXCop.exe on the .wxs tallow generates
to convert it to WiX v3.0/v3.5 code. Unfortunately heat.exe doesn't
support parsing .reg files into WiX code like tallow did/does so you
will need to download WiX v2.0 if you don't feel like manually writing
all the RegistryKey & RegistryValue entries yourself (you don't need to
install WiX v2.0 to use tallow, just download the binaries).

If you have the actual object which is wrapped in the executable you
could try running heat.exe on that & see if it generates the required
registration information which would save the hassle of the above
process.

Blair the source code for RegSpy2 is available on the above link. That
may help you modify heat.exe (or write an new tool separate from
heat.exe if that's what's easier). This comes up every couple of months
so there's definitely people who have a use for it (I'd certainly be
happier auto-generating WiX v3.0/v3.5 code than passing stuff through 3
different tools) & it might even discourage people from trying to take
the easy way out and do this type of thing using Custom Actions.


Palbinder Sandher
Software Deployment & IT Administrator
T: [phone]
F: [phone]

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

-----Original Message-----
From: Blair [mailto:[hidden email]]
Sent: 29 October 2009 04:42
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Heat and .exe COM objects

Short answer: manually.

Long answer and call to action (if there is enough interest):

Unlike the import methods that RegSvr32.exe calls in DLLs, the
/regserver and /unregserver command line arguments are a convention that
while common is not universal. In addition, it is dangerous to run an
unknown executable since you never know if it even checks command-lines
or not (that danger of running foreign code also exists with DLLs, but
the likelihood of trouble is reduced since there isn't a lot you can do
in DllMain and it is unlikely that DllRegisterServer will be something
else).

It would be possible to extend heat to call the /regserver commandline
although that would require some testing and not-so-conventional process
bootstrapping, but the largest difficulty is in how to communicate to
the tool which EXEs it should probe this way in a scalable fashion.

If list members wish to propose ways to identify EXE files that should
be harvested for COM, I am open to compiling them and distilling some
proposals back to the group for further refinement. Send them to
[hidden email] with a subject of "COM .exe harvesting".

-----Original Message-----
From: JK E-Lists [mailto:[hidden email]]
Sent: Wednesday, October 28, 2009 11:07 AM
To: [hidden email]
Subject: [WiX-users] Heat and .exe COM objects

I have an old out-of-process COM object that is wrapped in an EXE. It
uses the /regserver and /unregserver command line parameters to register
and unregister the COM object.

Heat appears to treat this as an ordinary executable, ignoring the fact
that it's a COM object.

Can Heat extract the COM information, or do I just need to do it
manually?

Thanks a lot!

jk

------------------------------------------------------------------------
----
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA is
the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and
stay ahead of the curve. Join us from November 9 - 12, 2009. Register
now!
http://p.sf.net/sfu/devconference
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users


------------------------------------------------------------------------
------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and
stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users



------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users

[Daniel Hughes-2]

Thanks,

Have done as you suggested (use RegSpy2 then Tallow then RegCop) but
have run into three problems which make it hard to automate.

Firstly RegSpy2 throws a "File not Found" message box up which you have
to click ok on (it still works), if you look in the code there is
comment which says he doesn't know why this happens. This makes it hard
to automate.

Secondly, the wix tallow creates doesn't have a component and so is
invalid the <RegistryValue> tag can no be a child of <Fragment>,  RegCop
does not fix this, So I would have to copy the registry tags into a
component to make it work.

Thirdly the Registry values have the location of the ActiveX exe file
hard coded, this could be solved with a find and replace.

If anyone has any ideas on how to easily overcome any of the above
problems please let me know.

Cheers,
Daniel



Pally Sandher wrote:

> Heat can't extract the COM information from your executable but never
> fear, all is not lost quite yet.
> I've used a tool called RegSpy2 to harvest the /regserver information
> from an out-of-process COM server executable in the past. It's available
> at http://www.installsite.org/pages/en/msi/tips.htm (scroll down to the
> section labelled "Capture Self-Registration Information")
> It will output a .reg file which you'll need either manually convert
> into WiX code or if you want to save yourself some time you can use
> tallow.exe in WiX v2.0 then use WiXCop.exe on the .wxs tallow generates
> to convert it to WiX v3.0/v3.5 code. Unfortunately heat.exe doesn't
> support parsing .reg files into WiX code like tallow did/does so you
> will need to download WiX v2.0 if you don't feel like manually writing
> all the RegistryKey & RegistryValue entries yourself (you don't need to
> install WiX v2.0 to use tallow, just download the binaries).
>
> If you have the actual object which is wrapped in the executable you
> could try running heat.exe on that & see if it generates the required
> registration information which would save the hassle of the above
> process.
>
> Blair the source code for RegSpy2 is available on the above link. That
> may help you modify heat.exe (or write an new tool separate from
> heat.exe if that's what's easier). This comes up every couple of months
> so there's definitely people who have a use for it (I'd certainly be
> happier auto-generating WiX v3.0/v3.5 code than passing stuff through 3
> different tools) & it might even discourage people from trying to take
> the easy way out and do this type of thing using Custom Actions.
>
>
> Palbinder Sandher
> Software Deployment & IT Administrator
> T: [phone]
> F: [phone]
>
> http://www.iesve.com 
> **Design, Simulate + Innovate with the <Virtual Environment>**
> Integrated Environmental Solutions Limited. Registered in Scotland No.
> SC151456
> Registered Office - Helix Building, West Of Scotland Science Park,
> Glasgow G20 0SP
> Email Disclaimer
>  
>
> -----Original Message-----
> From: Blair [mailto:[hidden email]]
> Sent: 29 October 2009 04:42
> To: 'General discussion for Windows Installer XML toolset.'
> Subject: Re: [WiX-users] Heat and .exe COM objects
>
> Short answer: manually.
>
> Long answer and call to action (if there is enough interest):
>
> Unlike the import methods that RegSvr32.exe calls in DLLs, the
> /regserver and /unregserver command line arguments are a convention that
> while common is not universal. In addition, it is dangerous to run an
> unknown executable since you never know if it even checks command-lines
> or not (that danger of running foreign code also exists with DLLs, but
> the likelihood of trouble is reduced since there isn't a lot you can do
> in DllMain and it is unlikely that DllRegisterServer will be something
> else).
>
> It would be possible to extend heat to call the /regserver commandline
> although that would require some testing and not-so-conventional process
> bootstrapping, but the largest difficulty is in how to communicate to
> the tool which EXEs it should probe this way in a scalable fashion.
>
> If list members wish to propose ways to identify EXE files that should
> be harvested for COM, I am open to compiling them and distilling some
> proposals back to the group for further refinement. Send them to
> [hidden email] with a subject of "COM .exe harvesting".
>
> -----Original Message-----
> From: JK E-Lists [mailto:[hidden email]]
> Sent: Wednesday, October 28, 2009 11:07 AM
> To: [hidden email]
> Subject: [WiX-users] Heat and .exe COM objects
>
> I have an old out-of-process COM object that is wrapped in an EXE. It
> uses the /regserver and /unregserver command line parameters to register
> and unregister the COM object.
>
> Heat appears to treat this as an ordinary executable, ignoring the fact
> that it's a COM object.
>
> Can Heat extract the COM information, or do I just need to do it
> manually?
>
> Thanks a lot!
>
> jk
>
> ------------------------------------------------------------------------
> ----
> --
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA is
> the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and
> stay ahead of the curve. Join us from November 9 - 12, 2009. Register
> now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> WiX-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> ------------------------------------------------------------------------
> ------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and
> stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> WiX-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> WiX-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>  

=======================================================================
This email, including any attachments, is only for the intended
addressee.  It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
 altered or corrupted during transmission.
=======================================================================


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users

[Daniel Hughes-2]

By the way for anyone thinking I should generate the WiX xml by hand,
the WiX output from the suggested method (RegSpy2 + Tallow + RegCop)
produces 700 lines of xml. If you have several of these ActiveX exes to
register like I do then doing this by hands would involve writing
several thousand lines of XML....... no thanks.

Pally Sandher wrote:

> Heat can't extract the COM information from your executable but never
> fear, all is not lost quite yet.
> I've used a tool called RegSpy2 to harvest the /regserver information
> from an out-of-process COM server executable in the past. It's available
> at http://www.installsite.org/pages/en/msi/tips.htm (scroll down to the
> section labelled "Capture Self-Registration Information")
> It will output a .reg file which you'll need either manually convert
> into WiX code or if you want to save yourself some time you can use
> tallow.exe in WiX v2.0 then use WiXCop.exe on the .wxs tallow generates
> to convert it to WiX v3.0/v3.5 code. Unfortunately heat.exe doesn't
> support parsing .reg files into WiX code like tallow did/does so you
> will need to download WiX v2.0 if you don't feel like manually writing
> all the RegistryKey & RegistryValue entries yourself (you don't need to
> install WiX v2.0 to use tallow, just download the binaries).
>
> If you have the actual object which is wrapped in the executable you
> could try running heat.exe on that & see if it generates the required
> registration information which would save the hassle of the above
> process.
>
> Blair the source code for RegSpy2 is available on the above link. That
> may help you modify heat.exe (or write an new tool separate from
> heat.exe if that's what's easier). This comes up every couple of months
> so there's definitely people who have a use for it (I'd certainly be
> happier auto-generating WiX v3.0/v3.5 code than passing stuff through 3
> different tools) & it might even discourage people from trying to take
> the easy way out and do this type of thing using Custom Actions.
>
>
> Palbinder Sandher
> Software Deployment & IT Administrator
> T: [phone]
> F: [phone]
>
> http://www.iesve.com 
> **Design, Simulate + Innovate with the <Virtual Environment>**
> Integrated Environmental Solutions Limited. Registered in Scotland No.
> SC151456
> Registered Office - Helix Building, West Of Scotland Science Park,
> Glasgow G20 0SP
> Email Disclaimer
>  
>
> -----Original Message-----
> From: Blair [mailto:[hidden email]]
> Sent: 29 October 2009 04:42
> To: 'General discussion for Windows Installer XML toolset.'
> Subject: Re: [WiX-users] Heat and .exe COM objects
>
> Short answer: manually.
>
> Long answer and call to action (if there is enough interest):
>
> Unlike the import methods that RegSvr32.exe calls in DLLs, the
> /regserver and /unregserver command line arguments are a convention that
> while common is not universal. In addition, it is dangerous to run an
> unknown executable since you never know if it even checks command-lines
> or not (that danger of running foreign code also exists with DLLs, but
> the likelihood of trouble is reduced since there isn't a lot you can do
> in DllMain and it is unlikely that DllRegisterServer will be something
> else).
>
> It would be possible to extend heat to call the /regserver commandline
> although that would require some testing and not-so-conventional process
> bootstrapping, but the largest difficulty is in how to communicate to
> the tool which EXEs it should probe this way in a scalable fashion.
>
> If list members wish to propose ways to identify EXE files that should
> be harvested for COM, I am open to compiling them and distilling some
> proposals back to the group for further refinement. Send them to
> [hidden email] with a subject of "COM .exe harvesting".
>
> -----Original Message-----
> From: JK E-Lists [mailto:[hidden email]]
> Sent: Wednesday, October 28, 2009 11:07 AM
> To: [hidden email]
> Subject: [WiX-users] Heat and .exe COM objects
>
> I have an old out-of-process COM object that is wrapped in an EXE. It
> uses the /regserver and /unregserver command line parameters to register
> and unregister the COM object.
>
> Heat appears to treat this as an ordinary executable, ignoring the fact
> that it's a COM object.
>
> Can Heat extract the COM information, or do I just need to do it
> manually?
>
> Thanks a lot!
>
> jk
>
> ------------------------------------------------------------------------
> ----
> --
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA is
> the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and
> stay ahead of the curve. Join us from November 9 - 12, 2009. Register
> now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> WiX-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> ------------------------------------------------------------------------
> ------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and
> stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> WiX-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> WiX-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>  

=======================================================================
This email, including any attachments, is only for the intended
addressee.  It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
 altered or corrupted during transmission.
=======================================================================


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users

[Bob Arnson-6]

Daniel Hughes wrote:
> Have done as you suggested (use RegSpy2 then Tallow then RegCop) but
> have run into three problems which make it hard to automate.
>  

So don't automate it; run it once and maintain the authoring as needed.
It's an inherently fragile process so you'll probably spend more trying
to automate it than you save in maintenance costs.

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



------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users

[Neil Sleightholm]

I would disagree, do it by hand, I would want to know what was being  
registered. I would be fairly sure that many of these registry entries  
are not required. Are these exes vb by any chance, vb has a habit of  
adding extra registration - it registers the vb runtime everytime.  
Also, this is a one off and not really something that needs automating  
as part of a build process.

Neil

Neil Sleightholm
[hidden email]

On 29 Oct 2009, at 23:20, "Daniel Hughes" <[hidden email]>  
wrote:

> By the way for anyone thinking I should generate the WiX xml by hand,
> the WiX output from the suggested method (RegSpy2 + Tallow + RegCop)
> produces 700 lines of xml. If you have several of these ActiveX exes  
> to
> register like I do then doing this by hands would involve writing
> several thousand lines of XML....... no thanks.
>
> Pally Sandher wrote:
>> Heat can't extract the COM information from your executable but never
>> fear, all is not lost quite yet.
>> I've used a tool called RegSpy2 to harvest the /regserver information
>> from an out-of-process COM server executable in the past. It's  
>> available
>> at http://www.installsite.org/pages/en/msi/tips.htm (scroll down to  
>> the
>> section labelled "Capture Self-Registration Information")
>> It will output a .reg file which you'll need either manually convert
>> into WiX code or if you want to save yourself some time you can use
>> tallow.exe in WiX v2.0 then use WiXCop.exe on the .wxs tallow  
>> generates
>> to convert it to WiX v3.0/v3.5 code. Unfortunately heat.exe doesn't
>> support parsing .reg files into WiX code like tallow did/does so you
>> will need to download WiX v2.0 if you don't feel like manually  
>> writing
>> all the RegistryKey & RegistryValue entries yourself (you don't  
>> need to
>> install WiX v2.0 to use tallow, just download the binaries).
>>
>> If you have the actual object which is wrapped in the executable you
>> could try running heat.exe on that & see if it generates the required
>> registration information which would save the hassle of the above
>> process.
>>
>> Blair the source code for RegSpy2 is available on the above link.  
>> That
>> may help you modify heat.exe (or write an new tool separate from
>> heat.exe if that's what's easier). This comes up every couple of  
>> months
>> so there's definitely people who have a use for it (I'd certainly be
>> happier auto-generating WiX v3.0/v3.5 code than passing stuff  
>> through 3
>> different tools) & it might even discourage people from trying to  
>> take
>> the easy way out and do this type of thing using Custom Actions.
>>
>>
>> Palbinder Sandher
>> Software Deployment & IT Administrator
>> T: [phone]
>> F: [phone]
>>
>> http://www.iesve.com
>> **Design, Simulate + Innovate with the <Virtual Environment>**
>> Integrated Environmental Solutions Limited. Registered in Scotland  
>> No.
>> SC151456
>> Registered Office - Helix Building, West Of Scotland Science Park,
>> Glasgow G20 0SP
>> Email Disclaimer
>>
>>
>> -----Original Message-----
>> From: Blair [mailto:[hidden email]]
>> Sent: 29 October 2009 04:42
>> To: 'General discussion for Windows Installer XML toolset.'
>> Subject: Re: [WiX-users] Heat and .exe COM objects
>>
>> Short answer: manually.
>>
>> Long answer and call to action (if there is enough interest):
>>
>> Unlike the import methods that RegSvr32.exe calls in DLLs, the
>> /regserver and /unregserver command line arguments are a convention  
>> that
>> while common is not universal. In addition, it is dangerous to run an
>> unknown executable since you never know if it even checks command-
>> lines
>> or not (that danger of running foreign code also exists with DLLs,  
>> but
>> the likelihood of trouble is reduced since there isn't a lot you  
>> can do
>> in DllMain and it is unlikely that DllRegisterServer will be  
>> something
>> else).
>>
>> It would be possible to extend heat to call the /regserver  
>> commandline
>> although that would require some testing and not-so-conventional  
>> process
>> bootstrapping, but the largest difficulty is in how to communicate to
>> the tool which EXEs it should probe this way in a scalable fashion.
>>
>> If list members wish to propose ways to identify EXE files that  
>> should
>> be harvested for COM, I am open to compiling them and distilling some
>> proposals back to the group for further refinement. Send them to
>> [hidden email] with a subject of "COM .exe harvesting".
>>
>> -----Original Message-----
>> From: JK E-Lists [mailto:[hidden email]]
>> Sent: Wednesday, October 28, 2009 11:07 AM
>> To: [hidden email]
>> Subject: [WiX-users] Heat and .exe COM objects
>>
>> I have an old out-of-process COM object that is wrapped in an EXE. It
>> uses the /regserver and /unregserver command line parameters to  
>> register
>> and unregister the COM object.
>>
>> Heat appears to treat this as an ordinary executable, ignoring the  
>> fact
>> that it's a COM object.
>>
>> Can Heat extract the COM information, or do I just need to do it
>> manually?
>>
>> Thanks a lot!
>>
>> jk
>>
>> ---
>> ---------------------------------------------------------------------
>> ----
>> --
>> Come build with us! The BlackBerry(R) Developer Conference in SF,  
>> CA is
>> the only developer event you need to attend this year. Jumpstart your
>> developing skills, take BlackBerry mobile applications to market and
>> stay ahead of the curve. Join us from November 9 - 12, 2009. Register
>> now!
>> http://p.sf.net/sfu/devconference
>> _______________________________________________
>> WiX-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>
>>
>> ---
>> ---------------------------------------------------------------------
>> ------
>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart  
>> your
>> developing skills, take BlackBerry mobile applications to market and
>> stay
>> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>> http://p.sf.net/sfu/devconference
>> _______________________________________________
>> WiX-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>
>>
>>
>> ---
>> ---
>> ---
>> ---------------------------------------------------------------------
>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart  
>> your
>> developing skills, take BlackBerry mobile applications to market  
>> and stay
>> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>> http://p.sf.net/sfu/devconference
>> _______________________________________________
>> WiX-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>
>>
>
>
> ===
> ====================================================================
> This email, including any attachments, is only for the intended
> addressee.  It is subject to copyright, is confidential and may be
> the subject of legal or other privilege, none of which is waived or
> lost by reason of this transmission.
> If the receiver is not the intended addressee, please accept our
> apologies, notify us by return, delete all copies and perform no
> other act on the email.
> Unfortunately, we cannot warrant that the email has not been
> altered or corrupted during transmission.
> ===
> ====================================================================
>
>
> ---
> ---
> ---
> ---------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart  
> your
> developing skills, take BlackBerry mobile applications to market and  
> stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> WiX-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-users

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users

[Rob Mensching-7]

In addition to what Neil says, there are elements in the WiX toolset that
abstract the grand majority of the COM registration that can sometimes take
30 registry keys and make them one line of XML. The end result is far more
readable and thus maintainable, IMHO.

On Fri, Oct 30, 2009 at 2:13 AM, Neil Sleightholm <[hidden email]>wrote:

> I would disagree, do it by hand, I would want to know what was being
> registered. I would be fairly sure that many of these registry entries
> are not required. Are these exes vb by any chance, vb has a habit of
> adding extra registration - it registers the vb runtime everytime.
> Also, this is a one off and not really something that needs automating
> as part of a build process.
>
> Neil
>
> Neil Sleightholm
> [hidden email]
>
> On 29 Oct 2009, at 23:20, "Daniel Hughes" <[hidden email]>
> wrote:
>
> > By the way for anyone thinking I should generate the WiX xml by hand,
> > the WiX output from the suggested method (RegSpy2 + Tallow + RegCop)
> > produces 700 lines of xml. If you have several of these ActiveX exes
> > to
> > register like I do then doing this by hands would involve writing
> > several thousand lines of XML....... no thanks.
> >
> > Pally Sandher wrote:
> >> Heat can't extract the COM information from your executable but never
> >> fear, all is not lost quite yet.
> >> I've used a tool called RegSpy2 to harvest the /regserver information
> >> from an out-of-process COM server executable in the past. It's
> >> available
> >> at http://www.installsite.org/pages/en/msi/tips.htm (scroll down to
> >> the
> >> section labelled "Capture Self-Registration Information")
> >> It will output a .reg file which you'll need either manually convert
> >> into WiX code or if you want to save yourself some time you can use
> >> tallow.exe in WiX v2.0 then use WiXCop.exe on the .wxs tallow
> >> generates
> >> to convert it to WiX v3.0/v3.5 code. Unfortunately heat.exe doesn't
> >> support parsing .reg files into WiX code like tallow did/does so you
> >> will need to download WiX v2.0 if you don't feel like manually
> >> writing
> >> all the RegistryKey & RegistryValue entries yourself (you don't
> >> need to
> >> install WiX v2.0 to use tallow, just download the binaries).
> >>
> >> If you have the actual object which is wrapped in the executable you
> >> could try running heat.exe on that & see if it generates the required
> >> registration information which would save the hassle of the above
> >> process.
> >>
> >> Blair the source code for RegSpy2 is available on the above link.
> >> That
> >> may help you modify heat.exe (or write an new tool separate from
> >> heat.exe if that's what's easier). This comes up every couple of
> >> months
> >> so there's definitely people who have a use for it (I'd certainly be
> >> happier auto-generating WiX v3.0/v3.5 code than passing stuff
> >> through 3
> >> different tools) & it might even discourage people from trying to
> >> take
> >> the easy way out and do this type of thing using Custom Actions.
> >>
> >>
> >> Palbinder Sandher
> >> Software Deployment & IT Administrator
> >> T: [phone]
> >> F: [phone]
> >>
> >> http://www.iesve.com
> >> **Design, Simulate + Innovate with the <Virtual Environment>**
> >> Integrated Environmental Solutions Limited. Registered in Scotland
> >> No.
> >> SC151456
> >> Registered Office - Helix Building, West Of Scotland Science Park,
> >> Glasgow G20 0SP
> >> Email Disclaimer
> >>
> >>
> >> -----Original Message-----
> >> From: Blair [mailto:[hidden email]]
> >> Sent: 29 October 2009 04:42
> >> To: 'General discussion for Windows Installer XML toolset.'
> >> Subject: Re: [WiX-users] Heat and .exe COM objects
> >>
> >> Short answer: manually.
> >>
> >> Long answer and call to action (if there is enough interest):
> >>
> >> Unlike the import methods that RegSvr32.exe calls in DLLs, the
> >> /regserver and /unregserver command line arguments are a convention
> >> that
> >> while common is not universal. In addition, it is dangerous to run an
> >> unknown executable since you never know if it even checks command-
> >> lines
> >> or not (that danger of running foreign code also exists with DLLs,
> >> but
> >> the likelihood of trouble is reduced since there isn't a lot you
> >> can do
> >> in DllMain and it is unlikely that DllRegisterServer will be
> >> something
> >> else).
> >>
> >> It would be possible to extend heat to call the /regserver
> >> commandline
> >> although that would require some testing and not-so-conventional
> >> process
> >> bootstrapping, but the largest difficulty is in how to communicate to
> >> the tool which EXEs it should probe this way in a scalable fashion.
> >>
> >> If list members wish to propose ways to identify EXE files that
> >> should
> >> be harvested for COM, I am open to compiling them and distilling some
> >> proposals back to the group for further refinement. Send them to
> >> [hidden email] with a subject of "COM .exe harvesting".
> >>
> >> -----Original Message-----
> >> From: JK E-Lists [mailto:[hidden email]]
> >> Sent: Wednesday, October 28, 2009 11:07 AM
> >> To: [hidden email]
> >> Subject: [WiX-users] Heat and .exe COM objects
> >>
> >> I have an old out-of-process COM object that is wrapped in an EXE. It
> >> uses the /regserver and /unregserver command line parameters to
> >> register
> >> and unregister the COM object.
> >>
> >> Heat appears to treat this as an ordinary executable, ignoring the
> >> fact
> >> that it's a COM object.
> >>
> >> Can Heat extract the COM information, or do I just need to do it
> >> manually?
> >>
> >> Thanks a lot!
> >>
> >> jk
> >>
> >> ---
> >> ---------------------------------------------------------------------
> >> ----
> >> --
> >> Come build with us! The BlackBerry(R) Developer Conference in SF,
> >> CA is
> >> the only developer event you need to attend this year. Jumpstart your
> >> developing skills, take BlackBerry mobile applications to market and
> >> stay ahead of the curve. Join us from November 9 - 12, 2009. Register
> >> now!
> >> http://p.sf.net/sfu/devconference
> >> _______________________________________________
> >> WiX-users mailing list
> >> [hidden email]
> >> https://lists.sourceforge.net/lists/listinfo/wix-users
> >>
> >>
> >> ---
> >> ---------------------------------------------------------------------
> >> ------
> >> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> >> is the only developer event you need to attend this year. Jumpstart
> >> your
> >> developing skills, take BlackBerry mobile applications to market and
> >> stay
> >> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> >> http://p.sf.net/sfu/devconference
> >> _______________________________________________
> >> WiX-users mailing list
> >> [hidden email]
> >> https://lists.sourceforge.net/lists/listinfo/wix-users
> >>
> >>
> >>
> >> ---
> >> ---
> >> ---
> >> ---------------------------------------------------------------------
> >> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> >> is the only developer event you need to attend this year. Jumpstart
> >> your
> >> developing skills, take BlackBerry mobile applications to market
> >> and stay
> >> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> >> http://p.sf.net/sfu/devconference
> >> _______________________________________________
> >> WiX-users mailing list
> >> [hidden email]
> >> https://lists.sourceforge.net/lists/listinfo/wix-users
> >>
> >>
> >
> >
> > ===
> > ====================================================================
> > This email, including any attachments, is only for the intended
> > addressee.  It is subject to copyright, is confidential and may be
> > the subject of legal or other privilege, none of which is waived or
> > lost by reason of this transmission.
> > If the receiver is not the intended addressee, please accept our
> > apologies, notify us by return, delete all copies and perform no
> > other act on the email.
> > Unfortunately, we cannot warrant that the email has not been
> > altered or corrupted during transmission.
> > ===
> > ====================================================================
> >
> >
> > ---
> > ---
> > ---
> > ---------------------------------------------------------------------
> > Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> > is the only developer event you need to attend this year. Jumpstart
> > your
> > developing skills, take BlackBerry mobile applications to market and
> > stay
> > ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> > http://p.sf.net/sfu/devconference
> > _______________________________________________
> > WiX-users mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> WiX-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>

--
virtually, Rob Mensching - http://RobMensching.com LLC
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users

[Daniel Hughes-2]

This is not a one off as it will need to be changed if the interface
changes.

When I described the process to be team they all said there is no way
they are doing that, and that I should just use /regserver and
/unregserver custom actions,

1. They could not understand why a supported feature should not be used.
2. They can not accept that something that just works in install shield
should not be used.
3. They point out we have not had any problem from a install shield
installers caused by self reg.
4. Quote "The mechanism that you are proposing as a replacement for COM
self registration sounds at first hearing about it to be labour
intensive, fiddly and brittle."

The ActiveX exe in question are shared between multiple project and so
must only be unregistered when the last one is removed. My workmates
tell me that Install Shield keeps a count and only runs /unregserver
when the last component is removed. They want me to replicate this
behavior using WiX.

How do I set up a custom action to unregister the ActiveX exes only when
all programs using them are uninstalled?


Neil Sleightholm wrote:

> I would disagree, do it by hand, I would want to know what was being  
> registered. I would be fairly sure that many of these registry entries  
> are not required. Are these exes vb by any chance, vb has a habit of  
> adding extra registration - it registers the vb runtime everytime.  
> Also, this is a one off and not really something that needs automating  
> as part of a build process.
>
> Neil
>
> Neil Sleightholm
> [hidden email]
>
> On 29 Oct 2009, at 23:20, "Daniel Hughes" <[hidden email]>  
> wrote:
>
>  
>> By the way for anyone thinking I should generate the WiX xml by hand,
>> the WiX output from the suggested method (RegSpy2 + Tallow + RegCop)
>> produces 700 lines of xml. If you have several of these ActiveX exes  
>> to
>> register like I do then doing this by hands would involve writing
>> several thousand lines of XML....... no thanks.
>>
>> Pally Sandher wrote:
>>    
>>> Heat can't extract the COM information from your executable but never
>>> fear, all is not lost quite yet.
>>> I've used a tool called RegSpy2 to harvest the /regserver information
>>> from an out-of-process COM server executable in the past. It's  
>>> available
>>> at http://www.installsite.org/pages/en/msi/tips.htm (scroll down to  
>>> the
>>> section labelled "Capture Self-Registration Information")
>>> It will output a .reg file which you'll need either manually convert
>>> into WiX code or if you want to save yourself some time you can use
>>> tallow.exe in WiX v2.0 then use WiXCop.exe on the .wxs tallow  
>>> generates
>>> to convert it to WiX v3.0/v3.5 code. Unfortunately heat.exe doesn't
>>> support parsing .reg files into WiX code like tallow did/does so you
>>> will need to download WiX v2.0 if you don't feel like manually  
>>> writing
>>> all the RegistryKey & RegistryValue entries yourself (you don't  
>>> need to
>>> install WiX v2.0 to use tallow, just download the binaries).
>>>
>>> If you have the actual object which is wrapped in the executable you
>>> could try running heat.exe on that & see if it generates the required
>>> registration information which would save the hassle of the above
>>> process.
>>>
>>> Blair the source code for RegSpy2 is available on the above link.  
>>> That
>>> may help you modify heat.exe (or write an new tool separate from
>>> heat.exe if that's what's easier). This comes up every couple of  
>>> months
>>> so there's definitely people who have a use for it (I'd certainly be
>>> happier auto-generating WiX v3.0/v3.5 code than passing stuff  
>>> through 3
>>> different tools) & it might even discourage people from trying to  
>>> take
>>> the easy way out and do this type of thing using Custom Actions.
>>>
>>>
>>> Palbinder Sandher
>>> Software Deployment & IT Administrator
>>> T: [phone]
>>> F: [phone]
>>>
>>> http://www.iesve.com
>>> **Design, Simulate + Innovate with the <Virtual Environment>**
>>> Integrated Environmental Solutions Limited. Registered in Scotland  
>>> No.
>>> SC151456
>>> Registered Office - Helix Building, West Of Scotland Science Park,
>>> Glasgow G20 0SP
>>> Email Disclaimer
>>>
>>>
>>> -----Original Message-----
>>> From: Blair [mailto:[hidden email]]
>>> Sent: 29 October 2009 04:42
>>> To: 'General discussion for Windows Installer XML toolset.'
>>> Subject: Re: [WiX-users] Heat and .exe COM objects
>>>
>>> Short answer: manually.
>>>
>>> Long answer and call to action (if there is enough interest):
>>>
>>> Unlike the import methods that RegSvr32.exe calls in DLLs, the
>>> /regserver and /unregserver command line arguments are a convention  
>>> that
>>> while common is not universal. In addition, it is dangerous to run an
>>> unknown executable since you never know if it even checks command-
>>> lines
>>> or not (that danger of running foreign code also exists with DLLs,  
>>> but
>>> the likelihood of trouble is reduced since there isn't a lot you  
>>> can do
>>> in DllMain and it is unlikely that DllRegisterServer will be  
>>> something
>>> else).
>>>
>>> It would be possible to extend heat to call the /regserver  
>>> commandline
>>> although that would require some testing and not-so-conventional  
>>> process
>>> bootstrapping, but the largest difficulty is in how to communicate to
>>> the tool which EXEs it should probe this way in a scalable fashion.
>>>
>>> If list members wish to propose ways to identify EXE files that  
>>> should
>>> be harvested for COM, I am open to compiling them and distilling some
>>> proposals back to the group for further refinement. Send them to
>>> [hidden email] with a subject of "COM .exe harvesting".
>>>
>>> -----Original Message-----
>>> From: JK E-Lists [mailto:[hidden email]]
>>> Sent: Wednesday, October 28, 2009 11:07 AM
>>> To: [hidden email]
>>> Subject: [WiX-users] Heat and .exe COM objects
>>>
>>> I have an old out-of-process COM object that is wrapped in an EXE. It
>>> uses the /regserver and /unregserver command line parameters to  
>>> register
>>> and unregister the COM object.
>>>
>>> Heat appears to treat this as an ordinary executable, ignoring the  
>>> fact
>>> that it's a COM object.
>>>
>>> Can Heat extract the COM information, or do I just need to do it
>>> manually?
>>>
>>> Thanks a lot!
>>>
>>> jk
>>>
>>> ---
>>> ---------------------------------------------------------------------
>>> ----
>>> --
>>> Come build with us! The BlackBerry(R) Developer Conference in SF,  
>>> CA is
>>> the only developer event you need to attend this year. Jumpstart your
>>> developing skills, take BlackBerry mobile applications to market and
>>> stay ahead of the curve. Join us from November 9 - 12, 2009. Register
>>> now!
>>> http://p.sf.net/sfu/devconference
>>> _______________________________________________
>>> WiX-users mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>>
>>>
>>> ---
>>> ---------------------------------------------------------------------
>>> ------
>>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>>> is the only developer event you need to attend this year. Jumpstart  
>>> your
>>> developing skills, take BlackBerry mobile applications to market and
>>> stay
>>> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>>> http://p.sf.net/sfu/devconference
>>> _______________________________________________
>>> WiX-users mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>>
>>>
>>>
>>> ---
>>> ---
>>> ---
>>> ---------------------------------------------------------------------
>>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>>> is the only developer event you need to attend this year. Jumpstart  
>>> your
>>> developing skills, take BlackBerry mobile applications to market  
>>> and stay
>>> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>>> http://p.sf.net/sfu/devconference
>>> _______________________________________________
>>> WiX-users mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>>
>>>
>>>      
>> ===
>> ====================================================================
>> This email, including any attachments, is only for the intended
>> addressee.  It is subject to copyright, is confidential and may be
>> the subject of legal or other privilege, none of which is waived or
>> lost by reason of this transmission.
>> If the receiver is not the intended addressee, please accept our
>> apologies, notify us by return, delete all copies and perform no
>> other act on the email.
>> Unfortunately, we cannot warrant that the email has not been
>> altered or corrupted during transmission.
>> ===
>> ====================================================================
>>
>>
>> ---
>> ---
>> ---
>> ---------------------------------------------------------------------
>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart  
>> your
>> developing skills, take BlackBerry mobile applications to market and  
>> stay
>> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>> http://p.sf.net/sfu/devconference
>> _______________________________________________
>> WiX-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>    
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> WiX-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>  

=======================================================================
This email, including any attachments, is only for the intended
addressee.  It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
 altered or corrupted during transmission.
=======================================================================


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users

[JK E-Lists]

*sigh* Sorry for this... being a WiX dummy, I'm having difficulty  
finding this in the docs. Could I ask for a pointer to what's probably  
right in front of my face?

(For me, the COM exe is static; the interface won't be changing.  
Nevertheless the idea of a minimal XML is appealing.)


On 2009/10/30, at 10:01, Rob Mensching wrote:

> In addition to what Neil says, there are elements in the WiX toolset  
> that
> abstract the grand majority of the COM registration that can  
> sometimes take
> 30 registry keys and make them one line of XML. The end result is  
> far more
> readable and thus maintainable, IMHO.




------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users

[Neil Sleightholm]

I know it sounds a pain but it is really worthwhile adopting. What
regserver does is not standard it is developer dependant and you can do
anything in that code.

You say it would need rework when the interface changes, that is correct
but that shouldn't happen that often and should be well defined. If you
are coding in C++ then you will have to write the self reg code so will
know all the details. It sounds to me like you are using VB which is
hiding all the complexity (and in my experience making it worse).

1. I am not sure it is "supported", it is commonly done.
2. I bet it doesn't just work, it works on their machines :-) Once it
gets out in the wild I have seem all sorts of issues with self reg.
3. I am surprised but I guess you might only deploy to well known clean
environments.
4. Personally I would argue that self reg fits that description.

You final point about sharing is the killer for me, if you do it with
reference counting it will break, doing it with WiX registry entries
won't. Have you tried opening the InstallShield MSI with Orca to see how
they implement the self reg, it may be that it actually implements the
registry keys.

There is no way to setup a custom action to work like this without
implementing your own reference counting.

Obviously these are my opinions and you are welcome to ignore them!

Neil

-----Original Message-----
From: Daniel Hughes [mailto:[hidden email]]
Sent: 01 November 2009 22:44
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Heat and .exe COM objects

This is not a one off as it will need to be changed if the interface
changes.

When I described the process to be team they all said there is no way
they are doing that, and that I should just use /regserver and
/unregserver custom actions,

1. They could not understand why a supported feature should not be used.
2. They can not accept that something that just works in install shield
should not be used.
3. They point out we have not had any problem from a install shield
installers caused by self reg.
4. Quote "The mechanism that you are proposing as a replacement for COM
self registration sounds at first hearing about it to be labour
intensive, fiddly and brittle."

The ActiveX exe in question are shared between multiple project and so
must only be unregistered when the last one is removed. My workmates
tell me that Install Shield keeps a count and only runs /unregserver
when the last component is removed. They want me to replicate this
behavior using WiX.

How do I set up a custom action to unregister the ActiveX exes only when

all programs using them are uninstalled?


Neil Sleightholm wrote:
> I would disagree, do it by hand, I would want to know what was being  
> registered. I would be fairly sure that many of these registry entries

> are not required. Are these exes vb by any chance, vb has a habit of  
> adding extra registration - it registers the vb runtime everytime.  
> Also, this is a one off and not really something that needs automating

> as part of a build process.
>
> Neil
>
> Neil Sleightholm
> [hidden email]
>
> On 29 Oct 2009, at 23:20, "Daniel Hughes" <[hidden email]>  
> wrote:
>
>  
>> By the way for anyone thinking I should generate the WiX xml by hand,
>> the WiX output from the suggested method (RegSpy2 + Tallow + RegCop)
>> produces 700 lines of xml. If you have several of these ActiveX exes

>> to
>> register like I do then doing this by hands would involve writing
>> several thousand lines of XML....... no thanks.
>>
>> Pally Sandher wrote:
>>    
>>> Heat can't extract the COM information from your executable but
never
>>> fear, all is not lost quite yet.
>>> I've used a tool called RegSpy2 to harvest the /regserver
information
>>> from an out-of-process COM server executable in the past. It's  
>>> available
>>> at http://www.installsite.org/pages/en/msi/tips.htm (scroll down to

>>> the
>>> section labelled "Capture Self-Registration Information")
>>> It will output a .reg file which you'll need either manually convert
>>> into WiX code or if you want to save yourself some time you can use
>>> tallow.exe in WiX v2.0 then use WiXCop.exe on the .wxs tallow  
>>> generates
>>> to convert it to WiX v3.0/v3.5 code. Unfortunately heat.exe doesn't
>>> support parsing .reg files into WiX code like tallow did/does so you
>>> will need to download WiX v2.0 if you don't feel like manually  
>>> writing
>>> all the RegistryKey & RegistryValue entries yourself (you don't  
>>> need to
>>> install WiX v2.0 to use tallow, just download the binaries).
>>>
>>> If you have the actual object which is wrapped in the executable you
>>> could try running heat.exe on that & see if it generates the

required

>>> registration information which would save the hassle of the above
>>> process.
>>>
>>> Blair the source code for RegSpy2 is available on the above link.  
>>> That
>>> may help you modify heat.exe (or write an new tool separate from
>>> heat.exe if that's what's easier). This comes up every couple of  
>>> months
>>> so there's definitely people who have a use for it (I'd certainly be
>>> happier auto-generating WiX v3.0/v3.5 code than passing stuff  
>>> through 3
>>> different tools) & it might even discourage people from trying to  
>>> take
>>> the easy way out and do this type of thing using Custom Actions.
>>>
>>>
>>> Palbinder Sandher
>>> Software Deployment & IT Administrator
>>> T: [phone]
>>> F: [phone]
>>>
>>> http://www.iesve.com
>>> **Design, Simulate + Innovate with the <Virtual Environment>**
>>> Integrated Environmental Solutions Limited. Registered in Scotland  
>>> No.
>>> SC151456
>>> Registered Office - Helix Building, West Of Scotland Science Park,
>>> Glasgow G20 0SP
>>> Email Disclaimer
>>>
>>>
>>> -----Original Message-----
>>> From: Blair [mailto:[hidden email]]
>>> Sent: 29 October 2009 04:42
>>> To: 'General discussion for Windows Installer XML toolset.'
>>> Subject: Re: [WiX-users] Heat and .exe COM objects
>>>
>>> Short answer: manually.
>>>
>>> Long answer and call to action (if there is enough interest):
>>>
>>> Unlike the import methods that RegSvr32.exe calls in DLLs, the
>>> /regserver and /unregserver command line arguments are a convention

>>> that
>>> while common is not universal. In addition, it is dangerous to run
an

>>> unknown executable since you never know if it even checks command-
>>> lines
>>> or not (that danger of running foreign code also exists with DLLs,  
>>> but
>>> the likelihood of trouble is reduced since there isn't a lot you  
>>> can do
>>> in DllMain and it is unlikely that DllRegisterServer will be  
>>> something
>>> else).
>>>
>>> It would be possible to extend heat to call the /regserver  
>>> commandline
>>> although that would require some testing and not-so-conventional  
>>> process
>>> bootstrapping, but the largest difficulty is in how to communicate

to
>>> the tool which EXEs it should probe this way in a scalable fashion.
>>>
>>> If list members wish to propose ways to identify EXE files that  
>>> should
>>> be harvested for COM, I am open to compiling them and distilling
some

>>> proposals back to the group for further refinement. Send them to
>>> [hidden email] with a subject of "COM .exe harvesting".
>>>
>>> -----Original Message-----
>>> From: JK E-Lists [mailto:[hidden email]]
>>> Sent: Wednesday, October 28, 2009 11:07 AM
>>> To: [hidden email]
>>> Subject: [WiX-users] Heat and .exe COM objects
>>>
>>> I have an old out-of-process COM object that is wrapped in an EXE.

It

>>> uses the /regserver and /unregserver command line parameters to  
>>> register
>>> and unregister the COM object.
>>>
>>> Heat appears to treat this as an ordinary executable, ignoring the  
>>> fact
>>> that it's a COM object.
>>>
>>> Can Heat extract the COM information, or do I just need to do it
>>> manually?
>>>
>>> Thanks a lot!
>>>
>>> jk
>>>
>>> ---
>>>

---------------------------------------------------------------------
>>> ----
>>> --
>>> Come build with us! The BlackBerry(R) Developer Conference in SF,  
>>> CA is
>>> the only developer event you need to attend this year. Jumpstart
your
>>> developing skills, take BlackBerry mobile applications to market and
>>> stay ahead of the curve. Join us from November 9 - 12, 2009.
Register

>>> now!
>>> http://p.sf.net/sfu/devconference
>>> _______________________________________________
>>> WiX-users mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>>
>>>
>>> ---
>>>

---------------------------------------------------------------------
>>> ------
>>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>>> is the only developer event you need to attend this year. Jumpstart

>>> your
>>> developing skills, take BlackBerry mobile applications to market and
>>> stay
>>> ahead of the curve. Join us from November 9 - 12, 2009. Register
now!

>>> http://p.sf.net/sfu/devconference
>>> _______________________________________________
>>> WiX-users mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>>
>>>
>>>
>>> ---
>>> ---
>>> ---
>>>

---------------------------------------------------------------------
>>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>>> is the only developer event you need to attend this year. Jumpstart

>>> your
>>> developing skills, take BlackBerry mobile applications to market  
>>> and stay
>>> ahead of the curve. Join us from November 9 - 12, 2009. Register
now!

>>> http://p.sf.net/sfu/devconference
>>> _______________________________________________
>>> WiX-users mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>>
>>>
>>>      
>> ===
>> ====================================================================
>> This email, including any attachments, is only for the intended
>> addressee.  It is subject to copyright, is confidential and may be
>> the subject of legal or other privilege, none of which is waived or
>> lost by reason of this transmission.
>> If the receiver is not the intended addressee, please accept our
>> apologies, notify us by return, delete all copies and perform no
>> other act on the email.
>> Unfortunately, we cannot warrant that the email has not been
>> altered or corrupted during transmission.
>> ===
>> ====================================================================
>>
>>
>> ---
>> ---
>> ---
>> ---------------------------------------------------------------------
>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart  
>> your
>> developing skills, take BlackBerry mobile applications to market and

>> stay
>> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>> http://p.sf.net/sfu/devconference
>> _______________________________________________
>> WiX-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>    
>
>

------------------------------------------------------------------------
------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart
your
> developing skills, take BlackBerry mobile applications to market and
stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> WiX-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>  


=======================================================================
This email, including any attachments, is only for the intended
addressee.  It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
 altered or corrupted during transmission.
=======================================================================


------------------------------------------------------------------------
------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and
stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users

[Neil Sleightholm]

What you are looking for is the <Class>, <ProgId> and <Interface>
elements.

Neil

-----Original Message-----
From: IFM Lists [mailto:[hidden email]]
Sent: 02 November 2009 16:05
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Heat and .exe COM objects

*sigh* Sorry for this... being a WiX dummy, I'm having difficulty  
finding this in the docs. Could I ask for a pointer to what's probably  
right in front of my face?

(For me, the COM exe is static; the interface won't be changing.  
Nevertheless the idea of a minimal XML is appealing.)


On 2009/10/30, at 10:01, Rob Mensching wrote:

> In addition to what Neil says, there are elements in the WiX toolset  
> that
> abstract the grand majority of the COM registration that can  
> sometimes take
> 30 registry keys and make them one line of XML. The end result is  
> far more
> readable and thus maintainable, IMHO.




------------------------------------------------------------------------
------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and
stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users

[Rob Mensching-7]

I'd like to add that SelfReg was a 1980s and early 1990s concept. By the end
of the 1990s it was recognized as being a prime contributor to the "DLL
Hell" problem that as killing redistributables (anyone remember how messed
up the VB runtime could get?).

Anyway, the Windows Installer documentation provides a number of reasons why
you should not use SelfReg here:
http://msdn.microsoft.com/en-us/library/aa371608%28VS.85%29.aspx. It is rare
for MSDN documentation to come out and say "don't use this".

We learned that SelfReg was a "bad thing" (most of us call it "evil"
<smile/>) a long time ago. You are welcome to ignore the advice (it is free
after all) but I would still (and always) encourage you to not use SelfReg.
<smile/>

On Mon, Nov 2, 2009 at 10:18 AM, Neil Sleightholm <[hidden email]>wrote:

> I know it sounds a pain but it is really worthwhile adopting. What
> regserver does is not standard it is developer dependant and you can do
> anything in that code.
>
> You say it would need rework when the interface changes, that is correct
> but that shouldn't happen that often and should be well defined. If you
> are coding in C++ then you will have to write the self reg code so will
> know all the details. It sounds to me like you are using VB which is
> hiding all the complexity (and in my experience making it worse).
>
> 1. I am not sure it is "supported", it is commonly done.
> 2. I bet it doesn't just work, it works on their machines :-) Once it
> gets out in the wild I have seem all sorts of issues with self reg.
> 3. I am surprised but I guess you might only deploy to well known clean
> environments.
> 4. Personally I would argue that self reg fits that description.
>
> You final point about sharing is the killer for me, if you do it with
> reference counting it will break, doing it with WiX registry entries
> won't. Have you tried opening the InstallShield MSI with Orca to see how
> they implement the self reg, it may be that it actually implements the
> registry keys.
>
> There is no way to setup a custom action to work like this without
> implementing your own reference counting.
>
> Obviously these are my opinions and you are welcome to ignore them!
>
> Neil
>
> -----Original Message-----
> From: Daniel Hughes [mailto:[hidden email]]
> Sent: 01 November 2009 22:44
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Heat and .exe COM objects
>
> This is not a one off as it will need to be changed if the interface
> changes.
>
> When I described the process to be team they all said there is no way
> they are doing that, and that I should just use /regserver and
> /unregserver custom actions,
>
> 1. They could not understand why a supported feature should not be used.
> 2. They can not accept that something that just works in install shield
> should not be used.
> 3. They point out we have not had any problem from a install shield
> installers caused by self reg.
> 4. Quote "The mechanism that you are proposing as a replacement for COM
> self registration sounds at first hearing about it to be labour
> intensive, fiddly and brittle."
>
> The ActiveX exe in question are shared between multiple project and so
> must only be unregistered when the last one is removed. My workmates
> tell me that Install Shield keeps a count and only runs /unregserver
> when the last component is removed. They want me to replicate this
> behavior using WiX.
>
> How do I set up a custom action to unregister the ActiveX exes only when
>
> all programs using them are uninstalled?
>
>
> Neil Sleightholm wrote:
> > I would disagree, do it by hand, I would want to know what was being
> > registered. I would be fairly sure that many of these registry entries
>
> > are not required. Are these exes vb by any chance, vb has a habit of
> > adding extra registration - it registers the vb runtime everytime.
> > Also, this is a one off and not really something that needs automating
>
> > as part of a build process.
> >
> > Neil
> >
> > Neil Sleightholm
> > [hidden email]
> >
> > On 29 Oct 2009, at 23:20, "Daniel Hughes" <[hidden email]>
> > wrote:
> >
> >
> >> By the way for anyone thinking I should generate the WiX xml by hand,
> >> the WiX output from the suggested method (RegSpy2 + Tallow + RegCop)
> >> produces 700 lines of xml. If you have several of these ActiveX exes
>
> >> to
> >> register like I do then doing this by hands would involve writing
> >> several thousand lines of XML....... no thanks.
> >>
> >> Pally Sandher wrote:
> >>
> >>> Heat can't extract the COM information from your executable but
> never
> >>> fear, all is not lost quite yet.
> >>> I've used a tool called RegSpy2 to harvest the /regserver
> information
> >>> from an out-of-process COM server executable in the past. It's
> >>> available
> >>> at http://www.installsite.org/pages/en/msi/tips.htm (scroll down to
>
> >>> the
> >>> section labelled "Capture Self-Registration Information")
> >>> It will output a .reg file which you'll need either manually convert
> >>> into WiX code or if you want to save yourself some time you can use
> >>> tallow.exe in WiX v2.0 then use WiXCop.exe on the .wxs tallow
> >>> generates
> >>> to convert it to WiX v3.0/v3.5 code. Unfortunately heat.exe doesn't
> >>> support parsing .reg files into WiX code like tallow did/does so you
> >>> will need to download WiX v2.0 if you don't feel like manually
> >>> writing
> >>> all the RegistryKey & RegistryValue entries yourself (you don't
> >>> need to
> >>> install WiX v2.0 to use tallow, just download the binaries).
> >>>
> >>> If you have the actual object which is wrapped in the executable you
> >>> could try running heat.exe on that & see if it generates the
> required
> >>> registration information which would save the hassle of the above
> >>> process.
> >>>
> >>> Blair the source code for RegSpy2 is available on the above link.
> >>> That
> >>> may help you modify heat.exe (or write an new tool separate from
> >>> heat.exe if that's what's easier). This comes up every couple of
> >>> months
> >>> so there's definitely people who have a use for it (I'd certainly be
> >>> happier auto-generating WiX v3.0/v3.5 code than passing stuff
> >>> through 3
> >>> different tools) & it might even discourage people from trying to
> >>> take
> >>> the easy way out and do this type of thing using Custom Actions.
> >>>
> >>>
> >>> Palbinder Sandher
> >>> Software Deployment & IT Administrator
> >>> T: [phone]
> >>> F: [phone]
> >>>
> >>> http://www.iesve.com
> >>> **Design, Simulate + Innovate with the <Virtual Environment>**
> >>> Integrated Environmental Solutions Limited. Registered in Scotland
> >>> No.
> >>> SC151456
> >>> Registered Office - Helix Building, West Of Scotland Science Park,
> >>> Glasgow G20 0SP
> >>> Email Disclaimer
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: Blair [mailto:[hidden email]]
> >>> Sent: 29 October 2009 04:42
> >>> To: 'General discussion for Windows Installer XML toolset.'
> >>> Subject: Re: [WiX-users] Heat and .exe COM objects
> >>>
> >>> Short answer: manually.
> >>>
> >>> Long answer and call to action (if there is enough interest):
> >>>
> >>> Unlike the import methods that RegSvr32.exe calls in DLLs, the
> >>> /regserver and /unregserver command line arguments are a convention
>
> >>> that
> >>> while common is not universal. In addition, it is dangerous to run
> an
> >>> unknown executable since you never know if it even checks command-
> >>> lines
> >>> or not (that danger of running foreign code also exists with DLLs,
> >>> but
> >>> the likelihood of trouble is reduced since there isn't a lot you
> >>> can do
> >>> in DllMain and it is unlikely that DllRegisterServer will be
> >>> something
> >>> else).
> >>>
> >>> It would be possible to extend heat to call the /regserver
> >>> commandline
> >>> although that would require some testing and not-so-conventional
> >>> process
> >>> bootstrapping, but the largest difficulty is in how to communicate
> to
> >>> the tool which EXEs it should probe this way in a scalable fashion.
> >>>
> >>> If list members wish to propose ways to identify EXE files that
> >>> should
> >>> be harvested for COM, I am open to compiling them and distilling
> some
> >>> proposals back to the group for further refinement. Send them to
> >>> [hidden email] with a subject of "COM .exe harvesting".
> >>>
> >>> -----Original Message-----
> >>> From: JK E-Lists [mailto:[hidden email]]
> >>> Sent: Wednesday, October 28, 2009 11:07 AM
> >>> To: [hidden email]
> >>> Subject: [WiX-users] Heat and .exe COM objects
> >>>
> >>> I have an old out-of-process COM object that is wrapped in an EXE.
> It
> >>> uses the /regserver and /unregserver command line parameters to
> >>> register
> >>> and unregister the COM object.
> >>>
> >>> Heat appears to treat this as an ordinary executable, ignoring the
> >>> fact
> >>> that it's a COM object.
> >>>
> >>> Can Heat extract the COM information, or do I just need to do it
> >>> manually?
> >>>
> >>> Thanks a lot!
> >>>
> >>> jk
> >>>
> >>> ---
> >>>
> ---------------------------------------------------------------------
> >>> ----
> >>> --
> >>> Come build with us! The BlackBerry(R) Developer Conference in SF,
> >>> CA is
> >>> the only developer event you need to attend this year. Jumpstart
> your
> >>> developing skills, take BlackBerry mobile applications to market and
> >>> stay ahead of the curve. Join us from November 9 - 12, 2009.
> Register
> >>> now!
> >>> http://p.sf.net/sfu/devconference
> >>> _______________________________________________
> >>> WiX-users mailing list
> >>> [hidden email]
> >>> https://lists.sourceforge.net/lists/listinfo/wix-users
> >>>
> >>>
> >>> ---
> >>>
> ---------------------------------------------------------------------
> >>> ------
> >>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> >>> is the only developer event you need to attend this year. Jumpstart
>
> >>> your
> >>> developing skills, take BlackBerry mobile applications to market and
> >>> stay
> >>> ahead of the curve. Join us from November 9 - 12, 2009. Register
> now!
> >>> http://p.sf.net/sfu/devconference
> >>> _______________________________________________
> >>> WiX-users mailing list
> >>> [hidden email]
> >>> https://lists.sourceforge.net/lists/listinfo/wix-users
> >>>
> >>>
> >>>
> >>> ---
> >>> ---
> >>> ---
> >>>
> ---------------------------------------------------------------------
> >>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> >>> is the only developer event you need to attend this year. Jumpstart
>
> >>> your
> >>> developing skills, take BlackBerry mobile applications to market
> >>> and stay
> >>> ahead of the curve. Join us from November 9 - 12, 2009. Register
> now!
> >>> http://p.sf.net/sfu/devconference
> >>> _______________________________________________
> >>> WiX-users mailing list
> >>> [hidden email]
> >>> https://lists.sourceforge.net/lists/listinfo/wix-users
> >>>
> >>>
> >>>
> >> ===
> >> ====================================================================
> >> This email, including any attachments, is only for the intended
> >> addressee.  It is subject to copyright, is confidential and may be
> >> the subject of legal or other privilege, none of which is waived or
> >> lost by reason of this transmission.
> >> If the receiver is not the intended addressee, please accept our
> >> apologies, notify us by return, delete all copies and perform no
> >> other act on the email.
> >> Unfortunately, we cannot warrant that the email has not been
> >> altered or corrupted during transmission.
> >> ===
> >> ====================================================================
> >>
> >>
> >> ---
> >> ---
> >> ---
> >> ---------------------------------------------------------------------
> >> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> >> is the only developer event you need to attend this year. Jumpstart
> >> your
> >> developing skills, take BlackBerry mobile applications to market and
>
> >> stay
> >> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> >> http://p.sf.net/sfu/devconference
> >> _______________________________________________
> >> WiX-users mailing list
> >> [hidden email]
> >> https://lists.sourceforge.net/lists/listinfo/wix-users
> >>
> >
> >
> ------------------------------------------------------------------------
> ------
> > Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> > is the only developer event you need to attend this year. Jumpstart
> your
> > developing skills, take BlackBerry mobile applications to market and
> stay
> > ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> > http://p.sf.net/sfu/devconference
> > _______________________________________________
> > WiX-users mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
>
>
> =======================================================================
> This email, including any attachments, is only for the intended
> addressee.  It is subject to copyright, is confidential and may be
> the subject of legal or other privilege, none of which is waived or
> lost by reason of this transmission.
> If the receiver is not the intended addressee, please accept our
> apologies, notify us by return, delete all copies and perform no
> other act on the email.
> Unfortunately, we cannot warrant that the email has not been
>  altered or corrupted during transmission.
> =======================================================================
>
>
> ------------------------------------------------------------------------
> ------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and
> stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> WiX-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> WiX-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>

--
virtually, Rob Mensching - http://RobMensching.com LLC
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users