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 runtime, 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 C# project types in the “Create a new project” dialog produce a single assembly as their main output. They will often put additional files in the output folder too, such as copies of any assemblies that your project relies on that are not built into the .NET runtime, and other files needed by your application. (For example, ...