Debug and Conquer!

Tags: .NET, Office

A few tips to keep in mind when developing and debugging a Smart Document using C# (and probably VB.NET too).
(For my own selfish ease-of-use, I will refer to Word exclusively here. All these steps should apply to Excel equally).

  1. When building the Smart Doc's Manifest.xml, make sure to include the <runFromServer/> tag for both the solution DLL and the schema.. This makes sure Word doesn't copy the DLL and such to the current user's profile, and thus uses the same DLL that Visual Studio is debugging.
  2. Create an empty document and attach it to the schema and the expansion pack. Then save it somewhere.
  3. In the Project Properties -> Configuration Properties -> Debugging -> Start Action, set Winword.exe as your default application to run when debugging. Pass the name and path of the document from section #2 in the Command Line Arguments field. That way we always launch Word when debugging, and don't have to mess with attaching to process and so on.
  4. In the Post Build Event for the project, add the following line:
    C:\Windows\Microsoft.NET\Framework\v1.1.4322\gacutil.exe /cdl
    (You might need to replace C:\Windows with C:\WINNT for Windows 2000. Also replace with the version of the framework you're using).
    This command clears the Download Cache. If we don't run it, Word will use an older, cached copy of the DLL.
    Note: If Word is running, this command will fail. Don't forget to close Word.
  5. Once we're in Word and debugging and all, it's best to manually close the document rather than just brutally stopping the debugging session. Otherwise we'll get all those “Word recovered your document from the sudden crash, do you want to restore it?“ questions and taskpanes and all popping up. Best to spare yourself the aggravation and close it politely yourself.

Those should get us started. Now to fight with ActiveX controls...

 

No Comments