Customers angry, fighting unknown DLL dependencies

Question

I'm a one man show developing a C++ Windows application for a customer. Over the past several months we've been running to the same problems with missing DLL dependencies on customer machines. Despite my best efforts something keeps going wrong and we get angry emails back. My boss and my boss's boss are angry with me and the customers aren't happy.

I'm hoping you guys can help out and give suggestions/ideas on how to get the deliverables in order. Before some of the obvious:

1. I have no test machine. That is, I can't replicate the customer environment nor attempt to install the app on a "clean" system to catch gotchas before shipping.
2. I've tried using depends.exe to track down what versions of the DLLs my project is dependent upon. I'm shipping our code with the redistributables I've been able to find that way. After that it's an angry customer email waiting game.
3. I do have access to a 64-bit machine and 32-bit machine to install new builds. It always works there.
4. I'm required to use a third-party DLL which can not be registered (it's buggy as hell.)
5. I'm not supposed to use Install Shield, any other automated installer, or write an install script.
6. I provide written instructions on how to get the app installed (unzip, double click exe file.)

I'm tired of taking heat for this stuff. What am I missing that I could be doing? What should I ask in terms of support from my employer? How should I ask for that support in a way that they'll provide it?

Update:

Virtual Machine torpedoed. They don't want me spending all of my times setting up and tearing down customer configurations. Instead, I'm now working with the customer to get a base configuration so that I know the exact machine set-up I'm supposed to target. If it's not up to that spec, I no longer have to care. At least something went somewhere... although I'd still like a test machine.

Answer 1

If you don't have a test machine, can you at least use a virtual machine with a clean Windows installation?

Answer 2

You could ask the customer for VPN access or something similar so you could use their environment.

Answer 3

Could some of your dependencies be statically linked instead?

Answer 4

I have no test machine. That is, I can't replicate the customer environment
enter code here nor attempt to install the app on a "clean" system to catch
gotchas before shipping.

This type of setup typically never ends well. No matter how good you are there will always be significant differences between your developer machines and the customer machines. For one thing Visual Studio tends to include a shitload of runtimes that it may make your application dependant on without saying anything. Setting up a virtual machine is not very complicated. I use VMWare Workstation to emulate all kinds of different machines. Only requirement is that you have licenses for the operating systems and programs you want to install on the virtual machines. VMWare offer a 30 day free trial and after that I believe $189.

Answer 5

You should quit. In your quit letter you should explain why the situation is ridiculous and sets both you and the customer up for frustration. Let's go over the things you've said about your situation:

I have no test machine. That is, I can't replicate the customer environment nor attempt to install the app on a "clean" system to catch gotchas before shipping.

No professional development firm releases products without testing install. We are a very small firm and we have numerous VM's that we run tests on and that we run our installers on.

I've tried using depends.exe to track down what versions of the DLLs my project is dependent upon. I'm shipping our code with the redistributables I've been able to find that way. After that it's an angry customer email waiting game. I do have access to a 64-bit machine and 32-bit machine to install new builds. It always works there.

These aren't too bad or too strange. It is odd that you don't know what DLL's you're using but there's not much your employers could do for that unless you're maintaining an undocumented legacy system - then it's their fault for not documenting anything.

Unfortunately you've said these systems are not "clean" so it is very easy to lose track of what steps are actually necessary to successfully install the product.

I'm required to use a third-party DLL which can not be registered (it's buggy as hell.)

This happens.

I'm not supposed to use Install Shield, any other automated installer, or write an install script. I provide written instructions on how to get the app installed (unzip, double click exe file.)

This is utterly insane. Customers are NOT capable of following basic instructions. The fact that you've been told not to use an installer to make the customer's life easier is almost certainly the cause of your problem. You can't tell what they've done. When you ask them they're going to lie or forget what they did...if they ever knew to begin with. Your employers have caused a sever support issue by this edict and the situation is just plain never going to improve for you.

Tie this with the first issue (not having adequate install test platforms) and your product is certain to fail. Your customers SHOULD be mad and you should be as well. The situation your employers have created is not one conducive to development of a successful product. There is, simply put, nothing you can do until these issues are addressed.

Answer 6

only for review: You have this redistributable package? http://www.microsoft.com/downloads/details.aspx?familyid=9b2da534-3e03-4391-8a4d-074b9f2bc1bf&displaylang=en

It helps for me.

Answer 7

Present it to your boss this way:
A machine for testing installations is far cheaper than a pissed off customer or even your TIME in tracking down issues.

Answer 8

Other people have given you a big picture answer; here are a couple smaller suggestions that you might find helpful in case you aren't able to take bigger action:

• list what DLLs your application is dependent on. If you don't know exactly what your application depends on, how can you ensure that the dependencies are available?
• Write a utility that searches out and logs any instance of those DLLs on a system, along with the DLL version and the system's path. If a user is having problems, this utility might go a long way to helping you troubleshoot the problem, since you've mentioned that you don't have physical or network access to the machines that exhibit the problem.
• write a utility that does nothing but LoadLibrary() your dependencies. Failures can be logged and at least you'll have an easy way to determine what's wrong on a customers machine.

Hopefully, the common problems will be figured out quickly and fixes made so that they stop being common problems and you'll have less and less need to use these tools. But until you get a handle on the problems they may prove helpful.

Also, in one comment you mention that the problem is caused by Windows system DLLs - these should generally cause few "DLL hell" problems on modern systems, since 3rd party software (including yours) is generally unable to replace these. All Windows systems should get what MS provides, and MS is pretty good (though not necessarily perfect) about making new ones backwards compatible. If these are causing you problems, you might want to post details of which DLLs they are (and maybe versions) so people can answer with more specifics, like what might need to be configured to ensure that Windows setup installs the DLL.

Answer 9

Do you include the specific DLLs in your install?

If so, this is the wrong way to go about it. Instead, you should include the MS redistributable pack for your compiler. For example, if you compile using MSVC 8.0 SP1, you would get this pack and install it with your app:

Microsoft Visual C++ 2008 SP1 Redistributable Package (x86)

Each MSCV version (including SP level) has its own redist package. Make sure you get the right one for your compiler.

After you put the fire out, sit down with your boss and convince them that if you're going to pretend to be a software company, you have to act like one. Get a real production environment. This isn't a high school programming club, it's your livlihood.

EDIT: Just to be clear. Once you get the redist, dont unpack it to your machine and then include the encosed DLLs in your setup. Instead, include the entire redist installer as a sub-step of your install. Install the redist first, then install your code.

Answer 10

If you pass a full, absolute path to LoadLibrary(), it will only look in that exact location for the DLL. You may be able to use this to get around some of your problems. Package all the DLLs your app needs inside a "lib" folder and include it in the zip file with your program. As long as the "lib" folder lives in the same folder as the .exe, you can use GetCurrentDirectory to construct absolute paths to those libraries and ensure that the libs being loaded are the same ones that you were using when you tested the software. However, if you are using a library that you don't have the rights to redistribute, then this method isn't very helpful.

Answer 11

I'd check out the VMWare. It's a pretty cool virtual machine, and you could probably mimic the customer's environment.

Also, I'd have a word with your boss. It's entirely possible that they're under the assumption that the product you shipped has been tested thoroughly by you. So it's probably a miscommunication, and I would talk with him just to be sure. If you boss is failing to understand your point, I would most definitely consider quitting because what would happen is that he would claim that he had to "talk to you" and "set you straight" whenever the product became successful. It's entirely possible that in your review, he'd put down that you were uncooperative or worst. So my best is to talk, then form a decision based on that on whether or not you should continue with the company.