Update: I've found a temporary solution. After inspecting which files was in our package I found a 3rd party component that we don't use anymore but still had a reference to. This was references by our business layer, which all our web services use, hence this dll was in every bin folder on every web service. Since the size of the file was quite big it was enough to get the installation down to a reasonable size and avoiding the described error message.

For a while now our msi file that contains the application server for our product has not been working. Not an msi that our customers have, but one we're about to ship in two weeks. I've had my hands full for a long time, but today I finally got around to check what was causing the problem. Here's a screen shot of the error I get:

After a quick Google search I found that this is related to a bug on Windows Server 2003 and Windows XP. Cause:

This problem occurs if the Windows Installer process has insufficient contiguous virtual memory to verify that the .msi package or the .msp package is correctly signed. 

Fantastic! I will not go and ask all our customers to install the hotfix on their servers. That's just to stupid. About now you're probably thinking something like "How big is their app-server really?" or "What product can get to big for an msi file?". I can tell you... The size of the msi is 576MB. No images, no database, just pure .Net dll's! And actually we're not alone. Visual Studio Service Pack 1 had the exact same problem! Go figure. And even better, there is no hotfix for this on Windows XP.

Have we been coding like mad men for a decade and producing tons of code? I wish (or maybe not) :) The answer is simpler than you might think. Our application server contains web services only. At the beginning of our project we took an architectural decision to have our web services separated in virtual directories (or projects in VS). This to be able to update parts of our application without affecting the whole system. This was part of a master plan around the smart client principle and would let us deploy small modules into our application which dynamically loads the new behavior. As it turns out we have almost never done this in production. The drawback of this is of course that you get many of the same dll's scattered around in many virtual directories. And when you have many web services (by web services I mean asmx files and not web methods, 43 to be exact), and each one is dependent on your business and data access layer (which is quite huge) and more, megabytes is piling up.

So what's the solution? Well, since we don't really use this as intended we can just merge our web services into one and we will be home free. Except you don't do that two weeks before deployment with acceptance testing coming up. So I have to think of something else. The only solution I can see now is to find some way of making the msi smaller, which at the current time I don't have the faintest idea of how to accomplish. I can use a setup launcher (exe) which will probably solve it, but that will not make our customers very happy. Hopefully I'll figure something out during the weekend, or maybe you have a solution?