Although this concept is not necessarily new, the .NET Framework adopted the concept of a namespace. Think of a namespace as a way to categorize classes so that they are easy to find. For the same reason you use meaningful subdirectory names in a file system rather than keeping all your files in the root, CMS classes are organized into ten meaningful namespaces (generally referred to as PAPI).
The CMS .Publishing namespaces are by far the largest group of classes, referencing nearly every aspect of a CMS site. They are subdivided into the four groups that follow:
Microsoft.ContentManagement.Publishing namespace: This group contains the core classes used to interact with CMS, such as obtaining Context (Chapter 24), traversing channels (Chapter 25), managing postings (Chapter 26), and locating assets (Chapter 28). These and other classes are all accomplished through this namespace.
Microsoft.ContentManagement.Publishing.Events namespace: This group contains classes used for reacting to things that are happening when users are interacting with CMS. Extending the default CMS publishing workflow (Chapter 31) and responding to workflow and events (Chapter 6) are key tasks that can be accomplished using classes in this namespace.
Microsoft.ContentManagement.Publishing.Extensions.Placeholders namespace: This group contains classes used for manipulating placeholder definitions (for placeholder controls see the .WebControls namespace). There are classes for each distinct type of content, including HTML, images, XML, and attachments. Classes specifically for MS Word are found in the final .Publishing namespace.
Microsoft.ContentManagement.Publishing.Extensions.Placeholders.Office namespace: This group contains classes used for manipulating placeholder definitions populated by the Authoring Connector (Chapter 7). There are classes for Office HTML and Office attachments.
The CMS .Web namespaces are automatically used for working with ASP.NET Web applications and are subdivided into the three groups that follow:
Microsoft.ContentManagement.Web namespace: This group contains classes used for ensuring that CMS-enabled Web applications properly release resources, extending the ASP.NET OutputCache directive to support caching by several new VaryByCustom attributes: CmsPosting, CmsControl, CmsRoles, CmsUser, and so on. This namespace is referenced by VS.NET by default and should not be removed unless you intend to handle caching and authentication in a proprietary way.
Microsoft.ContentManagement.Web.Caching namespace: This group contains classes used for registering a cache validation callback for the current posting, not caching unpublished content, and spoiling the cache when changes are made within the CMS server.
Microsoft.ContentManagement.Web.Security namespace: This group contains classes used to ensure that all users are authenticated, for managing both CMS and ASP.NET authentication tickets (cookies).
The CMS .WebControls namespaces automatically manage placeholder controls, helper controls, and console controls. They are subdivided into the three groups that follow:
Microsoft.ContentManagement.WebControls namespace: This group contains classes used for manipulating intrinsic and custom placeholder controls (Chapters 13, 27, and 29), including retrieving saved content and saving new content, and managing authoring, presentation, and error mode containers. This namespace is referenced by VS.NET by default and should not be removed.
Microsoft.ContentManagement.WebControls.Console Controls namespace: This group contains classes used for manipulating and responding to console-specific controls and events, dictating what you want to happen when a posting is published, and automatically naming the creation of a new posting.
Microsoft.ContentManagement.WebControls.Design namespace: This group contains classes used to provide the user interface for design-time editing of PlaceholderToBind property values in VS.NET. CMS uses this class to manage the user interface that you see when you are setting up a placeholder definition. This is the namespace you would override to change the default design-time interface for this editor. This is not a common need.
If you have spent any time working with the .NET Framework, you probably already know about referencing namespaces. Similarly to the way header files in C++ or Project References in legacy VB are handled, VS.NET first needs to be able to find the appropriate DLLs that contain the classes you want to use in your project.
To reference a namespace in a VS.NET project, expand the built-in References folder from the Solution Explorer window, and you will see the DLLs that VS.NET includes in the project by default. PAPI .Publishing, .Web, .WebControls, and many others should be listed. Right-click the built-in References folder and select Add Reference (Add Web Reference is for referencing Web Services) from the pop-up menu (Figure 23-10).
Figure 23-10. Add Reference in VS.NET
A quick browse through the list of .NET assemblies in the resulting Add Reference dialog may still leave you wondering where the CMS DLLs live. Click the Browse button and navigate to the following default installation directory (if CMS is installed in another directory, you will need to use that installation path to find them): C:\Program Files\Microsoft Content Management Server\Server\bin\*.dll (Figure 23-11).
Figure 23-11. Selecting CMS DLLs
Notice that many of the DLLs have exactly the same name and a one-to-one correspondence with their namespace. Nice. Some namespaces have been consolidated into a single DLL. That is OK too. The DLLs that you will most commonly reference are .Common.dll, .Publishing.dll, .Publishing.Extensions.Placeholders.dll, .Web.dll, and .WebControls.dll.
Now that the VS.NET project knows where to find the DLLs that contain the namespaces starting with Microsoft.ContentManagement, we can reference them independently in each of our Web Form (ASPX) and Web Control (ASCX) pages. At the top of the code-behind file for these pages, where we need to use a class from any of the ten namespaces that we discussed earlier, we simply include a statement using that namespace. So, for instance, if we wanted to get the CMS current Context (Figure 23-12), we would include the following statement:
Figure 23-12. Namespaces used in CMS Template