DLL Hell in .NET

  • Thread starter Thread starter Allan Wong
  • Start date Start date
A

Allan Wong

What are the under-lying DLLs or libraries that .NET is sitting on which
after installing another program will cause the entire .NET Framework to
fail?
 
Not to mention VC++ .NET, is VB.NET, C#.NET, ASP.NET using NTDLL.dll?
What is .NET written with?
Is it built on any of the DLL/OCX in Windows or Windows\System32 folder on
Windows 98/NT/XP?
 
Allan Wong said:
Not to mention VC++ .NET, is VB.NET, C#.NET, ASP.NET using NTDLL.dll?
What is .NET written with?
Is it built on any of the DLL/OCX in Windows or Windows\System32 folder on
Windows 98/NT/XP?

Yes, there is no code you run on your system that doesn't access atleast one
kernel level function. Everything from windowing, consoles, drawing, memory
allocation, etc are provided somewhere down in the depths of the system,
including executable loading.
The .NET exe's that run are not directly related to any of them, they import
mscoree.dll and thats about it. mscoree.dll imports from kernel32.dll,
advapi32.dll, user32.dll, shlwapi.dll, and urlmon.dll directly, according to
depends.exe.
No matter what language you write in, even java, the language is going to
use those underlying functions, probably that specific set mostly, because
it provides alot of features.
But, those dll's shouldn't change much, they are pretty central to the
system and are hard to break.

Other components of the system also use OLE32.dll and MSVCR71.dll directly.
There are probably a good number of other dlls under those as well.

Many of the windows forms controls wrap the system provided controls.

Also, did you have to post this so widely? Just one group would have been
enough I'd think.
 
Don't cross post.

Why don't you run depends.exe on all the .net dlls to find out yourself?
 
Microsoft,

Can you allow a registering the system core dll into many registry?
You only have one registry in one operating system.
This way, every .NET framework version can run independently.

Thanks.
 
Allan Wong said:
Microsoft,

Can you allow a registering the system core dll into many registry?
You only have one registry in one operating system.
This way, every .NET framework version can run independently.

What do you mean? I'm afraid that didn't make much sense.
..NET framework versions run independently of each other, but not
independently of the operating system, no framework can run independently of
the operating system.
 
..NET does not use any Windows DLL's, in fact, it creates an instance of Mac
OS X and then executes in that VM. So you can delete all the Windows DLL's
and still run all your .NET applications.
 
Look, that could become a new .NET anecdote :-)

I think .NET at least relies on DLLs shipped with Windows (kernel, gdi32,
user and so on). But these are unlikely to be replaced by an installation
routine. The rest of the libraries depends on which framework features you
use in your programs. If you, for example, used P/Invoke aggressively, you
could end up being highly dependent on certain versions of a number of DLLs
whereas their absence wouldn't cause the framework itself to fail.
 
Is there a list of what libraries in the .NET that rely on Pinvoke or
platform specifics (winforms etc)



Dmitriy Lapshin said:
Look, that could become a new .NET anecdote :-)

I think .NET at least relies on DLLs shipped with Windows (kernel, gdi32,
user and so on). But these are unlikely to be replaced by an installation
routine. The rest of the libraries depends on which framework features you
use in your programs. If you, for example, used P/Invoke aggressively, you
could end up being highly dependent on certain versions of a number of DLLs
whereas their absence wouldn't cause the framework itself to fail.

--
Dmitriy Lapshin [C# / .NET MVP]
X-Unity Test Studio
http://x-unity.miik.com.ua/teststudio.aspx
Bring the power of unit testing to VS .NET IDE

Joubert said:
.NET does not use any Windows DLL's, in fact, it creates an instance of Mac
OS X and then executes in that VM. So you can delete all the Windows DLL's
and still run all your .NET applications.
folder
on Framework
 
Back
Top