Hi,
I've built a Windows Installer for a .NET application. It works fine when installed from the local hard disk but fails when I try to install it from the web. I posted a similar issue a while back but the solutions then did not resolve the problem.

The msi includes a merge module that has a custom installer in it. If I cut out the custom installer, it works so the problem is clearly within that custom installer. However, I cannot see any bugs and, as I say, it works fine from the local hard disk.

I have tried putting MessageBox.show commands into the installer but I do not see the dialogs so I am not even sure that the installer is being called.

The relevant section in the log file is shown below:

MSI (s) (D4:80) [12:02:08:043]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI1A.tmp, Entrypoint: ManagedInstall
MSI (s) (D4:54) [12:02:08:043]: Generating random cookie.
MSI (s) (D4:54) [12:02:08:053]: Created Custom Action Server with PID 1520 (0x5F0).
MSI (s) (D4:70) [12:02:08:093]: Running as a service.
MSI (s) (D4:70) [12:02:08:093]: Hello, I'm your 32bit Elevated custom action server.
MSI (s) (D4!18) [12:02:08:994]: Creating MSIHANDLE (35) of type 790531 for thread 792
DEBUG: Error 2835:  The control ErrorIcon was not found on dialog ErrorDialog
The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2835. The arguments are: ErrorIcon, ErrorDialog, 
Error 1001. Error 1001. Exception occurred while initializing the installation:
System.IO.FileNotFoundException: Could not load file or assembly 'file:///C:\WINDOWS\system32\and' or one of its dependencies. The system cannot find the file specified..
MSI (s) (D4!18) [12:02:10:857]: ¥¥朁㿟¥¥¥¥栗㿟⃰㿾¥枸㿟蘸Ĕ�?#18;¥䍗㿥蘸Ĕ�?#18;䍻㿥蘸Ĕ¥Ā
MSI (s) (D4:80) [12:02:10:887]: Leaked MSIHANDLE (35) of type 790531 for thread 792
MSI (s) (D4:80) [12:02:10:887]: Closing MSIHANDLE (35) of type 790531 for thread 792
MSI (s) (D4:80) [12:02:10:887]: Note: 1: 2769 2: _A3180014_ED33_42B3_BCC7_22A5B84CB50D.install 3: 1 
DEBUG: Error 2769:  Custom Action _A3180014_ED33_42B3_BCC7_22A5B84CB50D.install did not close 1 MSIHANDLEs.
The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2769. The arguments are: _A3180014_ED33_42B3_BCC7_22A5B84CB50D.install, 1, 
MSI (s) (D4:80) [12:02:10:887]: Closing MSIHANDLE (34) of type 790536 for thread 1228
Action ended 12:02:10: InstallExecute. Return value 3.

My understanding - from reading other posts - is that the missing icon is a red herring and really the problem is to do with the custom installer.
During the rollback, I get an error message saying that it could not locate the InstallState file corresponding to the DLL containing the custom installer:

Error 1001. Error 1001. Could not find file 'C:\Program Files\[path]\[installer].InstallState'.

Does all of this suggest that it's not finding the custom installer?
I would be grateful for any help or advice.
Many thanks,
-Paul

Hi pauldb,

Please read the article below which is about a same error and provides a solution:
http://support.microsoft.com/kb/555650

Regards,
Aland Li

---

Please mark the replies as answers if they help and unmark if they don't. This can be beneficial to other community members reading the thread.

FOUND IT !!!

In the properties for the custom action, in the CustomActionData field, I was including /src="[SourceDir]\"

SourceDir points at the root directory of the installation files.

I can understand why this is not available when the installer is run over the web but I cannot see why it should give the error message that it did.

I recognise that I didn't give enough information about my setup for anyone on these forums to be able to identify the cause of this problem. Please forgive me. I hope you see that it was pretty obscure and, as I say, the error message was misleading and not at all helpful.

However, reading back over the article that Aland Li mentioned:
http://support.microsoft.com/default.aspx/kb/555650
the information is contained within there. I just got sidetracked into thinking about GPOs - my fault entirely.

Anyway, many thanks to those who did take an interest and try to resolve the issue. And thanks again to Aland Li for putting the answer under my nose.
It's much appreciated.
-Paul

Hi pauldb,

Please read the article below which is about a same error and provides a solution:
http://support.microsoft.com/kb/555650

Regards,
Aland Li

---

Please mark the replies as answers if they help and unmark if they don't. This can be beneficial to other community members reading the thread.

Thanks Aland Li, that does sound like it's the problem. However, I'm not sure I understand what to do in terms of the solution.

I'm not knowingly using GPO, however, I am using a custom installer that makes use of local paths on the installation machine - AFAIK, I have no choice - I need to install files and then execute them as part of the install.

I will try to find out more information but many thanks for providing this starting point.
-Paul

A follow up question then after reading the article:

If installing a MSI from the web, is it absolutely necessary that the MSI be hosted on a Windows Server (and with the appropriate GPO settings)?

Many thanks,
-Paul

