As a result, our application will fail at runtime when trying to load the version that wasn’t copied. Both DLL files are copied to the output folder, but there can be only one log4net.dll file. Here’s an example: project A might use log4net V1.1 and project B uses log4net V1.2. What to do when several of its projects depend on different version of the same assembly? So now the problem arises for a single application. These in turn, depend on dozens more and we end up with hundreds or thousands of dependencies. In the modern world, we are dependent on dozens of libraries. This means we can store different versions of the same DLL and the different applications will load their intended version. Alternatively, we can use the GAC for shared DLL’s, which supports versioning. We will usually ship DLL files separately for each application. Then, one of the applications updated the DLL file and now the other applications no longer work. The original DLL hell issue was this: Several applications use a shared DLL file. One such problem is the infamous DLL Hell (and variations of it). Much like cockroaches, these problems resist technological advancements and increasing human knowledge. Some problems in programming seem to stay and bother us forever.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |