There are many resources to learn about Visual Studio Tools for Office, and they are scattered through blogdom and even the MSDN Library. In my one year on this team, I've collected various helpful links that I share here.
The Visual Studio Tools for the Office System (3.0) whitepapers written by subjet matter expert like MVPs in the Microsoft Office Development section of the MSDN Library. These complement the Visual Studio Tools for Office documentation.
Several VSTO team members share their expertise on their own blogs. Misha discusses how to use an unofficial feature of Microsoft Office to deploy to alll users in Deploying your VSTO Add-In to All Users (Part I) and Deploying your VSTO Add-In to All Users (Part II). Andrew explains Why is VS development is not supported with multiple versions of Office? TQ details Why there is a separate VSTO runtime apart from the .NET Framework and Microsoft Office. Kris compares the VS2005 and VS2008 VSTO security models in The passphrase is "Install already": A new look at VSTO Security.
- Mary Lee, programming writer.
A lot of VBA developers tell me that they love VBA solutions because there is no deployment necessary. All the code lives inside the document itself, so all you need to do is get the document (in e-mail or on SharePoint) and you have everything you need to get the job done. Then there are some really cool things you can only do with VSTO that you can't do with VBA, such as programming with LINQ, building Action Panes, using WPF controls, and the overall fun of .NET programming. So I'm frequently asked how to get a similar e-mail or SharePoint scenario with a VSTO solution.
Here is one way of accomplishing the e-mail deployment scenario. You develop an Word document solution (or an Excel, or a template solution). You publish it to a server where users can copy the document for use. Jody from human resources copies the document to his local machine and makes some edits to the document, adds some text, and uses VSTO features such as an Actions Pane to retrieve information from PeopleSoft or some other line of business system. Then Jody sends the document to Abby using an e-mail attachment. Abby saves the document to her local drive, opens the document and adds information about her department to the document using both features of Word and features from the VSTO solution. At no point does Jody or Abby run a setup.exe. They just send the document around like they always did. This blog post will try to explain how you can accomplish this scenario. Some pre-requisites to this scenario are:
You can use Visual Studio 2008 to Publish your solution to a server or web site. You should choose a web site where all of the people in your workgroup have access. Let's use the fictitious server location \\HRServer\apps\. In Visual Studio 2008, on the Project menu click <ProjectName> Properties, and then click the Publish tab. Enter the server path or web site in both the Publish location and Install location as seen here:
What do these settings mean? The first path determines where Visual Studio will try to copy all of the deployment files when you click the Publish Now button. The person who pushes the Publish Now button needs to have permissions to write to the target directory. The second path, Installation Folder URL, determines the string that gets written to the MySolution.vsto file. Try this yourself and then look at the *.vsto file in Notepad or an XML editor to see where your URL gets stored. Make sure not to permanently associate the .vsto file extension with Notepad.exe.
To test your deployment, it is better to not use your development computer. Your computer likely has a version of the solution already deployed from when you ran the solution in the Visual Studio debugger. I strongly recommend that you use another computer, or a Virtual PC image to test your deployment.
You will need to install Microsoft Office, the Office primary interop assemblies, the .NET Framework 3.5 and the VSTO 3.0 Runtime on the test computer. Now you can send e-mail or copy your document from the server (in this example \\HRServer\apps\mydoc.docx) to your local computer. If you try to open the document directly from Outlook, then you will get an error because Outlook's temporary files location is not a trusted location. Because it is not a trusted location, the Runtime won't try to load the assembly and the user won't even get a prompt to install the assembly. Instead, the user should Save the document to a trusted location, such as in My Documents. When the document is opened from a trusted location such as on your own hard drive or from a trusted server, then everything should work.
When you open the document, the VSTO runtime will look inside your docx file and find the path to the server. If you are using the Open XML file format, then you can see exactly where this information is written by renaming your file to *.zip, then opening it to see all the folders hidden inside. You should see a folder called vstoDataStore, and another folder called docProps, and a few others. The interesting stuff is inside docProps\custom.xml you'll find the string that shows the full path to your assembly on the server. The interesting node inside of custom.xml will look something like this:
<property fmtid="{D5CDD505-2E9C-101B-9397-08002B2CF9AE}" pid="2" name="_AssemblyLocation"> <vt:lpwstr>file://HRServer/apps/MySolution.vsto|dc6c4da9-ed2d-45d0-83e2-4b3fa4545705</vt:lpwstr> </property>
<property fmtid="{D5CDD505-2E9C-101B-9397-08002B2CF9AE}" pid="2" name="_AssemblyLocation">
<vt:lpwstr>file://HRServer/apps/MySolution.vsto|dc6c4da9-ed2d-45d0-83e2-4b3fa4545705</vt:lpwstr>
</property>
Next you can remove the test computer from the network and try to open the document again. The solution continues to work because the assembly has been installed on the user's computer! You can look in Control Panel in Add/Remove Programs to see your assembly listed. You have now successfully deployed a solution via e-mail! Does this feel insecure? Well, if you did not use a Certificate to sign your solution, then every user will get prompted with a warning that the assembly is from an Unknown Publisher. That will scare them! We recommend that you get Certificates from your IT department or from an independent Certificate Authority.
If you are unable to use a real certificate, we recommend against creating a temporary certificate. Instead you can create an inclusion list entry to automatically grant trust to your VSTO solution by saving the certification information and the network location of the assembly’s deployment manifest. For more information, see Trusting Office Solutions by Using Inclusion Lists (2007 System).
The information in this blog entry is meant to complement the existing documentation for Visual Studio 2008. Please leave a comment to let us know if this blog entry is useful or let us know if there is an error in the text. Thank you!
-Christin Boyd, Program Manager
Although VSTO provides many features that help simplify Office development (especially UI development), nearly every VSTO solution needs to dip into the underlying Office object model to get some work done. Because information about using the Office object models can be spread out in many different places, I thought it might help some readers who are just getting started with Office development using VSTO to talk about a Word object model question that came across my desk recently.
A developer on an internal alias inside Microsoft asked about the best way to programmatically show the Insert Picture dialog box in a Word add-in, and how to perform some logic based upon the full name of the picture that the user selects. The developer had no trouble displaying this dialog box, but couldn't figure out how to get the file name of the chosen picture.
As the developer noticed, displaying the Insert Picture dialog box (or any built-in Word dialog box, for that matter), is pretty straightforward. The trickiest part is determining which WdWordDialog enum value to pass as an index to the ThisAddIn.Application.Dialogs property in the VSTO project. By referring to the VBA documentation for the WdWordDialog enum at http://msdn2.microsoft.com/en-us/library/bb214033.aspx and scanning through the list of values for something that matches the name of the Insert Picture dialog box, you will eventually find the value wdDialogInsertPicture.
So, the code to display this dialog box looks like:
'VB
Dim dialogBox As Word.Dialog = Globals.ThisAddIn.Application.Dialogs(Word.WdWordDialog.wdDialogInsertPicture)
dialogBox.Show()
// C#
Word.Dialog dialogBox = Globals.ThisAddIn.Application.Dialogs[Word.WdWordDialog.wdDialogInsertPicture];
dialogBox.Show();
The Dialog object (reference topic at http://msdn2.microsoft.com/en-us/library/bb211882.aspx) doesn't provide much help. A quick look through its members doesn't show anything obviously useful or pertinent, like a "FileName" property anything like that. However, the reference topic for the WdWordDialog enum (http://msdn2.microsoft.com/en-us/library/bb214033.aspx) says something interesting (emphasis mine):
"Indicates the Microsoft Office Word dialog boxes with which you can work and specifies arguments, if applicable, that you can use to get or set values in a dialog box."
This helps. So, for each WdWordDialog enum value, the table in this topic specifies the properties you can use to get or set information in the dialog box. For wdDialogInsertPicture, there are Name, LinkToFile, New, and FloatOverText properties. Of these, Name looks the most promising. So, how do we use the Name property if the Dialog class doesn't have this property?
The answer, as is often the case when using the Office object models, is late binding. The Name property is accessible only as a late-bound property, so the way that you use it in a VSTO project depends on the type of project you are developing:
If you're using VB with Option Strict set to Off, then you can use the following relatively simple code, which relies on late binding to access the Name property on the Dialog object at run time. After the Insert Picture dialog box is displayed, if the user selects a picture file and clicks Insert, then this code gets the full path of the selected file and displays the path in a message box:
Dim DialogResultOK As Integer = -1
With Globals.ThisAddIn.Application.Dialogs(Word.WdWordDialog.wdDialogInsertPicture)
If .Show() = DialogResultOK Then
System.Windows.Forms.MessageBox.Show("The name of the inserted picture is: " & .Name)
End If
End With
If you're using C# or Visual Basic with Option Strict set to On, you'll have use reflection:
System.Type dialogType = typeof(Word.Dialog);
int DialogResultOK = -1;
if (dialogBox.Show(ref missing) == DialogResultOK)
{
string pictureName = (string)dialogType.InvokeMember("Name", System.Reflection.BindingFlags.GetProperty |
System.Reflection.BindingFlags.Public | System.Reflection.BindingFlags.Instance, null, dialogBox, null);
System.Windows.Forms.MessageBox.Show("The name of the inserted picture is: " + pictureName);
}
This is one of those areas where the late-bound features of Visual Basic help make it a natural fit for Office programming. Granted, anything you can do in Visual Basic in terms of Office development is possible in C#, but it just isn't always as straightforward or elegant.
Some of you reading this might be wondering if they have to go digging around in the VBA reference documentation every time they need to figure out how to do something with the Office object models in VSTO. Not always - the VSTO documentation provides a set of "how to" topics with code examples for some of the most common programming tasks using the Excel and Word object models (see the topics under http://msdn2.microsoft.com/en-us/library/kw65a0we.aspx for Word and http://msdn2.microsoft.com/en-us/library/bb386293.aspx for Excel). In fact, most of the information in this post is covered in the topic "How to: Use Built-In Dialog Boxes in Word" at http://msdn2.microsoft.com/en-us/library/ahzbkf8e.aspx.
When you deploy your VSTO solution, you must package the following prerequisites for your end users: .NET Framework, the VSTO runtime, and the Microsoft Office primary interop assemblies (PIAs).
Visual Studio Tools for Office in Visual Studio 2008 offers a ClickOnce experience only for the 2007 Microsoft Office system, and the publish step creates a setup.exe that includes most prerequisites: Windows Installer 3.1, .NET Framework 3.5, and the Visual Studio Tools for Office 3.0 runtime. However you need to install the PIAs separately, because the end user must accept the Microsoft Software License Terms individually.
For developers targeting Microsoft Office 2003, you must still use a setup project to distribute your solution, include prerequisites (.NET Framework 2.0 or later , Visual Studio Tools for Office 2.0 runtime, and PIAs), and set security policies to grant full trust. These steps are explained in the MSI deployment whitepapers at Deploying Visual Studio 2005 Tools for Office Second Edition Solutions Using Windows Installer (Part 1 of 2) and Deploying Visual Studio 2005 Tools for Office Second Edition Solutions Using Windows Installer: Walkthroughs (Part 2 of 2).
The following table lists the prerequisites (with download links) to run Office solutions created with Visual Studio Tools for Office in Visual Studio 2008.
Office Platform
Primary Interop Assemblies
.NET Framework (minimum)
Visual Studio Tools for Office runtime version
2007 Microsoft Office system.
For a full list of supported versions and complete installation instructions, see How to: Install Visual Studio Tools for Office to Develop for the 2007 Microsoft Office System.
2007 Microsoft Office System Update: Redistributable Primary Interop Assemblies
Microsoft .NET Framework 3.5
Microsoft Visual Studio Tools for the Microsoft Office system (version 3.0 Runtime)
Microsoft Office Professional Edition 2003 and Office 2003 Service Pack 1 (or later).
For a full list of supported versions and complete installation instructions, see How to: Install Visual Studio Tools for Office to Develop for Microsoft Office 2003.
Office 2003 Update: Redistributable Primary Interop Assemblies
Microsoft .NET Framework Version 2.0 Redistributable Package (x86)
Microsoft Visual Studio 2005 Tools for Office Second Edition Runtime (build 8.0.50272.940) (x86)
To develop for Microsoft Office SharePoint Server 2007, see How to: Install Visual Studio Tools for Office to Develop for SharePoint Workflow Project Templates.
Helpful links:
Mary Lee, Programming Writer
Last Monday I presented session CLI202: Developing and Deploying Smart Clients for Office at the Office Developer Conference in San Jose. This blog post is a mini-version of the slides and demos from my session. The session was not recorded.
Slide 1: Office Development In VS 2008
Slide 2: Excel And Ribbon Demo
Slide 3: Databinding
Slide 4: Developing Outlook Add-Ins
Slide 5: Deploying Office Solutions
Slide 6: Best Practices
Slide 7: Resources
I hope this information is useful as a reference for those who attended my session and for those of you who were unable to attend.
The Visual Studio Tools for Office build environment in Visual Studio 2008 relies on a number of MSBuild tasks used together with the Microsoft.VisualStudio.Tools.Office.Office2003.targets and Microsoft.VisualStudio.Tools.Office.Office2007.targets files. These tasks register add-ins, generate the application and deployment manifests, copy customized documents to the build output folder, and update security on development systems. Be sure to create a backup copy of these .targets files before modifying them.
The build tasks are documented in Microsoft.VisualStudio.Tools.Office.BuildTasks Namespace (2007 System). However, the (2007 System) name appended to the build task name is not always correct. For several reasons, the build tasks for Microsoft Office 2003 and the 2007 Microsoft Office system were merged into a single namespace. The following tables show the correlation between the specific build task and the Microsoft Office version.
The following table shows which build tasks apply to the 2007 Microsoft Office system.
Build tasks for the 2007 Microsoft Office system
CheckOffice2007Document
CustomizeOffice2007Document
EmbedTypeLibrary
GenerateOfficeAddInManifest
GenerateOfficeDocumentInstallationPath
GenerateOfficeDocumentManifest
RegisterFormRegions
SetInclusionListEntry
SetOffice2007AddInRegistration
The following table shows which build tasks apply to Microsoft Office 2003.
Build tasks for Microsoft Office 2003
GenerateAndPersistAppInfoTask
IsInvalidDocumentTask
SetOffice2003AddInRegistration
SetOffice2003SecurityPolicy
[Updated 25 Aug 2008] Unlike what the following comments say, you can build VSTO solutions without having Visual Studio installed. Kent Boogaart has documented the assemblies that you need to copy at http://kentb.blogspot.com/2008/08/building-vsto-projects-without-visual.html
The Visual Studio team is growing and we have several exciting developer positions open!
If you’re looking for big challenges, if you’re driven to innovate, if you are looking for big impact and responsibilities, then you can join us!
We are building developer tools and infrastructure for Windows SharePoint Services and the SharePoint Server platform. We are going to invent, design and influence a wide range of RAD developer tools for the fastest growing server product in Microsoft’s history.
We’re in the early stages of execution – join us and make immediate contributions! Check out opportunities below and contact us - we’d love to hear from you!
Software Developers Positions - Business Applications
Nathan Carlson developed a creative solution for Outlook 2007 using Visual Studio 2008 (codename Orcas). The Out Loud for Outlook project started as a dogfood testing project last summer. For those of you unfamiliar with the dogfood testing practice at Microsoft, it's a term for testing our own products in real-world solutions while they are still in beta so we can personally experience any problems or bugs. The dogfood tests helped us find and fix dozens of bugs.
Out Loud for Outlook allows you to create a new Outlook rule that reads your designated email out loud when it triggers. You can also use voice commands with a good microphone to open and navigate through your emails.
Nathan recently updated the solution to run on the release version of Visual Studio 2008. The Out Loud for Outlook source code is available for download on the new Code Gallery site.
The sample demonstrates: