Someone asked in MicrosoftIncompatibleDependencySuite what a DotNetAssembly is, how it is different from the registry, and how it gets rid of DllHell. The DotNetAssembly is metadata that travels with the application and is in the directory that conatins the application. The metadata consists of

	1. Description of a GranuleOfDeployment (called an DotNetAssembly)

		* Name, version, culture
		* A public key for verification
		* Types exported by the assembly
		* Dependencies - other assemblies which this assembly depends on
		* Security permissions needed to run

This metadata is one of the ways that the CommonLanguageRuntime can support a wide variety of languages and tools. Some of the possible tool consumers of the metadata are designers, debuggers, profilers, Proxy Generators, Other Compilers (to find out how to use a component in their language), type/object browsers, and Schema generators.

So the unit of deployment is a DotNetAssembly. It can consist of one or more files and is self-describing. It contains a manifest which holds the metadata I have described above describing everything exported from the assembly, and what's needed to deploy and run a DotNetAssembly. 

A DotNetAssembly has its own version. Assemblies are combined to form Applications. An Application has one or more dotNet Assemblies and also may contain application-specific files or data. DotNet applications ''can'' install simply copying the files described above to a directory and run. '''No registry, no component registration.'''

----

The above description may be so complete that it confuses people or makes things sound more complicated than they are.  In the real world, there is usually a one-to-one correspondence between an assembly and a single DLL or EXE.  The code, metadata, and manifest are usually all in the same file.

Knowing that the parts can be split apart in various ways may be useful, but it is not too much of an oversimplification to say that a .NET assembly is basically a DLL/EXE that contains .NET code and metadata.

----

So it's like the JAR manifest and the WAR/EAR deployment descriptor for Java applications.  Is it in a nice standard format, like XML?

''Yes.''

----

Is it a brand new source of bugs like all metadata?

''Yes.''

This is a rather silly attempt at bashing .NET.  Any part of a system can be a source of defects, whether it is code, data, hardware or the user.  Automatically-generated metadata in a standardized format is almost always less defect-prone than the hand-rolled alternatives many systems rely upon.  The most metadata-rich programming platforms available include Smalltalk and Lisp--does the existence of metadata make those platforms buggy?