I haven't talked much about what I do here at Microsoft.  To be honest I'm not going to go too far into any details about what I am doing but I think it'll be okay to talk about what I did do (up until we shipped VSTO 2008).

I am and SDET which basically means I test the product.  Really I spend a lot of time trying to make the product better.  Sometimes I'm testing the product and sometimes I'm doing other things (such as reviewing documentation).  But it also means I tend to spend a lot of time "thinking like a customer".  That is, I make a great deal of effort to do things and see things from the perspective of an outsider.  An example is that I often try to find things out via our external communication methods before I go and ask someone here who actually built the thing I'm trying to use.  So we’re back to what I was talking about in the post title...  I always have a hard time finding the articles (many that I know exist) about the product features I'm working with.  I'm always looking for that special something.  After talking with one of our insiders who works on MSDN I learned an interesting piece of advice when searching for VSTO related articles:

Start with Visual Studio Tools for Office or Visual Studio Tools for the Office System avoid using VSTO when searching for MSDN articles.

My biggest mistake is that I often start with VSTO.  I believe it's a product of working on VSTO so completely that I often get searches that look like this:

When really what I want are searches that look like this:

You'll notice that the highlighted Article from the first Search is much lower than the one from the second search.  Another particular thing about this is that you'll get more relavant hits this way  (all of the ones listed in the second search image are very relevant articles). 

Certainly I feel this was a hugely helpful thing to know, and I hope it helps you reduce your knowledge searching times also.

Now to completely switch gears....

There have been questions (there always are questions, I like questions, feel free to send me your relevant questions) around how to change the friendly name of a VSTO customization and how to change the name that gets displayed in the Add/Remove Programs dialog. 

To be honest, there currently isn't UI to set either of these directly, however both of these values are created by using the Assembly name (the Main VSTO customization Assembly).  You can set the Assembly name in the VSTO Project Properties (Right Clicking the Project).

The limitations imposed by the file system are evaluated against this value so you should be okay with whatever value VS lets you put here.  There is a minor Caveat though.  If you use spaces in the name you have to use a cannonicalized URI for the file path.  Example:  my I publish "My Project" to C:\foo.  to install the customization with VSTOInstaller (using the command line) I would have to use the following command:

"C:\Program Files\Common Files\Microsoft Shared\VSTO\9.0\VSTOInstaller.exe" /i file:///C:\foo\My%20Project.vsto

The need to use URI's occurs for any case in which the path to the deployment manifest uses spaces.  For most user scenarios this is a complete non-issue since (I believe) most users will be using the bootstrapper or the Shell Handler (Clicking the .vsto files) to install VSTO customizations.  In both of these scenarios the Mechanisms that eventually call into VSTOInstaller are using properly cannonicalized URI's.  The main cases this might be a problem is when the developer has created a custom bootstrapper that calls VSTOInstaller in order to kick off the customization installation.

So the lesson is:  If you're going to build custom bootstrappers that use VSTO ClickOnce installation, use URI's.

I think that will be all I cover today.  Feel free to contact me with question or to post them directly to the relate entry.

Thank you for reading.

Kris