Office 2003 Smart Document Software Development Kit
Best Practices

Click the following topic links for information about best practices for smart document development, testing (including security and privacy issues), and deployment.

Development

  • Always use the runFromServer element during development and testing.
  • After you make changes to the smart document code, delete the XML expansion pack, reboot the host application, and then re-add the XML expansion pack. Alternatively, change the version number for the smart document solution in the XML expansion pack manifest file every time the code is updated, and then delete and re-add the XML expansion pack.
  • For smart document projects developed in Microsoft® Visual Basic® 6.0, use the project compatibility setting.
  • If at all possible, keep all smart document code inside a single dynamic-link library (DLL) file. Do not modularize a smart document by creating multiple DLLs with solution code.
  • If you are creating a managed smart document, be sure that you use the primary interop assembly that is included with Microsoft Office   2003 rather than the interop assembly that Microsoft Visual Studio® creates. If you use the interop assembly instead of the primary interop assembly, the primary interop assemblies will become unregistered on your users' computers and may break other managed solutions and add-ins that your users may have installed.
  • Always use error handling in your code so that you can more easily troubleshoot and resolve coding errors.
  • Do not use the default template of the host application (Normal.dot for Microsoft Office Word   2003 or Book.xlt for Microsoft Office Excel   2003) as a smart document. The XML expansion pack will not be automatically attached to a new document, because a smart document relies on the Solution ID and Solution URL custom properties, which are not inherited by any documents created by using the default template.
  • Always specify a ControlID value that allows you to add additional controls. For more information, see the ControlID property.
  • Always use a unique namespace and class name for your smart document projects. Because Office uses these values when it saves your projects on the user's machine, using similar namespace and class name values may cause multiple XML expansion packs to overwrite each other when they are installed.
Security and Privacy

  • Digitally sign all code components included in a smart document solution. This includes the smart document DLL, documents with macros, add-ins that are part of the solution, as well as the XML expansion pack.

    If the smart document DLL is written in managed code, use a strong name and sign it with an Authenticode® certificate.

  • If your organization has a firewall, you should use a local distribution point within the firewall from which to distribute your smart documents. This lessens the possibility of network attack and reduces the number of sites your users need to trust.
  • Microsoft Office   2003 designed the ability to temporarily disable the XML expansion pack security check only for use within a development and testing environment. You should never disable XML expansion pack security checking on your users' computers.
  • Always take advantage of the Visual Studio Tools for the Microsoft Office System loader when creating managed smart document solutions. The Visual Studio Tools for the Microsoft Office System loader leverage the Microsoft .NET Framework security model and as such, among other things, can take advantage of trust decisions other than those involving certificates.
  • If you are including add-ins written in managed code in your smart document solutions, use a Component Object Model (COM) wrapper to load the add-in. This way you can deploy it securely by digitally signing the DLL for the COM wrapper, allowing it to act as a proxy to the managed add-in. In addition, users can maintain their Office security setting at its highest.
  • Use built-in Office security for testing COM smart documents.
  • To ease development, while maintaining a secure development and testing environment, we recommend that developers use location-based evidence. Developers can also delay sign their assemblies. This allows testing to be done on assemblies that need to be strong named, with the actual signing performed later when development is completed.
  • Take measures to ensure that private information about the employees who develop and work on smart documents and network paths included in smart documents is not sent to people who are outside your organization. This will help to minimize potential security risks to both your employees and your corporate network.

For more information about security, read the article The Ten Immutable Laws of Security on the Microsoft TechNet Web site, and regularly visit TechNet and MSDN®, the Microsoft Developer Network Web site, for updates and security information.

Deployment

  • Whenever you update your XML expansion pack manifest file, you should always update the version number in the version element. Failure to do this may result in the inability to load the XML expansion pack and receipt of the "XML expansion logic is missing or invalid" error message. For more information about this and other error messages, see Error Messages.
  • Use a manifest collection when deploying your smart documents within an organization. For more information see, Understanding Manifest Collections.
  • Use a globally unique identifier (GUID) for the solutionID element.
  • Use an asterisk (*) for the lcid element.
  • Use a unique value for the CLSNAME element.
  • If you are deploying a smart document without a manifest, use the remote key to cause smart document files to be deleted during an uninstall of the smart document rather than when the user clicks Delete in the XML Expansion Packs dialog box.
  • Avoid using the runFromServer element when you deploy a smart document, because this prevents users from using the smart document when they are not connected to the network. In addition, there are performance implications related to using smart document DLL files that are stored on a server.
  • When creating your manifest, you should put all the file references for a single smart document within the same solution element, with the exception of the schema (.XSD) file reference for your smart document, which must always reside within its own solution element.


Page view tracker