Video Screencast Help

Merge Module issue for Wise Installation Studio v7 SP2

Created: 05 Dec 2013 | 6 comments

I recently had to reformat my machine and I lost all the merge modules.  I Installed Wise Installation Studio SP2 (help about shows version 7.4.0.214).  I then found http://www.symantec.com/business/support/index?page=content&id=TECH38334 and downloaded/ran the WPSModules.exe that the articule references.  No issues during any of this.

When I compile a new project from scratch for testing, no issues (all this does is install a DLL in a folder).

When I compile a project that existed and worked fine prior to my reformatting, I get a message towards the end that says, "The runtime files required for this installation must be downloaded from the Internet for this installation to be compiled.  Do you want to download the runtime installation files?"  I click Yes, pick either Wise Web Site or Other Vendors' Web Sites, (doesn't matter which) and then I get the error, "An error occured while downloading information files necessary to continue the process".  I assume because this is a legacy product that's mentioned in the above articule, this feature will never work again.

There are no merge modules listed under Feature Details>Merge Modules.

How can I tell which merge module it's missing?

Thanks,

Bond

Operating Systems:

Comments 6 CommentsJump to latest comment

EdT's picture

Just to clarify, can I assume that you are referring to the MSI editor and not the Wisescript editor? (The Wisescript Editor was also able to download some standard runtimes).

Assuming it is indeed merge modules that you are referring to, have you considered checking the ModuleSignature table in the WSI or any existing MSI ?

Here is an extract from the help file MSI.CHM which is installed by Wise products:

ModuleSignature Table

The ModuleSignature Table is a required table. It contains all the information necessary to identify a merge module. The merge tool adds this table to the .msi file if one does not already exist. The ModuleSignature table in a merge module has only one row containing the ModuleID, Language, and Version. However, the ModuleSignature table in an .msi file has a row containing this information for each .msm file that has been merged into it.

Merge and verification tools check the ModuleSignature table in .msi files to determine if it has all of the dependent merge modules required by the current merge module (see ModuleDependency Table) and whether the installation package was previously merged with any conflicting merge modules (see ModuleExclusion Table).

The ModuleSignature table has the following columns.

Column Type Key Nullable
ModuleID Identifier Y N
Language Integer Y N
Version Version   N

 

Columns

 

ModuleID

An identifier that uniquely identifies the merge module. Two merge modules cannot have the same ModuleID unless the merge module is entirely backward compatible with its predecessor. You can create a GUID for this field using a utility such as GUIDGEN. The ModuleID column is a primary key for the table and therefore it must follow the naming convention in Naming Primary Keys in Merge Module Databases. For example, if the readable name of the merge module is MyLibrary and the GUID is {880DE2F0-CDD8-11D1-A849-006097ABDE17}, the entry in the ModuleID column becomes MyLibrary.880DE2F0_CDD8_11D1_A849_006097ABDE17.

Language

The Language identifier specifies the default language for the merge module. The language identifier is in decimal format, for example, U.S. English is 1033. The language used by the merge module can be changed by applying a transform to the merge module before merging.

Version

The Version field contains a string that describes the major and minor versions of the merge module.

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

EdT's picture

Since this only happens for existing projects rather than new ones, chances are that the references to the merge module location are not correct. It would be worth checking through the tables starting Wise..xxx in the WSI as these contain various references to external resources. Eg the WiseSourcePath table refers to the location of the sources for each regular file listed in the file table.

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

mbond's picture

It is the MSI editor (WfWI.exe), and I'm using a WSI file.

 

There are no rows in every table that has "Module" in its name.

 

I noticed that in WiseStreamFiles, there are these paths:

[WisePath]\stub\wisepatch.dll

[WisePath]stub\WiseApi.dll

 

What is [WisePath] and how is it set?  I don't see it under Project Definition>Path Variables.  I also can't find either WiseApi.dll nor Wisepatch.dll on my machine under Program Files (x86).  Where should they be?

 

Also, it appears to ask to download modules during the "remove unused streams" stage of the compiling.  The error after cancelling the module download is "An error has occured creating the single-file .exe C:\<path>\<filename>.msi."

EdT's picture

[WisePath] is the location where the Wise software is installed. In my case, the stub folder is here:

C:\Program Files (x86)\Symantec\Wise\Windows Installer Editor\Stub

and the folder contains the two DLL files you mention, amongst others.

What I note from your most recent posting is that the error references a single file EXE.....

This leads me to ask the question - are you compiling your project to a single file EXE ??

If you are, then you need to look at the single file EXE compilation options, and especially whether there are any pre-requisites or dependencies specified as part of the EXE compilation. The process of compiling an MSI project to a single file EXE actually leverages the Wisescript compiler using a Wisescript "stub".  I suspect that some dependency required by the EXE is missing, and this could include something like a windows installer runtime at the minimum version required by your MSI in case your target system has a lower version installed, or it could include a vbscript runtime or a borland runtime, especially for really old software.

You could, of course, run filemon or procmon from sysinternals.com to monitor file activity during compilation and check what files are being requested, and where a "file not found" error gets recorded by procmon.

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

mbond's picture

I found the files in that location.  Apparently Windows Search can't find files in an indexed location ;)

 

Yes, I am compiling it to a single EXE.  I turned off that setting just to test and no errors happened.  The only prerequisite was Windows Installer 3.1.  I found the redistributable for this on Microsoft's site (http://www.microsoft.com/en-us/download/details.aspx?id=25), but it wouldn't install on my machine.  I changed that setting (Release Definition>Prerequeisites>Windows Installer Runtime Version (2000/XP/2003) to "None", and now it works without errors.

 

So, what impact will turning this off have?  I'm sure Windows Update would have updated all of our customer's machines by now to at least that version.  But what if a customer actually doesn't have version 3.1 installed?

 

Thank you for your time and assistance.

EdT's picture

Does your MSI project actually specify windows installer 3.1 as the minimum version required?

If I recall correctly, if you have XP at SP3 then you have Windows Installer 3.1, so your action from here really depends on what target operating systems you will be deploying to.  

If they are likely to have an earlier version of Windows Installer present, then you can add a launch condition to your MSI project which tests the file version of c:\windows\system32\msi.dll or c:\windows\system32\msiexec.exe, and terminates the install if the minimum version is not found.

However, the process to add the windows installer runtime to your project does not require you to install it, you just need to make sure that the installation executable is placed in the appropriate location for the Wisescript compiler to find it.  If I recall correctly, the documentation does cover this.

Finally, if you add a "dummy" pre-requisite to your EXE definition, the button that allows editing of the stub Wisescript gets enabled, and you can then edit the Wisescript to your heart's content - just remember to delete the lines added for your "dummy" pre-requisite.

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