Adding Reference to Dll (Class Library ) & Using statements
-
Hi, I would like to know: 1.what happens when you add a reference to a Class library in dotnet. 2.Is it something like a "implicit" linking in C++? 3.Can I make the library statically link to the exe? 4.And does the dll in dotnet internally have implementation for DLLAttach, Detach?
:beer:
-
Hi, I would like to know: 1.what happens when you add a reference to a Class library in dotnet. 2.Is it something like a "implicit" linking in C++? 3.Can I make the library statically link to the exe? 4.And does the dll in dotnet internally have implementation for DLLAttach, Detach?
:beer:
1. It is similar to compile-time linking in C++ in that the CLR automatically loads the library 2. A little bit. 3. No. The CLR takes care of runtime loading and linking automagically. You are not allowed to have anything to do with it. 4. All necessary runtime loading and linking is taken care of by the CLR.
The difficult we do right away... ...the impossible takes slightly longer.
-
1. It is similar to compile-time linking in C++ in that the CLR automatically loads the library 2. A little bit. 3. No. The CLR takes care of runtime loading and linking automagically. You are not allowed to have anything to do with it. 4. All necessary runtime loading and linking is taken care of by the CLR.
The difficult we do right away... ...the impossible takes slightly longer.
-
Thanks for the reply mate. I'm trying to look into the internals of managed world. The document says "CLR is hosted"? Does that mean CLR is per process stuff? is it not system wide?
:beer:
The CLR is 100% a user mode component. No kernel mode stuff at all. Technically, the CLR maintains a single process space, and all .NET "processes" are segregated within that one process space. These are called Application Domains. The fact that they are really within the same process makes inter-application communication much simpler and faster.
The difficult we do right away... ...the impossible takes slightly longer.
-
The CLR is 100% a user mode component. No kernel mode stuff at all. Technically, the CLR maintains a single process space, and all .NET "processes" are segregated within that one process space. These are called Application Domains. The fact that they are really within the same process makes inter-application communication much simpler and faster.
The difficult we do right away... ...the impossible takes slightly longer.
Thanks for the reply Richard. I'm trying to dig a little deep into it but most of the links show up a blunt high level Block diagrams , explaining the stacks in the framework. I need to a pointer to understand low level details of how CLR is invoked to deal managed Applications. Anywhere you can point me to? I want to know: When I execute a managed App, how does the OS route the exe to the CLR? Or CLR is mapped to every process? If CLR hosts all the managed Apps as domains? then how does it over ride 4GB limit per process in a 32bit system?
:beer:
-
Thanks for the reply Richard. I'm trying to dig a little deep into it but most of the links show up a blunt high level Block diagrams , explaining the stacks in the framework. I need to a pointer to understand low level details of how CLR is invoked to deal managed Applications. Anywhere you can point me to? I want to know: When I execute a managed App, how does the OS route the exe to the CLR? Or CLR is mapped to every process? If CLR hosts all the managed Apps as domains? then how does it over ride 4GB limit per process in a 32bit system?
:beer:
Yes, those certainly are important questions. I'm not sure where to find such detailed information. Perhaps the MSDN blogs? Good luck.
The difficult we do right away... ...the impossible takes slightly longer.
