Another useful tool for optimizing cold startup is Microsoft’s free CLR Profiler 2.0. While this tool has the aesthetics of a wadded-up paper sack, it does have the ability to graph each assembly that gets loaded, and the method that caused it to be loaded. This makes it easier to figure out why a particular assembly got loaded, allowing you to consider whether there might be a way to avoid loading it or postpone loading it until some less critical moment.

To generate the assembly graph, click the Start Application button in the profiler. It lets you browse to the executable, which it will then launch. When you close the application, the profiler displays a summary screen with a bunch of information about the managed heap and garbage collection. You can close that window. Instead, go to the main menu and pick View > Assembly Graph. You’ll see something like this:

Assembly Graph Window (click for larger image)

At the far left edge of the graph, you can see the total number of assemblies (30) that were loaded during the application run. The edges from there represent method calls that caused other assemblies to load. Underneath the method name is the total number assemblies loaded through the full call stack. As you move to the far right side of the graph, you eventually see each individual assembly that is loaded. If you click on a node in the graph it sort of highlights (is plaid technically a highlight color?) the edges in and out of the node. That can be really handy when the graph lines criss-cross over each other.

In my case, where I’m writing a Word add-in, I have some initialization that must happen on the main thread at startup. Other initialization is put on a low priority background thread, which allows Word to start up quickly while continuing to load up the add-in functionality for when it will be used. To get a better picture of startup, I commented out the background thread. Then I looked for call paths that loaded lots of assemblies to figure out if any of those could be deferred to the background thread.

I found that making an XML-RPC call was pretty expensive in terms of code loading. The RPC call itself was pretty fast — just talking to another process on the same machine, but it took loading classes from five additional assemblies just to make the call, which hurts cold startup performance. At this point we’re trying to figure out if the current performance is acceptable or if we need to tweak the add-in’s behavior a little to delay the RPC call to the background thread. 

After reproducing the problem a few times, I knew I needed an automated test for this:

[TestMethod]
[Description("Files initially without custom properties can be opened in Word after stamping.")]
[Timeout(20000)]
public void CanOpenStamped()
{
 string testFile = testData.GetFile("NoCustom.docx");
 using (Stream s = new FileStream(testFile, FileMode.Open, FileAccess.ReadWrite))
 {
 	IStampable stampable = handler.GetStampable(s);
 	stampable.StampNew(Identifier.Generate(), "test server");
 }	
 
 Word.Application wordApp = null;
 Word.Document wordDoc = null;
try
 {
  wordApp = new Word.Application();
  object fileName = testFile;
 
  // This will throw if there is an error on open:
  wordDoc = wordApp.Documents.Open(ref fileName, ref missing, ref missing, ref missing,
 		ref missing,ref missing, ref missing, ref missing, ref missing, ref missing, ref missing,
 		ref missing, ref missing, ref missing, ref missing);
 }
 finally
 {
  if (wordDoc != null)
  {
    Marshal.ReleaseComObject(wordDoc);
  }
 
  if (wordApp != null)
  {
    ((Word._Application)wordApp).Quit(ref missing, ref missing, ref missing);
    Marshal.ReleaseComObject(wordApp);
  }
 }
}

I tried to see if there was any kind of validation tools for OOXML files, but didn’t find anything too helpful. One person said, “If it opens in Word, it’s valid.” OK, so what if it isn’t valid? How do I figure it out? There was also a WPML validator, but it was failing on documents created by Word.

I resorted to creating a bad document (using my code) and making a copy and opening it in Word 2007. Word offered to fix the document, so I then had a bad and good version of the document that I could extract and do diffs on. At first, all I was finding were differences that should be irrelevant based solely on XML syntax, or minor things that I honestly didn’t know whether they mattered.

Ultimately, I discovered that there was a difference in the [ContentTypes].xml file. The good version had:

<Override PartName="/docProps/custom.xml" ContentType="application/vnd.openxmlformats-officedocument.custom-properties+xml"/>

The bad version didn’t have such an override. This led me to the code where I created the custom properties part. Changing the specified content type from “application/xml” to the content type above fixed the problem. The test passes and hopefully all is now well.

• You can search by class name (e.g. “OpusApp” for Word), but what if you somehow have multiple Word processes running? Which window do you get?
• You can search by window text, but it can be really hard to figure out what the window text is.
• You can set the Caption property on the Application object to some magic text and search for a window with the magic text, but Word throws all kinds of other stuff into the caption so this generally doesn’t work reliably.

Instead, if you’re using managed code, you can just do this:

IntPtr hwnd = Process.GetCurrentProcess().MainWindowHandle;

Underneath this uses EnumWindows and GetWindowThreadProcessId to find the right window.

The trouble with Paste Special is that it (a) doesn’t have a keyboard shortcut and (b) brings up a dialog that has to be dealt with when all I really want is to paste as “Unformatted Text”.

My wife is currently a “Knowledge Bowl” coach, and one of her jobs is to put together a study guide of science vocabulary. That involves a lot of copying from various sources and pasting into the study guide (which is a Word document), and finally drove me to come up with a solution. I found something similar to the following very short macro at http://swest.wordpress.com/2006/01/15/ms-word-paste-plain-text/:

Sub PasteSpecialUnformatted()
Selection.PasteAndFormat (wdFormatPlainText)
End Sub

You can add this to Normal.dot by clicking the Macros button on Word 2007′s View tab.

