DLL Hell Problem

DLL (Dynamic Link Library)
MS introduced the DLL where one or more programs could use a chunk of code stored in a separate file. This worked at a very basic level if the programs were written in the same language (typically C). However, programs needed to know a lot in advance about the DLLs they used, and DLLs did not enable programs to use one another’s data.

What is DLL Hell Problem?
Whenever u install your application and the DLL is modified, u need to reinstall the applicationat that time dll hell problem occurs in VB as higher version overwrites the lower version.It will be eliminated by the concept of assemblies in .NET
IN A SIMPLER WAY: The problem of DLL HELL arises only when ,the dll files of the two versions try to use the same memory location, instead of choosing different location, hence the problem of DLL HELL arises in VB6.0.To overcome this VB.Net is Developed.TECHNICAL APPROACH TO "DLL HELL": DLL files of same name in a same directory, but the dlls are of different versions is termed as "DLL HELL".

How does assembly versioning in .NET prevent DLL Hell?
.NET allows assemblies to specify the name and the version of any assemblies they need to run.

Definition of DLL Hell?
Dll hell is basically a technique to remove versioning problem. Means that suppose you have install the 1.0 version of any software in ur system. Then after u also install 1.1 version of that software on that system. This confusion is removed by dll hell.
"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.

What is the difference between DLL and EXE?
dll is reusable in another applications........dll is inprocess, dll run with an exe
exe is a standalone, outprocess. exe can run independently
· Dlls cannot be run by themselves as they don't have any entry point (Contains only DllMain()).Where as Exes have entry point(Main()) they can be executed.Usually Dlls are used by other Dlls or Exes.
· exes are self executable,where as dll are not exes are not reusable where we can reuse dllsexes are platform dependent where as dll are not platform independentonly console app ,windows apps,windows service produce exes other all dlls only

In .NET a DLL can contain how many classes?
it's not a good practice to have lot of classes in one dll. It has to be logically divided and compiled as separate dll's. Since the output of any .Net code is an assembly and that assembly contains MetaData(self describing assembly), imagine when there are 1000 classes in one single assembly it will take lot of time toload as the MetaData is huge.

How to hide the methods in DLL?
I created one dll that contains add,sub,mul methods after creating the object thatone like obj.add*******I want to hide remaining method how is it possible.
You can make your methods as private, by using private specifier.
How did the MS overcome with the DLL Hell Problem?
The .NET programming model brings a new standard that addresses these DLL problems, with .NET assembly.