I'm not sure why GPO is anything to do with this. You have a custom action that's failing, apparentlly before it gets to yopur code. You haven't said whether it's an Install custom action or a Commit custom action, but if it's really a missing Installstate file it could be because you haven't called the base method of Install (which creates it). Or the custom action code may have a dependency that isn't installed.

---

Phil Wilson

Hi Phil,
But why, then, does the MSI (including the custom installer) work perfectly when copied to the local machine and installed from there as opposed to using the bootstrapper over the web?
Thanks,
-Paul

Not sure exactly which bootstrapper you've got, so I don't know exactly what's going on. But....
Simple answer: It's not the same environment.
Is your bootstrapper downloading the MSI file to a folder and launching it from that folder?
Are all the files packaged in the MSI file or are they loose (or in a cab file)?
Is there already an Installstate file stuck on the system that the disk install finds but the downloaed one can't find?

If you have tried a messagebox as the first line of code in your install:
Is it really the first? Is it before base.Install()? Do you call base.Install()?

There's not enough information to know what's going on, but my main point is that I don't think Group Policy deployment is anything to do with what you're seeing. Code is always working in one environment and not in another, and there's rational explanation somewhere that doesn't involve Group Policy objects.

---

Phil Wilson

Hi Phil,
Thank you for your reply and for your interest.

I am happy to accept that GPO settings have nothing to do with this problem - the referenced article led me down that path. However, I do agree with you that the different environment is somehow having an effect on the success or failure of this installation. The article referenced by Aland Li is the nearest I have come to an explanation beyond the simple it being a different black box.

Anyhow, I thought I had answered some of your questions in the post that began this thread, however, to recap and answer the more specific ones....

which bootstrapper

I have tried bootstrappers generated by both VS2008 and the Bootstrapper Manifest Generator.

Is your bootstrapper downloading the MSI file to a folder and launching it from that folder? 

It specifies a URL for the folder containing the MSI - which is then downloaded to a temporary location and run from there.

Are all the files packaged in the MSI file or are they loose (or in a cab file)?

All in a single MSI.

Is there already an Installstate file stuck on the system that the disk install finds but the downloaed one can't find?

No, I ensure that every installation I try is clean. I have installed on several machines and VMs - all with the same result. I have also tried different web servers, both Linux and Windows. Note: the message about missing InstallState only occurs during the 'rollback' of the installation triggered by something else.

If you have tried a messagebox as the first line of code in your install:
Is it really the first? Is it before base.Install()? Do you call base.Install()? 

Yes..I have put MessageBox.Show's on the first line in the Install and Commit methods - neither show. And yes, I call base.Install, base.Commit, base.Rollback..., as appropriate, in all of the overridden methods.

To try and give a bit more information....the installer does fail at the point where I would expect the commit method to be executed (commit is where I do my customised stuff). The custom install actions are actually within a merge module not in the top level installer. It all works fine, as I say, when the setup.msi is run from a local (non temp) folder.

There is a dependency on .NET 3.5 SP1 and the Microsoft Chart Controls - but these are already installed on the machines I've tried. When I create a bootstrapper for non-web installs, I have included the dependency on these and they have been installed as/when necessary.

To me, it all seems fine except when installed from the web, it does not appear to be finding the merge module and the custom installer.

Thanks,
-Paul

When you say "maybe it doesn't find the merge module" I'm a bit confused. When you add a merge module to a setup project it becomes embedded in the MSI file and is no longer separate. It's got to be in there! Hopefully you right-clicked on the setup project and did Add->Merge module.

---

Phil Wilson

Please accept my apologoes for not using the correct phrase....I'm not sure how else to express it. However, to reiterate, the custom installer runs successfully when the MSI is run from the local hard disk but does not appear to run (no MessageBox dialog appears) or, at least, it fails (installation rolls back) when the MSI is launched (downloaded to a temp location and ran from there) via a bootstrapper over the web.

Once again, I repeat, the MSI behaves perfectly well when ran from the local hard disk or CD BUT as soon as I change the bootstrapper (either in VS2008 or using the BMG) to point to a web location for the setup files, it begins to run and then fails with the error messages quoted at the start of this thread.

I do not change the MSI, only the bootstrapper.
-Paul

FOUND IT !!!

In the properties for the custom action, in the CustomActionData field, I was including /src="[SourceDir]\"

SourceDir points at the root directory of the installation files.

I can understand why this is not available when the installer is run over the web but I cannot see why it should give the error message that it did.

I recognise that I didn't give enough information about my setup for anyone on these forums to be able to identify the cause of this problem. Please forgive me. I hope you see that it was pretty obscure and, as I say, the error message was misleading and not at all helpful.

However, reading back over the article that Aland Li mentioned:
http://support.microsoft.com/default.aspx/kb/555650
the information is contained within there. I just got sidetracked into thinking about GPOs - my fault entirely.

Anyway, many thanks to those who did take an interest and try to resolve the issue. And thanks again to Aland Li for putting the answer under my nose.
It's much appreciated.
-Paul