views:

2298

answers:

2

I am using InstallShield 2009 to generate an MSI for a codebase I have inherited. The code is comprised of VB6, and .NET 2.0 code (C# and C++). I'm developing and installing on Windows XP SP2.

I created the Install Shield project (call it "MyClient.ISM") by reverse engineering it from the MSI provided by the previous team. Their configurations are the now the same.

I then configured InstallShield to produce the MSI. This built, without error.

However, when I try to run my MSI it fails with two "Error 1001 InstallUtilLib.dll: Unknown Error" dialogs and then successfully backs out the changes it has made.

I then ran MyClient.MSI with the msiexec command. E.g.

msiexec /lvx C:\inst_server.log /i "C:\MyClient.MSI"

It seemed that the problem was due to a 2769 error. The error locations from the log files resulting from this are below.:

DEBUG: Error 2769: Custom Action _A11801EAD1E34CFF981127F7B95C3BE5.install did not close 1 MSIHANDLEs.

This Custom Action was trying to install .NET services. So I then went to InstallShield and removed all custom actions (install, uninstall, commit and rollback as well as the associated SetProperty's) and built and installed again. This worked, but the services were no longer installed. I now need to install these .NET Services using an InstallShield method which works.

Any help in this would be greatly appreciated.

Kind Regards, Andrew

A: 

I see this is an older question, but thought I'd give it a go in case anyone needed help with it.

From what I've observed, all Error 1001's are related to the .NET Framework.

First, I'd make sure you are building a setup.exe bootstrapper with your msi. Use the InstallShield Release wizard to do this, and be sure to include the version of the .NET Framework that your application needs in the bootstrapper. It could be that your test machine doesn't have the required version of the .NET Framework installed.

The custom action you mentioned was autogenerated by InstallShield during the build. It created wrapper custom actions to call the methods in the installer classes in your components. In your case, this was the .install method of one of your components' installer class.

If you've ensured that you're deploying the .NET Framework correctly, and you still have an issue, consider debugging the installer classes in the assembly. (Check here for more info: http://www.hanselman.com/blog/BackToBasicsUsingFusionLogViewerToDebugObscureLoaderErrors.aspx)

Hope this helps someone.

WeekendDiver
A: 

I had the error 1001 too, in an InstallShield 2009 basic MSI project. Try adding the automatically generated _isconfig.xml to the Support Files\Language Independent node. This will ensure the correct CLR fire up when a .NET related action such as InstallerClass invokes.

In my case _isconfig.xml contents had reference to .NET 2.0 runtime, but it could refer to 1.0\1.1 as well.

<?xml version="1.0"?>
<configuration>
    <startup>
     <supportedRuntime version="v2.0.50727"/>
    </startup>
</configuration>

See also: Q108690: INFO: Consuming A Merge Module Created Cith Microsoft Visual Studio .NET 2003 Or 2005

KMoraz