Assemblies are the smallest units of versioning and deployment in the .NET application. Assemblies are also the building blocks for programs such as Web services, Windows services, serviced components and .NET remoting applications.
.NET applications use two different types of assemblies : private assemblies and shared assemblies . Private assemblies are identified by their name and are deployed for the use of only a single application. Shared assemblies are identified by a strong name (a type of digital identity that I'll discuss later in this chapter) and are deployed for use by multiple applications. A strong name uses four attributes to identify an assembly ‚ the name of the assembly, its version number, its culture identity, and a public key token.
An assembly might also refer to classes present in other assemblies. When an assembly is built, information about all other assemblies that it refers to is stored in the assembly manifest . The manifest however, does not store the exact path of the assembly because this path might differ on the computer where the assembly is deployed. At runtime, when a class is referenced, the CLR reads the assembly manifest, retrieves the identification information for the referenced assembly, and then attempts to locate the referenced assembly. The mechanism used by the CLR to locate a private assembly is different from that used for a shared assembly.
The set of rules that the CLR uses to locate an assembly is called binding policy . Binding policy is a deciding factor in how and where the assemblies of an application should be deployed. In a successfully deployed application, the CLR should be able to bind to all the referenced assemblies. In other words, for a successful deployment you need to deploy your assemblies at locations where the CLR expects to find them. In the first part of this chapter, you will learn how to work with private and shared assemblies and how to deploy them successfully.
After you have identified the assemblies that need to be deployed and identified where the assemblies need to be deployed, you need to find an effective way to package and distribute your application. That's what you'll study in the later part of this chapter. You will learn how to deploy a Web service, a Windows service, a serviced component, and a .NET remoting object.
The .NET Framework greatly simplifies various deployment tasks . In fact, just copying the files to the target computer can easily deploy some simple applications. For advanced deployment options and requirements, however, you will probably want to create a Windows Installer-based setup project. In this chapter, you'll also learn how to use Visual Studio .NET setup and deployment projects to create Windows Installer-based setup packages for deploying the given applications.
Setup Alternatives In addition to the built-in support for Windows Installer packages in Visual Studio .NET, there are also commercial setup authoring tools from companies such as InstallShield and Wise Solutions. Although those tools aren't covered on the exam or discussed in this book, they provide additional flexibility that might be helpful when you're working with very complex applications.