So far in this book, I’ve used the term component
to describe either a library or an executable. It’s now time to look more
closely at exactly what that means. In .NET the proper term for a software
component is an assembly, and it is typically a
.dll or .exe file. Occasionally, an assembly will be
split into multiple files, but even then it is an indivisible unit of
deployment—you must either make the whole assembly available to the CLR, or
not deploy it at all. Assemblies are an important aspect of the type system,
because each type is identified not just by its name and namespace, but also
by its containing assembly. Assemblies provide a kind of encapsulation that
operates at a larger scale than individual types, thanks to the
internal accessibility specifier, which works at
the assembly level.
The runtime provides an assembly loader, which automatically finds and loads the assemblies a program needs. To ensure that the loader can find the right components, assemblies have structured names that include version information, and they can optionally contain a globally unique element to prevent ambiguity.
In Visual Studio, most of the project types under Visual C# in the New Project dialog produce a single assembly as their output. They will often put other files in the output folder too, such as copies of assemblies from outside of the .NET Framework class library that your project relies on, and other files needed by your application. ...