Video Screencast Help
Search Video Help Close Back
to help
New in the Rewards Catalog: Vouchers for "Symantec Technical Specialist" and "Symantec Certified Specialist" exams.

Best Practices for Patch Builds

Updated: 21 May 2010 | 1 comment
trailway's picture
0 0 Votes
Login to vote

I want to do patch builds (msp) using Wise Installation Studio.

The product that I work on has numerous VB6 COM components, each of which has a binary compatible COM DLL.  The  compatible DLLs are used such that we do not break the COM interface contract when we add methods to the exposed  classes.

In order to understand this I did the following:

1) Created a new Wise project
2) Added a VB6 exe and a VB6 COM DLL to the project
3) Compiled the Wise project producing an MSI file
4) Tested the MSI (it works)
5) Modified the settings for the VB6 COM DLL in order to "Rescan advertising information during compile".
6) Added a new member function to the VB6 COM DLL and rebuilt it
7) Recompiled the Wise project producing a new MSI

Observation - All the names of the registry keys associated with the VB6 COM DLL changed.

I then ran UpgradeSync from the current Wise project against the first MSI I produced.  UpgradeSync complained  about all the registry keys changing.

Question: What is the correct process/procedure to use in order to do this correctly?

I did read the MSDN discussion on "Creating a New Component" which seems to indicate that I should create a new component when registry keys change.  FWIW, I will never have more than 1 instance of any component installed on a given machine because I have no plans to support side-by-side installs.

Thanks,

Richard Watson
 

Comments

EdT's picture
02
Nov
2009
0 Votes 0
Login to vote

WiseComCapture

There is a utility called WiseComCapture which can extract the registration information from a COM DLL.
Ideally, the registry information that is unchanged should be maintained in the same component, and the new registration information added via another component, for patching purposes.
It sounds like your particular application will need some sort of hand crafted solution if you are regularly going to update the COM DLL, so that existing registration information is preserved unchanged and new information added separately.
Nothing simple or elegant springs to mind, but perhaps another forum member will be able to suggest a better way.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.