Visio solutions comes in three forms: Visio add-on, COM add-in, and VBA code stored in the document. This article on MSDN describes the differences between add-ons and add-ins. Most of the new solution development that I’ve seen use COM add-ins, which were introduced to Visio in Visio 2002. COM add-ins are easier to write, work in-proc with Visio, don’t have timing issues, and are simpler in nature than VSL add-ons. Add-ons have been around since Visio 2.0, so there are a lot of older applications that use them. There’s also other benefits to a VSL, like being run in response to a formula recalc or launched from the Visio Tools menu (see the article for full details). All of the solutions that we ship in Visio are VSLs.
A VSL (Visio library file) add-on is a Visio-specific dynamic-link library (DLL) that exports a function called VisioLibMain, which is the entry point for Visio communications with the VSL. VSLs are typically written in C++. People have asked if they can write a VSL add-on in C#.
You can't write a VSL from C# but you can write an unmanaged VSL that drives a C# component. The VisLibMain function is an unmanaged C entry point. You can write a simple unmanaged C++ VSL that calls a C# implemented object through .NET/COM interop. The hard part will be using custom CLR hosts to handle hosting managed cost bits in your unmanaged VSL application. You’ll need to read up on custom CLR hosting: Steven Pratchner wrote a great article on this a couple years ago called Microsoft.NET: Implement a Custom Common Language Runtime Host for Your Managed App. Alternatively, you can write a managed C++ VSL.
If you want to play around with this, the best way to get started with creating a VSL (or any Visio solution, for that matter) is to install the SDK. The SDK adds Visio solutions wizards to the New Project wizard in Visual Studio for you. You'll be able to go through the Visio solution setup for a VSL and get a compiling C++ VSL when you're done with the wizard.
Keep in mind that if you take the managed C++ or the custom CLR host approach, you will incur the same cross-process overhead for working with Visio that you get with COM add-ins written in C# and VB.NET. So while it's doable to write an unmanaged VSL that drives a C# component, it's certainly not trivial. Unless you're an expert on custom CLR hosting, you'll have to ramp up on that. Debugging might not be a whole lot of fun either, and there are no resources (articles, samples, etc.) that demonstrate how to take this approach. Personally, I'd stick with C++ if writing a VSL add-on. If you're a C# or VB.NET programmer, I'd use COM add-ins with QUEUEMARKER Add-on.
-- Mai-lan
This posting is provided "AS IS" with no warranties, and confers no rights