| A Dynamic-Link Library, or DLL, is an older technology than the .NET runtime, but it solves a similar set of problems. Code in a DLL can be called from Visual Basic 6 or unmanaged C++, so it provides some degree of binary compatibility. The word dynamic in the name refers to the fact that code in a DLL is linked in only while the application is running: If the DLL changes after the application has been compiled, the new version of the code will be used. This is in contrast to a statically linked library like the ones covered in Chapter 5, "Writing a Class Library in Unmanaged C++." SHOP TALK: DLL HELL The dynamic nature of a DLL can be a double-edged sword. At first glance it sounds amazing: Any upgrades or improvements to the library are immediately available to all the code that was using it. There's no need to recompile or redeploy those applications. That is very appealing. But what if what was added to a DLL wasn't exactly an upgrade? What if some functionality you were relying on worked differently in the new version, so differently that your application no longer worked at all? Believe me, it happened, and it happened a lot. Many times I've had phone calls that went like this: "Hey Kate, we've got something weird happening here. That application you wrote for us has stopped working." "Really? What's changed?" "Nothing really, it was fine last week and now it just hangs up when I try to use the Gizmo dialog box." "Is it like this on all the machines?" "No, that's what's strange , just on mine." "Oh, really? And you haven't installed anything?" "Well, I did install a new version of Internet Explorer, but that couldn't change anything in your application, could it?" Oh, it certainly could. Internet Explorer installs dozens of DLLs, and quite often working code that was using the old versions of those DLLs just stops working after the install. And I don't mean to single out IE; there are all kinds of applications, from many vendors , that can have this effect. We came to call it DLL Hell, and it certainly was unpleasant. It's one of the problems the .NET Global Assembly Cache was designed to solve. In this chapter, I recommend you copy the DLLs you are using to the executable folder for the client application. That means that any new version installed on the system in some other folder won't affect you. That's no protection against changes in the Windows DLLs, but it can at least keep things under control as far as private DLLs are concerned . |
Creating a DLL in unmanaged C++ is straightforward, as you'll see in this chapter. Once created, a DLL can be used from many languages: Visual Basic 6, unmanaged C++, managed C++, and any other managed language. You can't write a DLL in managed C++a managed C++ class library like those created in Chapter 6, "Writing a Class Library in Managed C++," is kept in a file with a .dll extension, but the internal layout of a DLL is very different from a managed assembly containing a class library.  |
