Introduction
On November 2006, Microsoft released Visual Studio 2005 Tools for the 2007 Office System, also known as VSTO 2005 SE (Second Edition). Developers have long been able to create custom add-ins for Visio. With VSTO 2005 SE, developers are now able to create VSTO add-ins for Visio.
You might be wondering, “Why should I care about VSTO 2005 SE when I have already been able to create custom add-ins for Visio?”
Here’s why. VSTO 2005 SE allows you to create secure add-ins for Visio. When you create a VSTO add-in, you can isolate your add-in from unexpected crashes of other add-ins. You can digitally sign your VSTO add-in. This allows your add-in to run when an administrator turns on the “Require Application Add-ins to be signed by Trusted Publisher” setting. Finally, VSTO add-ins operate under the .NET Code Access Security model. Your VSTO add-in has to be granted Full Trust in order to be loaded by Visio.
In this blog entry, I am going to:
· Overview of the different Visio solution options
· Recap the problem with Shared Add-ins
· Walkthrough on creating and deploying VSTO add-in for Visio
Overview of Visio Solution Options
Simply put, there are many ways to create a Visio solution. The following list briefly describes each of the options, in the order they were first made available:
· VSL add-ons: VSL’s (ViSio Libraries) were first made available with Visio 2.0. In fact, many of the out-of-the-box Visio solutions, such as the Organization Chart, are implemented as a VSL add-on. You create VSL add-ons using C or C++. The emphasis of this Visio solution option is sheer speed.
· EXE add-ons: EXE add-ons were also first made available with Visio 2.0. They are simply standalone executables that can be launched from Visio and can be created with virtually any programming language. EXE add-ons run in a separate process space as Visio, so you should avoid this option if your solution needs to access the Visio Automation Library a lot.
· VBA: Before Microsoft acquired Visio Corporation, Visio was probably one of the first non-Microsoft products to support Visual Basic for Applications (or VBA). VBA solutions are document-centric, meaning that code is embedded within the Visio drawing file. I like to use VBA for quick prototypes, especially with the Macro Recorder.
· COM add-ins: While VBA macros run at the document level, COM add-ins run at the Visio application level. They are created using unmanaged environments like Visual Basic 6.0, or unmanaged C++.
· Shared add-ins: Shared add-ins are application-level solutions created using .NET languages like VB.NET and C#. They are typically created using the Shared Add-in wizard, or by using the “Visio add-in or add-on” wizard that comes with the Visio SDK. They still fundamentally use COM to extend Visio, but using managed code.
· Visio Drawing Control: The Visio Drawing Control is an ActiveX component that lets you put your own chrome around Visio. You can embed the Visio Drawing Control in your Windows Forms or browser-based applications. It is essentially a wrapper around the Visio engine itself. You need to have Visio installed on the client machine.
· VSTO add-ins: VSTO add-ins are also managed code add-ins that run at the Visio application level, but require the VSTO runtime. The VSTO runtime includes a dedicated add-in loader that provides AppDomain isolation. VSTO add-ins must be granted full-trust on the target machine. The emphasis here is security.
For more information on VSL add-ons and EXE add-ons, please refer to About Microsoft Office Visio Add-ons and COM Add-ins.
For more information on the Visio Drawing Control, please refer to Programming with the Microsoft Office Visio 2003 ActiveX Control and Host an Interactive Visio Drawing Surface in .NET Custom Clients.
Since Visio 2002, Visio solution developers have had a helpful Visio software development kit (SDK), which provides code samples, sample applications, tools, and documentation. The Visio SDK includes the “Visio add-in or add-on” wizard, that shows up as an additional project type for VB.NET, C#, and C++ in Visual Studio. The add-ins you create with this “Visio add-in or add-on” wizard is identical to the ones you create using the Shared Add-in wizard. The difference is that the “Visio add-in or add-on” wizard allows you to create add-ons. For VB.NET and C#, you can create EXE add-ons. For C++ you also can create VSL add-ons.
The Visio 2007 SDK has been updated with more code samples and documentation that highlight the new Data Link and Data Graphics capabilities in Visio 2007. For more information, please go to the Visio Developer Portal.
Recap of the Problems of Shared Add-ins
Shared add-ins are not all that bad. If your add-in needs to work in multiple Office applications (e.g. Visio, Excel, and Word), you need to create a Shared add-in. VSTO add-ins are specific to their Office host. Also, if your add-in needs to work when multiple versions of Office applications are installed on the same machine, you will have better luck with a Shared add-in (although this is not recommended). Microsoft does not support VSTO development in the scenario where different versions of the same Office application are installed on the same machine.
VSTO add-ins address several problems that Shared add-ins have. Here I will shamelessly copy and paste from a couple of other blogs and articles that already do a great job describing the problems of Shared add-ins.
Brian A. Randall describes three problems with Shared add-ins in Migrating a Shared Add-in to a Visual Studio Tools for Office Add-In:
Mscoree.dll is the main entry DLL to the goodness that is the common language runtime (CLR). To ensure that the CLR is correctly loaded into a host application before your shared add-in, mscoree.dll is listed in the registry as the in-process server to load, not your managed assembly. This creates a few problems.
The first problem is that if your shared add-in (or some other one) causes an unhandled exception and crashes the host, the host will provide the user with an opportunity to stop the add-in from loading the next time. If the user chooses this option, the host lists the add-in as disabled. The problem is that the host application cannot distinguish between one shared add-in and another. It will ban mscoree.dll and thus all shared managed add-ins from the host.
The second problem is that when the CLR is initialized, it creates a default application domain and all shared add-ins loaded by the host are put into the same application domain. The problem with this is that one add-in can cause another add-in to fail. For example, one add-in could call ReleaseComObject on an object that both add-ins are using. This could happen in a case where there are two add-ins loaded into Excel, ExcelAddinOne and ExcelAddinTwo. By default, the two add-ins are put into the same default application domain. One of them is aggressive about memory management, say ExcelAddinTwo, and it calls FinalReleaseComObject on the Excel.Application reference that both add-ins are holding a reference to via a shared runtime callable wrapper (RCW). When ExcelAddinOne tries to access its reference to Excel it is a System.AccessViolationException: Attempted to read or write protected memory.
The third problem is an issue of trust. While most Office applications (in Office 2003, for example) trust add-ins out of the box (Publisher 2003 being an exception), it is possible for a security-minded user or administrator to disallow unsigned add-ins (those that don not have a valid X.509 signature). If this is done, your shared add-in will not work—even if you do sign it. Why? Once again it is mscoree.dll. Your Office application is looking to see if mscoree.dll is signed, not your managed assembly.
You can avoid these problems associated with Shared add-ins by creating a custom COM shim. A COM shim is essentially an unmanaged DLL that creates a separate AppDomain for your managed Shared add-in to run. You can then digitally sign your custom COM shim.
COM shims aren’t without problems either, as Andrew Whitechapel points out in Architecture of the Outlook Add-in Support in Visual Studio 2005 Tools for Office. Although the article was written for Outlook Add-in Support (VSTO 2005 “First Edition”), many of the points in this article still apply to VSTO 2005 SE:
You can download a Visual Studio COM Shim Wizard and project set from Microsoft, which enables you to build an unmanaged shim for managed add-ins. This approach solves some of the problems of a managed add-in that does not include a shim, but some issues remain:
· This approach is unsupported by Microsoft.
· This approach requires you to deploy an unmanaged shim component, plus one or more managed components with different installation requirements. This can be confusing for administrators (and developers) to maintain.
· The (wizard-generated) shim is written in C++, a development language with which managed add-in developers are not always familiar.
· With this model, each add-in requires an associated shim DLL, even though more than 99 percent of the code is identical across all such shims.
VSTO 2005 SE overcomes these issues by providing a supported, codesigned, single VSTO add-in loader.
For more information on the COM Shim Wizard, please see Andrew Whitechapel’s blog entry titled, COM Shim Wizards v2. It’s worth pointing out again from the early quote regarding the COM Shim Wizard, “This approach is unsupported by Microsoft.”
Creating a VSTO add-in for Visio 2007
Creating a VSTO add-in project for Visio is really simple. After you download and install the Visual Studio 2005 Tools for the 2007 Office System, you will get several new project templates in Visual Studio. Under your preferred programming language, let’s say Visual Basic, expand Office, and then 2007 Add-ins. There you will find a project template to create a Visio Add-in.
Here are the steps to follow to create your first VSTO add-in for Visio 2007:
1. Start Visual Studio 2005. Click Create Project.
2. Under Visual Basic | Office | 2007 Add-ins, and then select Visio Add-in.
3. Type MyVisioVSTOAddin for the name of the project. Click OK.
Visual Studio will then create a new project for a VSTO add-in that can be loaded in Visio 2007. The project will have all the required references, including the Visio 2007 Primary Interop Assembly. The debug settings of the project will be set so that when you press F5 to debug, Visio starts up. A class named ThisAddIn will also be defined automatically for you. This class replaces the Connect class that you may have been familiar with in a Shared Add-in. Finally, Visual Studio will create a new setup project for your add-in to get you started. (Emphasis on the “to get you started”-- you need to do more to actually get it to deploy your add-in on a test machine.)
ThisAddIn is an improvement from the Connect class. Instead of the four methods you had to implement with IDTExensibility interface, ThisAddIn requires two: Startup and Shutdown. ThisAddIn also takes advantage of the partial class feature introduces with Visual Studio 2005. The VSTO add-in project template adds ThisAddIn.Designer.vb, a partial class that contains generated code to support VSTO add-in functionality. Tip: If you are using Visual Basic, you might need to click the “Show All Files” option under the Project menu to see ThisAddIn.Designer.vb.
By default the partial class defined in ThisAddIn.Designer.vb declares the Visio Application object using WithEvents:
Friend WithEvents Application As Microsoft.Office.Interop.Visio.Application
I strongly recommend that you remove the WithEvents keyword. As you may know, Visio has two event handling models. The first is by using the WithEvents keyword, the second is by using the AddAdvise method. When you use AddAdvise, Visio will raise an event for the events that you specify. When you use WithEvents, Visio will raise all events, even though you may not have an event handlers defined for all events. I recommend that you always use AddAdvise when creating Visio solutions because Visio won’t have to raise events for events you don’t care about.
For now, let’s display a simple “Hello, world!” message box when Visio starts up.
4. Add the following code to the ThisAdd_Startup procedure:
System.Windows.Forms.MessageBox.Show("Hello, world!")
5. Compile and run.
When you run the code, Visio should start up and display “Hello, world!” in a message box.
Deployment
Now here’s where it starts to get pretty tricky. In order for your add-in to work on a non-development machine, you have to make sure that the following steps are taken:
1. Install .NET 2.0 Framework
2. Install VSTO SE Runtime
3. Install Visio 2007 Primary Interop Assembly
4. Add required add-in registry settings
5. Copy add-in assembly.
6. Copy any Visio templates and stencils
7. Grant full trust to add-in
The Setup project that is created for you by the VSTO SE add-in project template only takes care of steps 1, 4 and 5. Step 6, adding Visio templates and stencils is very easy. You just have to right-click on the setup project in Solution Explorer, and then click Add | File.
To do steps 2, 3, and 7, you need to customize the setup project. Fortunately, there are two great MSDN articles that show you how to do these customizations:
In the next few sections, I will copy and paste excerpts from the above two articles, including and editing what is relevant for Visio 2007 solution development. However, I strongly recommend that you take the time to read the above two articles in its entirety.
The first step is to install the accompanying download of the above two articles: OfficeVSTO2005SEWindowsInstaller.msi. This download contains custom setup bootstrapper packages for the VSTO 2005 SE runtime and Office 2007 PIA’s. It also contains the required custom action project to grant full trust to your add-in assembly.
After you install the accompanying download, follow the steps below from Deploying Visual Studio 2005 Tools for Office Second Edition Solutions Using Windows Installer (Part 1 of 2). The default location of the {SamplesDir} token below is “C:\Program Files\Microsoft Visual Studio 2005 Tools for Office SE Resources\VSTO2005SE Windows Installer Sample”:
Adding the Visual Studio Tools for Office Packages to the Bootstrapper
The following instructions describe how to add the packages listed above to the bootstrapper package directory. These changes need be made only once and only on your development computer.
This task shows how to use the files that are available in the Windows Installer download that accompanies this article. To use them, prepare the files before you copy them into the bootstrapper package directory.
Preparing the Runtime
To prepare the VSTO 2005 SE runtime bootstrapper package
1. Download Microsoft Visual Studio 2005 Tools for Office Second Edition runtime from the Microsoft Download Center.
2. Copy vstor.exe into the {SamplesDir}\packages\VSTOSERuntime directory.
Preparing the Visual Studio Tools for Office Language Pack Bootstrapper Package
If any users run your solutions with non–English settings for Windows, they must have the Visual Studio Tools for Office Language Pack to see runtime messages in the same language as Windows.
To prepare the Visual Studio Tools for Office Language Pack
1. Download the Microsoft Visual Studio 2005 Tools for the Microsoft Office System (VSTO2005) Language Package from the Microsoft Download Center.
2. Copy the file vstolp20.exe into the directory {SamplesDir}\packages\VSTOLP.
Preparing the Office Component Check
Compile the Office component checker sample for the primary interop assemblies redistributable packages.
|
|
|
If you are using VSTO 2005 SE in conjunction with VSTO 2005, ensure that you have installed both the .NET Framework 2.0 software development kit (SDK) and the Windows SDK. |
|
|
|
By default, Visual Studio Tools for Office does not install the .NET Framework 2.0 SDK. You can download it or install it from the installation media by using the Add or Remove Programs command in Visual Studio Tools for Office. In addition, you need to download a copy of the Microsoft Windows Software Development Kit for Windows Vista and .NET Framework 3.0 Runtime Components from the Microsoft Download Center. You can also download a copy of the .NET Framework 2.0 Software Development Kit (SDK) (x86) from the Microsoft Download Center. |
|
|
|
These downloads are not required if you are using a version of Visual Studio with Visual C++ installed. |
To prepare the Office component check
1. Open the Command Prompt window needed to compile the check.
If you are using Visual Studio 2005 Professional, Team Suite, or one of the role-based Team editions, open the Visual Studio 2005 Command Prompt window by clicking Start, and then pointing to Programs, pointing to Microsoft Visual Studio 2005, pointing to Visual Studio Tools, and then clicking Visual Studio 2005 Command Prompt.
If you are using Visual Studio Tools for Office, run CMD Shell by clicking Start, pointing to Programs, pointing to Microsoft Windows SDK, and then clicking CMD Shell.
[If you are running on Vista, you should right-click and Run as administrator.]
2. At the command prompt, change the directory to {SamplesDir}\projects\Checks
|
|
|
By default, the SamplesDir directory is C:\Program Files\Microsoft Visual Studio 2005 Tools for Office SE Resources\VSTO2005SE Windows Installer Sample. |
3. Compile the component checker by typing the following command.
cl.exe /Oxs /MT /GS ComponentCheck.cpp advapi32.lib
4. Close the Command Prompt window.
5. Using Windows Explorer, copy the executable file ComponentCheck.exe into {SamplesDir}\packages\Office2003PIA and {SamplesDir}\packages\Office2007PIA.
Preparing for the 2007 Release of Office
You must include the primary interop assemblies for 2007 in the corresponding bootstrapper package if your solution will run in the 2007 release of Office, including VSTO 2005 Excel and Word document solutions.
To prepare the primary interop assemblies bootstrapper package
1. Download the 2007 Microsoft Office System Update: Redistributable Primary Interop Assemblies from the Microsoft Download Center.
2. Run the primary interop assembly installer.
3. Accept the Microsoft Software License Terms, which gives you the right to package the primary interop assemblies as part of your installer.
4. In Windows Explorer, open the folder to which the installer extracted the files.
5. Copy O2007PIA.msi into the directory {SamplesDir}\packages\Office2007PIA.
|
|
|
Because you cannot directly download the redistributable package, you must always include it with your Windows Installer. If you set the prerequisite installation location to the Web, you are warned that this particular package must be included when you build the Setup project, as shown here: WARNING: No 'HomeSite' attribute has been provided for '2007 Microsoft Office Primary Interop Assemblies', so the package will be published to the same location as the bootstrapper. |
Copying the Packages into the Bootstrapper Directory
Now that you have prepared the prerequisites, copy them into the bootstrapper package directory.
To copy the packages into the bootstrapper
1. Determine where your bootstrapper package directory is located.
In Visual Studio Tools for Office, the default directory is here:
C:\Program Files\Microsoft.NET\SDK\v2.0\BootStrapper\Packages\
In Visual Studio 2005 Professional, Team Suite, or one of the role-based Team editions, the default directory is here:
C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\BootStrapper\Packages
|
|
|
If in doubt, you can determine the location by appending \bootstrapper\packages to the value of this registry key: \HKLM\SOFTWARE\Microsoft\.NETFramework\sdkInstallRootv2.0 |
2. Copy the contents of the directory {SamplesDir}\packages into the bootstrapper directory.
The next set of steps is to be completed for each of your VSTO add-in projects for Visio. Let’s do these steps for our MyVisioVSTOAddin project. The excerpt below is from Deploying Visual Studio 2005 Tools for Office Second Edition Solutions Using Windows Installer: Walkthroughs (Part 2 of 2) with my revisions:
Walkthrough: Enhancing the Visio Add-in Setup Project
This section describes how to enhance the Setup project that Visual Studio defines when you create an Outlook add-in project. It explains how to perform the following steps:
· Modify the Setup project so that it installs the prerequisites: the VSTO 2005 SE runtime and, optionally, the Visual Studio 2005 Tools for Office Language Pack.
· Add a step to the Setup project to grant security trust to the customization assembly.
· Add launch conditions to the Windows Installer (.msi) file to prevent installation if the prerequisites are not installed.
Signing the Assembly
Later in this article, you will grant trust to the customization assembly based upon a strong name and its location. However, you must first sign the assembly.
To sign the assembly
1. In Solution Explorer, right-click MyVisioVSTOAddin, and then click Properties.
2. Click the Signing tab.
3. Select the Sign the assembly check box.
4. In the Choose a strong name key file list, click <New. . .>.
5. Type the name MyVisioVSTOAddin in the Key file name box.
6. Type a password in the Enter password and Confirm password boxes.
7. Click OK.
8. Close the Properties pages.
Adding the Prerequisites to the Setup Project
Add the prerequisites that the bootstrapper will install. A later step addresses adding launch conditions.
To add the prerequisites
1. In Solution Explorer, right-click MyVisioVSTOAddinSetup, and then click Properties.
2. In the Property Pages dialog box, click Prerequisites.
3. In the list of prerequisites, select the following items:
a. 2007 Microsoft Office Primary Interop Assemblies
b. Microsoft Visual Studio 2005 Tools for Office SE Runtime
4. Select Microsoft Visual Studio 2005 Tools for Office Runtime Language Pack if any users run your solutions with non–English settings for Windows. These users must have the Visual Studio 2005 Tools for Office Language Pack to see runtime messages in the same language as Windows.
5. Click OK twice.
Adding a Custom Action to Grant Trust to the Assembly
Grant trust to the customization assembly using the supplied custom action sample.
To add the supplied project
1. Using Windows Explorer, copy the SetSecurity project from the {SamplesDir}\projects directory to the directory that contains the OutlookAddin solution.
|
|
|
By default, the {SamplesDir} directory is C:\Program Files\Microsoft Visual Studio 2005 Tools for Office SE Resources\VSTO2005SE Windows Installer Sample |
2. In Solution Explorer, right-click MyVisioVSTOAddin.
3. Point to Add on the shortcut menu, and then click Existing Project.
4. Select the SetSecurity project.
5. Click OK.
6. In Solution Explorer, right-click the SetSecurity project, and then click Build.
[If you are running on Vista, you should copy the setup project to a folder outside of the Program Files tree.]
To add the primary output of the custom action project to the Setup project
1. In Solution Explorer, right-click MyVisioVSTOAddinSetup.
2. Point to View on the shortcut menu, and then click Custom Actions.
3. In the Custom Actions editor, right-click Custom Actions, and then click Add Custom Action.
4. In the Look In list, click Application Folder, and then click Add Output.
The Add Project Output Group dialog box opens.
5. In the Project list, click SetSecurity.
6. Select Primary output from the list of output types, and then click OK.
7. Verify that Primary output from SetSecurity (Active) is added to the list of primary outputs for the Setup project.
This enables the Windows Installer file to run the custom action that edits the application manifest.
To add the custom action data for the Install method
1. In the Custom Actions editor, expand Install.
2. Right-click Primary output from SetSecurity (Active), and then click Properties Window.
3. In the Properties window, set the CustomActionData property to the following string. Enter this as one long string, and change MyCompanyName to your company name.
/assemblyName="MyVisioVSTOAddin.dll" /targetDir="[TARGETDIR]\" /solutionCodeGroupName="MyCompanyName.MyVisioVSTOAddin" /solutionCodeGroupDescription="Code group for MyVisioVSTOAddin" /assemblyCodeGroupName="MyVisioVSTOAddin" /assemblyCodeGroupDescription="Code group for MyVisioVSTOAddin" /allUsers=[ALLUSERS]
|
|
|
You do not need to add extra quotation marks if your company name contains a space. |
To add the custom action data for the Rollback method
1. In the Custom Actions editor, expand Rollback.
2. Right-click Primary output from SetSecurity (Active), and then click Properties Window.
3. In the Properties window, set the CustomActionData property to the following string:
/solutionCodeGroupName="MyCompanyName.MyVisioVSTOAddin"
To add the custom action data for the Uninstall method
1. In the Custom Actions editor, expand Uninstall.
2. Right-click Primary output from SetSecurity (Active), and then click Properties Window.
3. In the Properties window, set the CustomActionData property to the following string:
/solutionCodeGroupName="MyCompanyName.MyVisioVSTOAddin"
|
|
|
Although you did not override the Commit method with a custom action, the base Windows Installer class provides an implementation. Thus, you must still call the method. However, it does not require any custom action data. |
Adding Launch Conditions to the Windows Installer File
When the user runs Setup.exe, the Windows Installer checks for the prerequisites, and installs them if necessary. Alternatively, the user can double-click the .msi file to install the solution. In that case, the prerequisites are not installed and the solution cannot run. In other cases, Setup might fail because resources it needs are not present; for example, custom actions might require the .NET Framework.
This section shows you how to use the Launch Conditions editor to add launch conditions to the .msi file to prevent installation if certain dependencies are not installed.
To view the Launch Conditions editor
1. In Solution Explorer, right-click MyVisioVSTOAddinSetup.
2. Point to View on the shortcut menu, and then click Launch Conditions.
Add a launch condition for the VSTO 2005 SE runtime.
To add a launch condition for the VSTO 2005 SE runtime
1. In the Launch Conditions editor, right-click Requirements on Target Machine, and then click Add Registry Launch Condition.
2. Select the newly added search condition, Search for RegistryEntry1.
3. Rename the search condition to Search for VSTO 2005 SE Runtime.
4. In the Properties window, change the value of Property to VSTORTVERSION.
5. Also in the Properties window, set the value of RegKey to the following string.
Software\Microsoft\vsto runtime Setup\v2.0.50727
6. Leave the Root property set to vsdrrHKLM and change the Value property to Update.
7. Select the newly added launch condition, Condition1.
8. Rename it to Display message if the Visual Studio 2005 Tools for Office SE Runtime is not installed.
9. In the Properties window, change the value of the Condition property to the following string.
VSTORTVERSION >= "#1"
10. Leave the InstallURL property blank.
11. Change the value of the Message property to The Visual Studio 2005 Tools for Office SE Runtime is not installed. Please run Setup.exe.
If any users run your solutions with non–English settings for Windows, they must have the Visual Studio 2005 Tools for Office Language Pack to see runtime messages in the same language as Windows. Add a launch condition to check for the Language Pack.
To add a launch condition for the Visual Studio 2005 Tools for Office Language Pack
1. In the Launch Conditions editor, right-click Requirements on Target Machine, and then click Add Windows Installer Launch Condition.
2. Select the newly added search condition, Search for Component1.
3. Rename the search condition to Search for VSTO Language Pack.
4. In the Properties window, in the ComponentId property, type the following GUID:
{2E3A394E-C9BD-40C3-9990-BA7AF7C8B4AF}
5. Change the value of Property to COMPONENTEXISTS_VSTOLP.
6. Select the newly added launch condition, (Condition1).
7. Rename it to Display message if the Visual Studio 2005 Tools for Office Language Pack is not installed.
8. In the Properties window, change the value of the Condition property to COMPONENTEXISTS_VSTOLP.
9. Leave the InstallURL property blank.
10. Change the value of the Message property to The Visual Studio 2005 Tools for Office Language Pack is not installed. Please run Setup.exe.
When you create the launch conditions for the VSTO 2005 SE runtime and the Visual Studio 2005 Tools for Office Language Pack, you must right-click the Requirements on Target Machine node. This created both the search condition and the corresponding launch condition.
Testing the Installation
To test your Windows Installer, run it on a computer other than your development computer, because many of the prerequisites are already installed. Remember to run the Setup.exe file to test the bootstrapper. Remember first to build your Setup project.
To build Setup
· In Solution Explorer, right-click the MyVisioVSTOAddinSetup project, and then click Build.
Conclusion
As you can see, there are some extra steps that you have to complete in order to deploy a VSTO 2005 SE add-in for Visio. Shared add-ins are more straightforward when it comes to deployment. However, the payoff of using a VSTO 2005 SE to create Visio add-ins is significant. You will be able to digitally sign your assembly and take advantage of the VSTO add-in loader.
--Chris