.net – What are the `exact` differences between .NET dll and a normal dll

assembliesdllnet

I want to know what are the exact differences between .NET dll and a normal dll.

First question, what is "normal DLL" called? I'm using the word 'normal'. But it doesnt seem right?

Because both follow the PE format. Yeah, I agree that .NET DLL has an extra section. Other than that every thing else is same.

I also know that in .NET code is converted into CIL/MSIL then what is filled in .text section of PE file? MSIL? because there is no binary code. But if they put MSIL in .text section. Loader assumes that its a binary code and allows it to execute. Which is not the case. What am I missing?

I'm surprised to know that

Even the DLL file extension is
artificial. You can have DLLs with
entirely different extensions—for
instance .OCX controls and Control
Panel applets (.CPL files) are DLLs.

What else extensions are used for DLL files?

But I can understand the reason for using different extensions. Why didn't they follow do the same thing in case of .NET DLLS? they could have used a new extension to differentiate it from the "normal" DLL. They even have a different name (ASSEMBLY) for dlls in .NET but couldn't change the extension. huh?

Another completely different question: What is DLL registration? they use regsvr32.exe for it. right? I noticed it when I installed Windows XP SP3. After the installation & before restarting windows, I checked startup list and found lot of regsvr32.exe entries with lot of DLLs.

Please feel free to dive into as much depth as you like. I'm learning about linkers,loaders,binary formats. I'm familiar with PE file format also.

Best Answer

I've copied and pasted this from my own post on it:

The format of a .NET dll is:

PE header
CLR header
CLR metadata
CLR IL code
Native data

PE header

The PE header is the portable executable header that all Win32 applications and libraries have, and instructs Windows what to do with the file. With .NET assemblies this loads the CLR which in turn loads the assembly.

CLR header

This contains information such as the .NET version the .exe or assembly was written with, any strong name signature hash, the address (RVA or relative virtual address) in the file that the resources can be found. And most importantly the entry point for the application which is a token pointing to the MethodDef metadata table, or another file. This token is 0 for class libraries.

CLR metadata

This is information about the module that is stored inside several different types of "streams". These streams are typically compressed, with the exception of #~ which can be uncompressed for edit and continue. The streams come in two forms, a heap which is just used for storage, and tables.

The various parts of your DLL/assembly are stored in different tables based on what they do - for example all types are stored in the TypeRef table, all methods in the Method table. Each of the tables references a parent table.

The start point of the tables is the Module table which contains just the name and guid of the module as a single row. After this is the ModuleRef table which contains information about all modules that are referenced by this module (from the same assembly). In the case of VS.NET and its use of csc.exe there aren't multiple files in the assembly, just one module.

After this is the TypeDef table which contains 6 columns holding the type's name, namespace, its parent (0 for interfaces and Object), the start row for its fields in the FieldDef table, start row for its methods in the MethodDef table.

IL and native data

The app itself.

The book Inside Microsoft .NET IL Assembler - Serge Lidin goes into a lot more detail if you're interested.

This is the style that Microsoft tends to use in their examples.

It appears that the guidance in this area may have changed, as StyleCop now enforces the use of the C# specific aliases.

.net – What’s the difference between struct and class in .NET

In .NET, there are two categories of types, reference types and value types.

Structs are value types and classes are reference types.

The general difference is that a reference type lives on the heap, and a value type lives inline, that is, wherever it is your variable or field is defined.

A variable containing a value type contains the entire value type value. For a struct, that means that the variable contains the entire struct, with all its fields.

A variable containing a reference type contains a pointer, or a reference to somewhere else in memory where the actual value resides.

This has one benefit, to begin with:

value types always contains a value
reference types can contain a null-reference, meaning that they don't refer to anything at all at the moment

Internally, reference types are implemented as pointers, and knowing that, and knowing how variable assignment works, there are other behavioral patterns:

copying the contents of a value type variable into another variable, copies the entire contents into the new variable, making the two distinct. In other words, after the copy, changes to one won't affect the other
copying the contents of a reference type variable into another variable, copies the reference, which means you now have two references to the same somewhere else storage of the actual data. In other words, after the copy, changing the data in one reference will appear to affect the other as well, but only because you're really just looking at the same data both places

When you declare variables or fields, here's how the two types differ:

variable: value type lives on the stack, reference type lives on the stack as a pointer to somewhere in heap memory where the actual memory lives (though note Eric Lipperts article series: The Stack Is An Implementation Detail.)
class/struct-field: value type lives completely inside the type, reference type lives inside the type as a pointer to somewhere in heap memory where the actual memory lives.