Click here to Skip to main content
15,070,828 members
Please Sign up or sign in to vote.
2.33/5 (3 votes)
See more:
Hi All

I always confuse with Assembly, .exe and .dll files.
What is the basic concepts behind all these.?
What is the differences and similarities.?

Please any one can help me.
Posted

In addition to Marcus's answer, do have a look at these answers too: http://www.codeproject.com/Answers/218803/what-is-the-difference-between-exe-and-dll-files[^]
   
Comments
   
Good link, a 5. Did not reference my answers? There is a lot more to it.
Please see my solution.
--SA
Tarun.K.S 8-Jul-11 6:49am
   
Thanks SA!
[no name] 8-Jul-11 7:04am
   
Nice Link. +5.
Tarun.K.S 8-Jul-11 7:08am
   
Thanks Rama!
thatraja 8-Jul-11 8:41am
   
Have 5 to boost you after platinum.
Tarun.K.S 8-Jul-11 8:45am
   
Thanks man, its a great achievement for me to be a scholar in Authority. Still got a long way to go.
Really appreciate your upvotes, without them it would have taken me more time to reach. :)
Assembly is a complex concept, a main unit of the .NET. There are many different aspects of the assemblies and their identities. If could be a subject of really big article. You can start reading here: http://msdn.microsoft.com/en-us/library/hk5f40ct(v=VS.90).aspx[^].

I will only explain relationships between assembly and executable module. An EXE or DLL file are kinds of assembly executable modules. First surprising fact it: in .NET, there is no conceptual difference between DLL and EXE files.

Usually people know that EXE file is used to start a process from OS (normally, the Shell, but any process can start any other process; one special case is Service Controller use to start any application working as a Windows Service). DLL's are used as class libraries. When a DLL is used as a main assembly module (see below), it can be referenced by other assembly, a DLL or EXE. In this way, a running process have one or more assemblies loaded, directly or indirectly. A running code can also load assembly dynamically, using System.Reflection.Assembly.

Now, this picture is typical but not mandatory. First, any executable module can have any arbitrary "extension" (actually NTFS does not have extensions (DOS had them), so this is a legace concept now understood as a part on file name). Actually, EXE file is exactly same thing as a class library normally represented by DLLs. There is only one simple convention: one class in EXE is special: it provides the class with static entry point method. Normally, this static method is called Main, but it can be anything else and can be altered in a compilation parameter.

The OS (.NET Framework) simply "knows" by convention that an assembly should be loaded, entry point (manifested by assembly file) located and run. Any of us can create alternative host application running completely different type of assembly with completely different type of entry point (or even a set of different entry points) supporting completely different interface.

I discussed such architectures in my past solutions:
Create WPF Application that uses Reloadable Plugins...[^],
AppDomain refuses to load an assembly[^],
code generating using CodeDom[^],
Create WPF Application that uses Reloadable Plugins...[^],
Dynamically Load User Controls[^].

From the other hand, .NET assembly represented by EXE file with which can work as traditional application can also be used as a regular class library. Any other assembly can reference it as a regular DLL. This fact is not very well known.

Finally, I promised to explain about modules. Visual Studio supports only the simplified modular model: every assembly is represented by its only executable module, EXE or DLL file (or anything, just one executable file). The general model could be used if you make a custom build or just a bare C# compiler (I'm not sure about other compilers): every assembly can be composed of several different files called modules. Don't mix modules with referenced assemblies: no one of the modules represent the whole assembly. A module cannot be referenced by other assembly, it can only be used to create a new assembly. The same module can participate in two (or more) different assemblies. The same code may work in different way in different assemblies. For example, different assemblies can have different security permission. This would make some method placed in the module working properly when run in one assembly and fail in another one. One and only one of the modules in each assembly is called main module. It carries assembly manifest defining main assembly properties and identity. Again, with Visual Studio, each assembly is composed of just one module, so all modules are main.

—SA
   
v2
Comments
Espen Harlinn 8-Jul-11 6:45am
   
A 5++ - good work :)
   
Thank you, Espen.
--SA
Tarun.K.S 8-Jul-11 6:49am
   
Bookmarked for future reference. :D
5+
   
Thank you, Tarun.
--SA
Raju Prajapati 8-Jul-11 6:55am
   
Thank you
   
Please consider accepting this answer formally (green button).
Thanks.
--SA
Sugato Pal 8-Jul-11 7:05am
   
Though i answered this question,still i have some doubts.But this clears them ALL.Super answer.My 5~.
   
Thank you very much, Sugato.
So, do you still have any doubt? Perhaps I know how to check up things...
--SA
[no name] 8-Jul-11 7:47am
   
Excellent Answer. +5.Bookmarked for future reference too.
   
Thank you, Ramalinga.
--SA
[no name] 8-Jul-11 8:42am
   
It's my Pleasure.
harish85 8-Jul-11 13:01pm
   
I didn't get this point. "there is no conceptual difference between DLL and EXE files." I thought DLL and EXES are different in all places. they turned to somewhat mature CS concepts. DLL as "shared library" EXE as "executable" in all OS (extn and name might be different).
Please correct me if I am wrong.
Sergey Alexandrovich Kryukov 12-Jul-11 15:34pm
   
No. They are only different in the sense I described in this answer; there are no more differences, at least in .NET, I'll guarantee that. :-)
Also, they are just extensions. You can rename them and use in both ways.

I tell you: you can use EXE (with entry point) as library (normally, ignore entry point; or not). You can use DLL (without entry point) as EXE if you design alternative convention for entry points and design a special host method to support it.

--SA
There's an article here that might be a good starting point: http://en.wikipedia.org/wiki/.NET_assembly[^]
   
Comments
Tarun.K.S 8-Jul-11 6:15am
   
Nice link. 5+
   
There is a lot more to it.
Please see my solution.
--SA
Raju Prajapati 8-Jul-11 6:53am
   
Thanks
An assembly is the basic building block for the .NET Framework.
At a fundamental level, both DLL and EXE are assemblies.

* An assembly is what contains the underlying code that is used by the Common Language Runtime after compiled. It also contains additional information about itself, such as version and resources that are needed for the assembly to work.

*An exe is an executable file,that may run on its own.Its independent.

*An dll always bind to another dll or exe at run time.They can not execute independently.Agin by adding reference of an dll one can call the methods written inside that dll.
   
Comments
   
Not 100% accurate. Please see my solution to see what I mean. I voted 4.
--SA
0) Both an exe and a dll are assemblies.

1) An exe is an assembly that can be directly executed. A DLL cannot be.

2) Both an EXE and a DLL can be loaded as a reference inside another assembly.
   
Comments
   
Not 100% accurate. Please see my solution to see what I mean. I voted 4.
--SA
#realJSOP 8-Jul-11 7:23am
   
Unlike you, I don't have the time nor desire to type a narrative about something that is easily found on google. He also had the option of paying attention in class.
Sergey Alexandrovich Kryukov 12-Jul-11 15:32pm
   
Well, I agree of course; EXE and DLL are not assemblies by themselves, they are executable modules of assemblies. This difference is only essential in reflection and when you create assembly with several modules. It is not supported by Studio, but is supported by C# compiler. "Directly executed" is not quite clear -- that's all what needs some explanation. Good answer, anyway.
--SA

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




CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900