InstallShield installation - Error 2705

[jacko]

It would be interesting to know.  I am going to have to start building some Installshield installations for Lab View applications pretty soon, I hope this has been resolved. 

[SachaE]

Hi,

  I realise that this has been going on for quite some time now, however the matter is still being investigated at an R&D level at this time.

Thank you for your continued patience

Sacha Emery
National Instruments (UK)

[gbedford]

darn, i just spent $750 to upgrade to installshield 12 only to find that the same error occurs there.

[gbedford]

i wouldnt mind so much if the upgrade had fixed the problem but we have gone 8 months without being able to properly deploy a product because of this problem.  My colleagues are amazed that there isnt any solution after this length of time.  I can even create a blank project in IS 12, add the merge modules and run it, and i will get the errors.   Is there any other way to reliably distribute the runtimes with all required registry entries etc without having to show an interface?

[DrewH]

Has this issue been resolved yet?  It's now Nov 30 2007, and I am still getting this issue with Measurement Studio 7 and Installshield 2008.  Did the Measurement Studio 8 redistributables fix this problem?
Thanks.

[Ebele_Obijiofor]

Hello,

Reading through the thread, it looks like people were seeing slightly different issues. Could you please give me some more specific information on the issues you are seeing. Thanks!

Regards,

[DrewH]

I have the exact same problem as in the original post, by Chris Wilson
I am using the following setup:

Product: NI Measurement Studio 7.1
Installer: Installshield Professional 2008

When I try to include merge modules for Measurement Studio Winforms classes into my installation I see error 2705-Directory. For some setup configurations this was shortly followed by errors 2731.0 and/or 2732.0.  I have confirmed that the ProgramFilesFolder directory entry is present as per the advice in the Knowledgebase.

After some experimentation I have managed to discover the following:

1) The problem occurs for InstallScript MSI projects, but not for Basic MSI projects. However we need installscript functionality in order to install our application.

2) The problem can be reproduced using a very basic InstallScript MSI project. After creating the project, "NIMesaDLL" was selected from the redistributables panel window. This in turn caused it's "NI Installer Utilities" and  the "Microsoft C Runtime Library 6.0" to be selected. The release wizard was used to create an uncompressed setup, with both the MSI engine and the installscript engine extracted from setup.exe. The resulting setup program failed with error 2705

3) If the above setup is changed to be compressed, error 2732 can also be seen.

[JonathanN]

Hi Drew,

We test our merge modules in several different installer environments including Visual Studio, Wise, Wix and our own internal distribution framework and they all work correctly. We know that our merge modules only work in the basic MSI mode and not the InstallScript mode.  So you could only use our merge modules in the basic mode.

The problem is that the failure occurs in InstallShields application and we can't debug into that application to see what's going on. Its not our source code.  You would need to contact InstallShield and get them to debug into their own application and see what's failing. Then if they can show us that our merge modules have a bug in it, we would gladly be able to fix it. 

Best Regards,

[michaelmalak]

"The problem is that the failure occurs in InstallShields application and we can't debug into that application to see what's going on. Its not our source code.  You would need to contact InstallShield and get them to debug into their own application and see what's failing. Then if they can show us that our merge modules have a bug in it, we would gladly be able to fix it."

I'm sorry, but that is not an acceptable response.

That's like Adobe telling its customers to contact Microsoft regarding Photoshop not working with Windows.

First, it's National Instruments' responsibility to get its merge modules to work with the most popular and powerful reference standard of installers on the market, InstallShield.

Second, "InstallShield is a black box" is not a valid software development excuse.  Software developers have to deal with black boxes as a fact of life.  Windows is a black box.  InstallShield is a black box.  LabVIEW is a black box.  When an issue is encountered with a black box, the approach to take is to narrow down the problem.  An empty merge module doesn't cause the problem.  But the NI merge modules do.  By gradually morphing the empty merge module into the full NI merge module, NI can determine what is triggering the problem and code around it.

This is not some arcane configuration we're encountering.  It's InstallShield!  And it's been going on for three years.

[JonathanN]

Hi michaelmalak,

As I mentioned in the earlier post, our merge modules work in a variety of different installer environments.  Our merge modules work in InstallShield when you are using the MSI mode and not the InstallScript mode. The problem is that InstallShield doesn't seem to handle custom actions very well and our merge modules use custom actions to determine certain NI paths. Three years ago when this issue first arose, we did create debug logs of the installer and found that the errors were coming from some InstallShield functions. We then contacted InstallShield and reported the problem but nothing came out of that conversation.  Therefore we decided that we would only support the basic MSI mode with InstallShield.

Now, we can once again report this problem to InstallShield. To help us out, please post a copy of some InstallShield built-installer which we will then create a log of the installer and send that off to InstallShield. 

So we did work around the initial problem by deciding to only support MSI mode with InstallSheild.

Best Regards,