all groups > dotnet clr > september 2003 >
You're in the

dotnet clr

group:

DLL Hell in .NET


Re: DLL Hell in .NET Scott M.
9/25/2003 10:33:28 AM
dotnet clr:
???


[quoted text, click to view]

Re: DLL Hell in .NET Mr.Tickle
9/25/2003 5:53:02 PM
Can you be more specific?


[quoted text, click to view]

DLL Hell in .NET Allan Wong
9/25/2003 8:57:34 PM

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?


Re: DLL Hell in .NET Allan Wong
9/26/2003 9:45:07 PM
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?


[quoted text, click to view]

Re: DLL Hell in .NET Daniel O'Connell
9/26/2003 10:13:01 PM

[quoted text, click to view]

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.
[quoted text, click to view]

Re: DLL Hell in .NET Daniel O'Connell
9/27/2003 8:42:42 PM

[quoted text, click to view]

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.

[quoted text, click to view]

Re: DLL Hell in .NET Allan Wong
9/27/2003 9:17:11 PM
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.




[quoted text, click to view]

Re: DLL Hell in .NET Joubert
9/29/2003 7:18:17 PM
..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.


[quoted text, click to view]

Re: DLL Hell in .NET Mr.Tickle
10/7/2003 5:12:56 PM
Is there a list of what libraries in the .NET that rely on Pinvoke or
platform specifics (winforms etc)



[quoted text, click to view]

Re: DLL Hell in .NET Dmitriy Lapshin [C# / .NET MVP]
10/7/2003 5:16:15 PM
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

[quoted text, click to view]
AddThis Social Bookmark Button