trouble with InstallShield X and .msm files

[JJB]

I cannot use the distributed .msm files in InstallShield X - they give warnings(errors really) when included in an InstallShiel project.

In addition, I cannot open the .msm files - I get "Error retrieving ModuleID for Table" messages.

NIMesaDLL.msm CRASHES InstallShield X when opening it.

I need this to work ASAP and InstallShield doesn't seem to be able to figure out what the problem is.

Anyone here know ?

[jlaney]

Hello,

First, what version of CVI are you using? This makes a difference because the merge modules have changed a little each release to solve issues with other Installer building solutions.

Also, can you send me what merge modules you are using and errors for each.

Regards,
Jeff
NI

[JJB]

Using CVI 6.0.0 (105)

nipaths.msm - InstallShield X simply says "Cannot open nipaths.msm. Please contact InstallShield Technical Support for more information." So I did - their "more information" was "it's not our problem, contact the manufacturer". Grrrr.

NIMesaDLL.msm - opens in InstallShield X, but clicking on the General Information tab yields the informative "Error retrieving ModuleID for table" message. Eventually, if you click around their Installation Designer, InstallShield X crashes. Again, InstallShield Technical Support says "it's not our problem, contact the manufacturer". Grrrr. Grrrr.

cvirte.msm - opens in InstallShield X, but clicking on the General Information tab yields the informative "Error retrieving ModuleID for table" message (agai
n). I've never seen this one crash InstallShield X but, InstallShield Technical Support says "it's not our problem, contact the manufacturer". Grrrr. Grrrr. Grrrr.

Please help me stop saying "Grrrr".

[jlaney]

Hello,

I find that the best way to stop saying Grrr is to stop using products that have roman numerals in the name. This usually means that they are more controlled by Marketing than R&D.

I know what your problem is for nipaths and cvirte. Installshield is very stringent about it's merging of MSMs. It is having problems with a table that is no longer in the MSI specification, but it is also empty in the MSM. Installshield should just ignore the table as some other Distribution mechanisms do, such as CVI's create distribution. I am attaching MSMs that remove this "bad" table.

The NIMesaDLL.msm does not have the bad table entry, but it depends on the NIPaths.msm so I think this is where the issue is coming from. If the new MSMs
do not fix everything please let me know so I can look into this further.

Jeff
NI

[JJB]

Runtime Merge module 6.0 - works great, thanks
nipaths merge module - NiMesaDLL.msm still has the problem, so, if you have NiMesaDLL.msm that doesn't have the problem, please pass it along.

Thank you.

[jlaney]

I wish I could see what was going on with this because we have not had any issues with this merge module before.

What I can do is provide you with the latest shipping merge module. It has a different dependency other than NIPaths.msm though. Therefore, I will also provide you with the new NIMetaUtils.msm. Are you also adding MSVCRT.msm to the distribution? The mesa library depends on that merge module as well. Even though these are updated merge modules, I have been told that the DLL inside has not changed since CVI version 6.0, so you should be safe using this MSM.

Hope this helps,
Jeff
NI

[rosscsoft]

I am trying to create an installation for my client's LabWindows/CVI 7.0 application using a Visual Studio Setup and Deployment project.  The CVI Create Distribution Kit is causing issues in my automated environment so I have been trying to use Visual Studio instead.

I am having difficulty importing the cvirte.msm merge module (version 7.0) and get the following error while building:

"Error    1    Unable to import merge module 'D:\Program Files\National Instruments\CVI70\redist\msm\cvirte.msm'

I saw this old thread and wondered if it might be the same issue, that some tables are causing problems.  Did a 'cleaned up' version of cvirte.msm 7.0 get released?

If not, does any information exist on which tables were causing the problems?  Perhaps I can edit in Orca and get something working?

Thanks