Curious about DLLs in C#

Question

Hi, this is not a question about how to use DLLs, but how DLLs work. That is, when I build a DLL library and compile I get a DLL file. Well, in Visual Studio, I could add a reference to this DLL file and intellisense would start showing the classes inside the DLL as if the code in the DLL was like in a static library. Well how can that be? I mean DLLs are compiled files and I though compiled files are enigmatic things that cannot be decrypted. I mean look at the unmanaged libraries. You need to use [DLLImport("library.dll)] to be able to use them and even then, you have to cross your fingers that you didn't make a typo with the class name because Intellisense won't tell you. How come DLLs written in C# do not need that? Well, obviously, there is a difference between the managed DLLs and unmanaged ones, but I'm curious to know, what exactly has changed in the internal structure of those DLLs to make them so different.

Answer 1

Hi,

See http://msdn.microsoft.com/en-us/library/xcd8txaw(v=vs.110).aspx (.NET DLLs have "metadata" information in them).

---

Please always mark whatever response solved your issue so that the thread is properly marked as "Answered".

Answer 2

Thanks, exactly what I was looking for. I have a follow up question. Is that metadata available if I write a C++ DLL in Visual Studio?

Answer 3

Yes all compiled code has metadata, for managed code that area is named  the "Manifest", it tells the loader things like what other things are required at loadtime.  But in addition there is information which at the lowest level is named "Entry points", these are the numeric values/offsets of the compiled code that tell the runtime where to find the code!  It's very low leve and amazing that it all works so well.  Then again, this type of loading has been around since the beginning of compilers.

---

JP Cowboy Coders Unite!

Answer 4

You can read more about The .NET File Format to know how .NET compiler create and write metadata to .DLL and .EXE files

<object height="0" id="plugin0" style=";z-index:1000;" type="application/x-dgnria" width="0"><param name="tabId" value="ff-tab-10" /><param name="counter" value="23" /></object>

---

Any fool can know. The point is to understand.(Albert Einstein)

Answer 5

Thanks, exactly what I was looking for. I have a follow up question. Is that metadata available if I write a C++ DLL in Visual Studio?

Yea then be a good forum member, mark the reply from Patrice as answer. That helps those searching for an answer and then they get not an aswer which is in fact about your follow up question. 

Nobody restrict you to create a new question then for your follow up question, and then others can use that as well.

---

Success
Cor

Answer 6

First, I really want to emphasize that it is a mistake to say "DLL" without specifying what type of DLL. There are very many types of DLLs.

The next thing to mention is "Type Libraries". Prior to managed code, type libaries were used to describe DLLs. An unmanaged COM object has a type library, whether in the DLL or separate from it.

In the Unix environment, before Linux and before Windows, the type of networking that the internet now uses also had something called a Remote Procedure Call (RPC). Look that up. RPCs use an Interface Description Language (IDL). Microsoft used the IDL for its early version of what became COM objects and what they now call type libraries is also their version of a compiled IDL. I am not sure what extent that .Net builds on type libraries but I am sure that .Net uses an improved version of type libraries.

If you use DLLImport then you are using a DLL that is usually called a Native DLL. If you add a reference to a managed application and you do it using the COM tab then the DLL has a type library; that is a certainty.

I very much  doubt that any unmanaged DLL, in other words a native DLL or a COM object DLL, has metadata. I have never seen the term metadata used for those types of DLLs.

The term "managed" is extremely critical. The exe and DLL files created for managed applications are very different. I am not familiar with the format of managed applications very much, but there is a very big difference between managed and unmanaged.

So again, developers should be clear about what type of DLL they are saying.

---

Sam Hobbs
SimpleSamples.Info

Answer 7

Sam makes a good point; take a look at this:

http://en.wikipedia.org/wiki/Portable_Executable  (The PE format has been used since Windows 3.1 and came out of Unix COFF)

From that article we read this:

Microsoft's .NET Framework has extended the PE format with features which support the Common Language Runtime (CLR). Among the additions are a CLR Header and CLR Data section. Upon loading a binary, the OS loader yields execution to the CLR via a reference in the PE/COFF IMPORT table. The CLR then loads the CLR Header and Data sections.

The CLR Data section contains two important segments: Metadata and Intermediate Language (IL) code:

• Metadata contains information relevant to the assembly, including the assembly manifest. A manifest describes the assembly in detail including unique identification (via a hash, version number, etc.), data on exported components, extensive type information (supported by the Common Type System (CTS)), external references, and a list of files within the assembly. The CLR environment makes extensive use of metadata.

Although it doesn't really say it (above), this article (below) implies unmanaged code has no metadata as Sam says:

http://msdn.microsoft.com/en-us/library/ms809762.aspx  (from 1993)  Note that the what is seen in a PE format is more a layout of how the native loader operates, there is no implicit metadata.

Conclusion: Metadata only exists in the "Extended" PE header format in the "MetaData" section for .NET Framework  (See this link)  http://msdn.microsoft.com/en-us/library/8dkk3ek4(v=vs.71).aspx . 

Unmanaged PE headers do not have a MetaData section.

Sam is correct!

---

JP Cowboy Coders Unite!

Answer 8

Thank you, Mr. Javaman II. Thank you for doing the research and for the clarification.

I hope people do not mind me saying that you can call me Simple Samples or you can call me Sam. I think the name Simple Samples is a bad choice of names (my fault) because it is so logical to use the name Simple.

---

Sam Hobbs
SimpleSamples.Info

Answer 9

Unlike JavaMan I would say rather it depends. As told by others, DLL is a general concept (I assumed for know .NET DLLs as you asked about DLLs written using C# in a C# forum). If you have now a question about C++ I would suggest to move to a C++ programming forum. You can write .NET DLLs using C++ in which case metadata are mandatory and you have the whole palette : COM DLLs with optional metadata (just expressed as a C++ source files or this information is compiled and embedded as a type library within or in addition to the compiled DLL) or function exports with no metadata (just expressed as C++ source header files). And Windows 8 still introduces another .NET based metadata format for DLLs...

Not sure if you know which kind of DLL you want to build and knowing also how you'll consume that DLL is likely part of the choice... Try a C++ forum for details.

---

Please always mark whatever response solved your issue so that the thread is properly marked as "Answered".

Answer 10

Just curious Patrice, where would the metadata be found in PE file for C++ or other managed code?

---

JP Cowboy Coders Unite!

Answer 11

As told by others, DLL is a general concept

DLLs are precisely defined. There is a wide variety of types of DLLs but the native format is totally explicit.

You can write .NET DLLs using C++ in which case metadata are mandatory

They are typically called managed DLLs. They use a special version of C++ called C++/CLI as described in .NET Programming in Visual C++. It is possible to mix managed and unmanaged C++, as I describe in Managed C++ Wrapper For Unmanaged Code.

COM DLLs with optional metadata

Not possible. COM does not use metadata. I think Mr. Javaman II posted sufficient evidence of that. If you have any evidence indicating that a COM DLL has metadata then please provide that.

or function exports with no metadata (just expressed as C++ source header files).

Metadata is binary data in a DLL or EXE file. A header file is something that the C++ preprocessor reads prior to the C++ compiler. They are totally different. It is impossible to find any evidence whatsoever of a header file in a compiled image, except for the debugging data.

And Windows 8 still introduces another .NET based metadata format for DLLs...

Yes, Windows 8 introduces Windows Store apps (formerly known as Metro style apps), as described in Windows Store app development. I don't understand the relevance; as far as I know, for the purposes of this discussion, a Windows Store app is a managed application.

---

Sam Hobbs
SimpleSamples.Info

Answer 12

The type library can be embedded in the COM component as a resource (similarly to any other resource).

---

Please always mark whatever response solved your issue so that the thread is properly marked as "Answered".

Answer 13

The type library can be embedded in the COM component as a resource (similarly to any other resource).

Yes. I considered mentioning that detail in my reply but decided not to. There are many more details that I hope others will find when they want more information. The fact that a type library can be embedded in a DLL does make it clear that a type library is critical to making a COM DLL and explains why some DLLs are COM components and others are not. A type library can be embedded in a DLL or it can be a separate file (tlb file).

---

Sam Hobbs
SimpleSamples.Info

Answer 14

Sorry English is not my native language and it seems I badly expressed myself ?

1) I just meant that, as you said yourself there is several kinds of "DLLs" that have not much in common (it doesn't mean that the format of each of those kind of DLLs is not precisely defined). My understanding was first because of the "DLLs in C#" and being in a C# forum, that the question was specifically about "managed" DLLs created using C# not about the various kind of DLLs (whose general concept is to share code) available under Windows...

2) Just meant that metadata are mandatory in .NET Dlls (whatever is used to write them) as the OP seems to ask about metadata in DLLs (my point is that in .NET you can't do otherwise than providing metadata while this is optional for some other DLLs and just impossible for still other kind of DLLs).

3) You don't consider type librairies being metadata ? I do. See http://msdn.microsoft.com/en-us/library/windows/desktop/ms221355(v=vs.85).aspx  Though, this is optional, if available, it provides enough information to start using a COM component you added as a reference right away (if interfaces are suitable for consumption for your language).

4) Read again. I said "function export with NO metadata" (because the needed information is part of the header file, I never said this information was compiled into the final EXE file). The header file plays the same role than the DllImport attribute (i.e. you need to tell inside the consuming code how to use those functions as precisely they don't come with metadata).

5) As I said Windows 8 introduces the "Windows Runtime" that uses yet another metadata format. See http://mariusbancila.ro/blog/2011/10/30/winrt-and-winmd-files/ (this is just an additional DLL to hint as you have done that we have to know about which kind of DLLs we are talking).

---

Please always mark whatever response solved your issue so that the thread is properly marked as "Answered".

Answer 15

See http://msdn.microsoft.com/en-us/library/xcd8txaw(v=vs.110).aspx (.NET DLLs have "metadata" information in them).

Is that everything that BringMeAnother wanted to know? If so then I was foolish for cluttering this thread with my replies.

---

Sam Hobbs
SimpleSamples.Info

Answer 16

My understanding was first because of the "DLLs in C#" and being in a C# forum, that the question was specifically about "managed" DLLs created using C# not about the various kind of DLLs (whose general concept is to share code) available under Windows...

We cannot be sure what BringMeAnother meant to ask; it would help for BringMeAnother to be more involved. If it were me, I would have first requested clarification of the question, since it is not clear. Perhaps BringMeAnother needs to avoid having another until they have a chance to continue in this thread that they started.

You don't consider type librairies being metadata ? I do. See http://msdn.microsoft.com/en-us/library/windows/desktop/ms221355(v=vs.85).aspx

Where does that say anything about metadata? Yes, type libraries are metadata. No, type libraries are not metadata. Microsoft often uses confusing terminology. Type libraries are metadata in the general (dictionary) definition but in this context, the metadata is specific to .Net and is not the same thing as type libraries. So for the purposes of this thread, it is incorrect to say that type libraries are metadata. You will confuse yourself and others if you say, in the context of managed applications, that type libraries are metadata.

The header file plays the same role than the DllImport attribute (i.e. you need to tell inside the consuming code how to use those functions as precisely they don't come with metadata).

Whatever. Header files are used in C++ programs and the DllImport attribute is used for C#. Otherwise, yes, there is not much difference. They are both used for native DLLs but not for COM DLLs and not for .Net Class Libraries.

---

Sam Hobbs
SimpleSamples.Info

Answer 17

Ok if you prefer let's say just say that DLLs can either be self descriptive (either .NET or COM with type library) or not self descriptive (COM without type library or "old" DLLs with no description at all) in which case this description needs to be part of the client application (DllImport etc...).

Metadata is AFAIK an English word, not an MS specific lingo, so I'm not sure why I'm not allowed to explain that "Type Librairies" (and in this case I believe you'll find this expression mostly related to MS COM) contains the metadata needed to consume those COM classes (that is the same goal than for .NET based DLLs)...

A difference I see is that "metadata" perhaps convey the idea that this information is inherently attached to .NET assemblies rather than optional...

As I said, I may missed some English nuance as this is not my native language. Anyway we are far from the OP original question...

---

Please always mark whatever response solved your issue so that the thread is properly marked as "Answered".