From DLL Hell to DLL Super Hell and back again
Wow, that’s a scary blog title for a CrossTalk entry. CrossTalk deployment is designed to be easy, and xcopy deployable. However there are a few things that must be explained.
Most of us remember the days of DLL hell. Who would have thought we might ever long for such days? In fact it is true. Microsoft while trying to “fix” the problem actually made an even bigger problem called “Fusion”. Fusion was introduced and exists for C++ applications through and including Visual Studio 2008. In fact, it is so bad that for C++ in Visual Studio 2010, Micosoft is returning to “plain old DLL hell”. As one C++ blogger writes, “CRT/MFC/ATL/OpenMP-DLLs no longer use fusion (huray!); it uses plan old dll-hell”
Needless to say, as soon as Visual Studio 2010 is released we will recompile CrossTalk to further simplify CrossTalk deployment.
Why does this affect CrossTalk?
CrossTalk is written in three languages: Delphi, C# and C++. One of CrossTalk’s DLL’s is written in C++, and thus must follow the deployment rules of C++. The best option is static linking, including all code inside the DLL and simplifying deployment. Unfortunately in many cases including that of CrossTalk, static linking is not possible.
CrossTalk requires the Visual C++ Runtime Libraries. Deploying them offers three options. Static linking as previously discussed is not possible. That leaves us with vcredist installation, or bin deployment.
vcredist (x86 or x64) is an installation program that users can run to centrally install the C++ libraries on a users system so that all applications can use them. However this violates one of CrossTalk’s deployment goals of xcopy deployment. Many users will not have control of their servers or for other reasons will not want to require users to run any setup program.
CrossTalk includes the vcredist as part of it’s setup intended for developers machines.
The C++ DLL’s can also be deployed along with the application in the same directory. This allows for easy xcopy deployment. However these DLL’s when deployed this way, must exist in the same directory as the application. They cannot be deployed in another directory that is in the path and be shared by other applications. (i.e. Thanks Microsoft!) You may also need a manifest (text file) in the application directory which CrossTalk will supply for you. More on manifests.
vcredist or bin?
For deployment this is acceptable, however during development it is quite tedious to copy these DLL’s to each application directory when a new project is created. Becuase of this the recommendations are:
- On development machines, run vcredist to centrally install the C++ libraries.
- For deployment you can require the users to run vcredist, or use bin deployment to greatly simplify your deployment.
vcredist can also be embedded in your installation through merging so it is seemless, however like many things from Microsoft, it is not nearly as simple as it should be to do so.