How Dll Caching in Application ?

Question

0.00/5 (No votes)

See more:

hi !!!

I use component in application where low load form. I want to cache dll in C#??

Posted 26-Apr-11 18:24pm

javad_r_85

Updated 26-Apr-11 18:39pm

Sandeep Mewara

v2

Add a Solution

Comments

Sandeep Mewara 27-Apr-11 0:39am

Not clear to me.

2 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Abhinav S · Answer 1 · 2011-04-26T18:31:00

Solution 1

The framework will do this for you by loading any dll in memory. You need not worry about this at all.

Posted 26-Apr-11 18:31pm

Abhinav S

Comments

Sergey Alexandrovich Kryukov 27-Apr-11 0:53am

Even though it is not quite clear what is meant by "will do this" (what "this"), I think this answer should dismiss OP's concern. My 5.
I tried to explain why -- what really happens with those modules. Please see.
--SA

Abhinav S 27-Apr-11 0:56am

Thanks for the 5 SA.

Sergey Alexandrovich Kryukov · Answer 2 · 2011-04-26T18:51:00

You should understand the following. One difference between native executable modules and .NET is that a DLL is not anything special on .NET, just an extension which can be anything. Also, there is no fundamental difference between DLL and EXE. The only special feature of EXE is a special entry point (usually "main"). In particular, an application EXE file can be loaded or referenced as an assembly in another referenced assembly exactly as it is done with DLL (and it can be a useful technique in some cases). In turn, a DLL with an implementation of a special interface can be used as EXE under a specialized host.

The fundamental concept is .NET is not EXE or DLL but assembly. The executable modules like EXE or DLL are are called modules. Visual Studio only supports creation of an assembly consisting of a single (main) module which can be found via the .NET run-time library. When an assembly is loaded with all the assemblies it references directly or indirectly, all those assemblies are loaded in one single process which is nearly insensitive to the boundaries between loaded assemblies. Same thing happens if an assembly is loaded in the process dynamically during run-time via System.Reflection.Assembly loading methods or CodeDOM. (At the same time, for each method it is possible to determine in what assembly and module it is working.) More than that, all these assemblies are loaded is a single Application Domain (System.AppDomain) unless a different Application Domain is created explicitly during run time.

All that should explain that the boundaries between assemblies are not so essential (but they are much more important in terms of permissions.) Moreover, it is good to understand that the methods are not loaded in the memory immediately. They are JIT-compiled into the machine code only on demand, on per-call basis.

—SA