| Author: avtar 05 Sep 2008 | Member Level: Gold | Rating: Points: -20 |
DLL Hell is where loading one program breaks another program. Basically, any time an application (or service patch) replaces (or loads) an executable used by another application, there is a risk. It doesn't matter if the executable is an exe, vxd, dll, or something else, the risk is the same, and you, the user, have no control over what is happening.
To make matters worse (much worse), when your clients install software that you've written, your software might break other, un-related, applications on the clients machine. This is particularly true if you've used a Microsoft compiler. (mfc42.dll is known to cause this type of problem.) Of course, you and your clients have no control at all over what happens.
dotnet assembly has over come this problem and also u can have multiple version's of assembly/dll's in a same folder which was not possible with com dll's
|
| Author: Geetha 05 Sep 2008 | Member Level: Gold | Rating: Points: -20 |
DLL Hell
Let's take a brief look at this issue which used to give many headaches to System Administrators and Code Writers. There is no need to panic listening to something called "DLL Hell" as this problem is now totally eliminated with .NET Framework 1.1. It's good to know what used to happen before with the deployed applications, the way they used to behave when new version of an existing application was installed and what exactly is "DLL Hell" and so on.
The Problem
Previously, before .NET, this used to be a major issue. "DLL Hell" refers to the set of problems caused when multiple applications attempt to share a common component like a dynamic link library (DLL) or a Component Object Model (COM) class. In the most typical case, one application will install a new version of the shared component that is not backward compatible with the version already on the machine. Although the application that has just been installed works well, existing applications that depended on a previous version of the shared component might no longer work. In some cases, the cause of the problem is even more subtle. In many cases there is a significant delay before a user discovers that an application has stopped working. As a result, it is often difficult to remember when a change was made to the machine that could have affected the application. A user may remember installing something a week ago, but there is no obvious correlation between that installation and the behavior they are now seeing. The reason for these issues is that version information about the different components of an application aren't recorded or enforced by the system. Also, changes made to the system on behalf of one application will typically affect all applications on the machine.
One reason why it was hard to build an isolated application was the run-time environment typically allowed the installation of only a single version of a component or an application. This restriction means that component authors must write their code in a way that remains backward compatible, otherwise they risk breaking existing applications when they install a new component. In practice, writing code that is forever backward compatible is extremely difficult, if not impossible. Also components were shared because disk space and memory was expensive. In the past few years, hard disk and memory prices have dropped dramatically, and disk space is no longer a premium. But as applications have increased in size and in modularity not so long ago many applications were entirely self-contained in a single .exe file - the DLL sharing issue has not been addressed, and the problem has grown over time.
How .NET addresses DLL Hell?
Microsoft .Net 1.1, which is integral to the Windows Server 2003 operating systems, supports strong binding. Strong binding means an application or component can bind to a specific version of another component, so you can reuse components or use them in isolation.
.Net 1.1 will provide Windows Server 2003 operating systems with a Global Assembly Cache. This Cache is a repository for all the .Net components that are shared globally on a particular machine. When a .Net component is installed onto the machine, the Global Assembly Cache looks at its version, its public key, its language information and creates a strong name for the component. The component is then registered in the repository and indexed by its strong name, so there is no confusion between different versions of the same component, or DLL.
Windows 2003 Server also uses rules to make sure that an application finds the right component and version. The system will first look for a local version of the component, and will then look in the cache to find an exact match for the strong name of the required component. Failing that, the system will use heuristics to find the next best component, but by default an application will always run against the component that it was built and tested against. Administrators will be able to override these rules for exceptional cases.
Another feature of Windows Server 2003 is that .Net components will have no registration policy. This means it will be easy to take a .Net component on server and copy to another server. Microsoft is calling the feature xcopy deploy, after a command used in DOS to copy capability files, directories and even whole drives from one destination to another. It means you can copy applications instead of reinstalling them and the whole process becomes much simpler.
Also, .NET Framework 1.1 introduced something called side-by-side execution. Side by side is the ability to install and run multiple versions of the same component on the machine concurrently at the same time without interfering with each other. With components that support side-by-side, authors aren't necessarily tied to maintaining strict backward compatibility because different applications are free to use different versions of a shared component.
Reference:
http://www.startvbdotnet.com/extras/dhell.aspx
|
| Author: Aru 05 Sep 2008 | Member Level: Silver | Rating:  Points: 3 |
This is a problem everybody faced in asp application which
uses dll. Dll process still be in memory
even after the objest is destroyed exclusively causing the
program to restart. this will happen wen u trying to share the d same dll in multiple application..
|
| Author: D.Jeya kumar(JK) 05 Sep 2008 | Member Level: Diamond | Rating: Points: 15 |
Hi,
This the Problem with Previous versions of microsoft products like vb and asp. there the dll version is a problem. one application may had the same dll and it cannot be registered in the system. because already a version of the dll is there in the system.
So we cannot install the newer version of the dll. and while uninstalling the dll also it will uninstalled and that dll is used by another application.
So in order to avoid this problems microsft introduced the versioning in the dll. now in every dll will have the version number . so that many dll can be exists in a system with same name with different version this can be achieved by the strong name key pair. which is unique.
Regards
JK
|