Then I customized Word to bind the macro to Ctrl+Shift+V. In Word 2007, you do this by clicking the Office Menu, then Word Options, select the Customize category, click the Customize… button by Keyboard shortucts, which finally brings up the Customize Keyboard dialog. Pick Macros from the Categories list to see the macro, then you can associate a new shortcut key.

Temporary

Optional Object. True to make the new control temporary. Temporary controls are automatically deleted when the container application is closed. The default value is False.

This looks perfect. You can add the customizations at startup, and they’ll be gone at shutdown… except that it doesn’t work in Word.

There is a support article that acknowledges this, but it is not a bug in Word. Instead, as I read the article, it is functionality not deemed worthy of Word, given its vastly superior customization capabilities.

By default, Word adds any customizations to the Normal.dot template, which causes a couple of problems:

1. Those customizations are persistent, so the goal of having the customizations go away is foiled.
2. You tend to get these confusing prompts where the user is asked whether to save changes to Normal.dot, when most users don’t have a clue what Normal.dot even is.

I’ve tried a few different approaches to get the temporary functionality in Word similar to how it is documented (and implemented by other Office applications like Excel and PowerPoint). One approach is to add all the customizations at add-in startup, and (since the temporary flag doesn’t do it for you) remove them all again at add-in shutdown. This mostly works, but you have to be kind of careful. If the application crashed for some reason, missing the add-in shutdown step, you need to check for your customizations before adding them again or you’ll get duplicates. Also, Normal.dot needs saving every time the application exits. It’s not a huge problem — the little progress bar goes pretty fast — but it is slightly annoying.

Among several others that I tried, the approach that I finally settled on takes advantage of the Word application object’s CustomizationContext property, which lets you send CommandBar customizations to a template other than Normal.dot.

Here are the basic steps:

1. Embed an empty Word document template (.dot file) as a resource in the add-in. Maybe there’s a way to create a .dot programmatically from scratch, but embedding an already created one is pretty easy.
2. On start-up, if the template isn’t already on disk, extract the resource to disk in the user’s template directory (which is retrievable from the Options object using wdUserTemplatesPath).
3. Load the template by adding it to the application’s AddIns collection.
4. Before doing CommandBar customizations, set the CustomizationContext to be this template.
5. After doing customizations, set the Saved property of the template to true.

The last step is the key. Since Word thinks that the template isn’t dirty, it doesn’t save it, and any customizations it contained will be automatically discarded when the application exits. If your add-in doesn’t get loaded ever again, the customization template will never be loaded, and would be empty even if it was.

I’ve found this approach to be simple; you don’t have to check for existing customizations at startup or remove anything at shutdown. No templates need to be saved, and I stopped getting random bug reports of lingering customizations or Normal.dot save prompts.

NextPage has been involved in the standardization process for Open XML, with our very own Tom Ngo serving on the Ecma committee. Doug, at a post-training session dinner (thanks Erick!) had only good things to say about Tom. He said that he wished Tom could be at all the committee meetings because he’s able to reason from neutral ground, whereas a Microsoft representative saying the same things would immediately be treated with skepticism and mistrust.

The training focused mainly on document generation independent of Office applications. This included some general XML programming with .NET and using the System.IO.Packaging API included in .NET 3.0, which I had heard of but had never seen used. The packaging API give a little higher level of abstraction than just working with the raw ZIP and XML. I also learned that there is yet another API in the works that is at an even higher level of abstraction. It is currently in CTP form, and Doug indicated that the developers would really like feedback on it. Chris also showed using XSLT to generate documents from templates.

Aside from general understanding of our implementation domain, we’re not extremely interested in document generation at NextPage. Our efforts are more toward tracking documents that others create. There may be opportunities to store our tracking metadata as a custom XML part, whereas we currently mash some XML into the structured storage custom properties for the previous binary format.

Something that made the training experience unique was that it was all professionally videotaped. I don’t just mean that there was a camcorder running in the back of the room. They had multiple cameras, extensive lighting, a control room, and lots of other stuff completely lost on me as a TV production ignoramus.

Doug’s blog has a photo showing all the extra lighting added for the cameras. That’s the back of my balding head in the front row, second from the right. I’ve always heard that the best students sit toward the front to the side, so I was looking for someone up there to copy off of. I’m hoping there isn’t much footage of me nodding off, what with the late-night travel to get there and the limited personal relevance of some of the material.

The film crew also did interviews with the various attendees of the training, which I agreed to participate in mostly for the interesting experience of being formally interviewed on camera. My willingness was nearly offset by my fear that I would say something incredibly stupid. I’m fairly sure that I said stuff at least moderately stupid. This is why I prefer writing a blog instead of doing some sort of podcast. Hopefully the producer will have a goal of making the attendees appear insightful and articulate and omit my interview altogether.

Here is the XML:

<!-- version="1.0" encoding="utf-8--> 
<customui xmlns="http://schemas.microsoft.com/office/2006/01/customui"></customui> 
  <ribbon></ribbon> 
    <officemenu></officemenu> 
      <splitbutton idMso="FileSaveAsMenu"></splitbutton> 
        <menu idMso="FileSaveAsMenu"> 
 
          <button id="MyCustomButton"></button>              label="My Custom Command" 
              description="This text shows up under the label" 
              imageMso="HappyFace" 
              onAction="ControlClicked"/> 
 
        </menu>

The odd part, in my inexperienced view, is referencing the same “FileSaveAsMenu” id in both the splitButton and the menu elements.

I searched in vain for an XML file that contains the definition of the complete default ribbon. Having that would have made this and other customizations much easier. A similar strategy ought to work for other pop-up style items, like Print, Prepare, Send, etc.