Creating a Manifest
A manifest is an XML file that contains the information required to deploy an application. This file would contain a list of required files and corresponding paths—all the DLLs, XSD, or other files required for a successful SmartDocument solution download and installation. The SmartDocument SDK provides an XSD schema for this file.

The manifest contains a root element that can either be manifest or manifestCollection; the latter describes a collection of the former. For example, the Customermanifest.xml file's root declares the Office 2003 XML namespace within a manifest element. The URI is the namespace for your application, and will be the same URI specified for the XSD. For this sample the URI would be http://Officesamples/Customer/2004.

   <manifest xmlns=
     "http://schemas.microsoft.com/office/
     xmlexpansionpacks/2003">
      <version>1.0</version>
      <updateFrequency>0</updateFrequency>
      <uri>http://Officesamples/Customer/2004</uri>
      <solution>
      ...
   </manifest>

The solution tag contains a definition for your solution—multiple file elements each containing various files needed for deployment. For example:

   <solution>
    <solutionID>
      {E577F726-5EA1-4e68-8AC1-DFCE0C836B5C}</solutionID>
      <type>smartDocument</type>
      <alias lcid="1033">Customer sample template</alias>
      <documentSpecific>false</documentSpecific>
      <targetApplication>
         Word.Application.11</targetApplication>
      <file>
            <type>solutionActionHandler</type>
            <version>1.0</version>
            <CLSID>
               {3D54FCB2-403C-4E48-8740-
               8BFAC93B48D5}</CLSID>
            <filePath>
               D:\My Documents\My Articles\Designing 
              SmartDocument\DocumentShim\DocumentShim.dll
            </filePath>
            <runFromServer/>
         </file>
   </solution>
   <solution>
      <solutionID>schema</solutionID>
      <type>schema</type>
      <alias lcid="1033">Sample Markup</alias>
      <file>
         <type>schema</type>
         <version>1.0</version>
         <filePath>D:\My Documents\My Articles\
            Designing SmartDocument\CustomerManagement\
            Customer.xsd</filePath>
            <runFromServer/>
      </file>
   </solution>
   </manifest>

The type element is critical because it defines the solution's association with Office. For example, solutionActionHandler specifies that this DLL is an ISmartDocument implementation and all the actions for the specified solutionID are handled by this DLL. Some other possible values are actionHandler, recognizer, other, schema, template, etc. Because the file designates the unmanaged Shim DLL as a solutionActionHandler you need to ensure that the corresponding CLSID and filePath are configured correctly in the manifest. Other actions, such as adding registry keys, are also possible within the manifest. In the full downloadable manifest file you'll see another type configured as other that refers to the managed DLL.

It's also important to configure the "schema" as shown in the last section of the manifest. This will be a schema file that contains the customized markup language for the solution. Refer to the MSDN/SmartDocument SDK to find an overview of the various options available while configuring the file and solution elements.

SmartDocuments are really a highly programmable way to gather information that can help you avoid the "scattered data islands" problem. They provide context-sensitive lookups and support for selective content authoring. You can extend your authoring templates to use customized Research panes that can further enrich the user experience. You can configure most of the SmartNode handling using XML configuration files. In real-world applications you should move any hard-coded file paths to the registry or to configuration files.

SmartDocuments do have some disadvantages. As the number of XMLType registered for document actions increase, the response time for rendering the task pane becomes an issue. In the future, perhaps Microsoft will release a managed API that will help leverage the advantages of .NET-based Office development, but unfortunately that's not available yet.