Getting started with C# in LINQPad with Visio

This post is about how to use LINQPad to enable you to write C# against Visio in a similar way you use VBA.

What I like about VBA is that it’s fast, and I’m not talking about code execution necessarily, but the time from being in the Visio interface to actually writing and executing some code. It’s just Alt+F11 and off you go.

If only I could write C# in a similar, light-touch way.  Well LINQPad appears to offer just that.

Although there is a very useful free edition, some of the features I’m going to talk about are only in the paid editions, so be sure to check out the comparison table on the Purchase page.

So what is LINQPad?

LINQPad is a standalone tool that primarily allows you to write and test LINQ queries.  You can point at a number of data sources, query them directly and see the results.  It’s lightweight and fast to use, which sounds a bit like the VBE!

To support the ability to create queries LINQPad allows you to write in VB.Net, C#, SQL, ESQL and F# and can actually be used to execute standalone C#, but in order to talk to Visio you first need to setup the appropriate references.

Walkthrough

When you open LINQPad you’ll see a default tab representing the your first query.

All queries are isolated from one another and each sits in its own process. So this is a blank canvas and the first thing you need to do is add a reference to the Visio interop assembly. 

1. Hit F4 to show the references dialog:

   

2. Hit ‘Add’, filter for Visio, and you’ll be presented with a number of versions from the interop assembly depending on your Visual Studio version:

   

3. Once you’ve added the reference, you’ll see your new reference appear in the list:

   

4. Now you’ve got a reference to the correct assembly you then need to add the associated Using/Imports namespaces so that they’re available to your code.  So, click on the Additional Namespace Imports tab and add that as well.  If you want to add an alias then you can do that by editing directly in the dialog:

   Visio = Microsoft.Office.Interop.Visio

Talking to Visio

With all of the references in place you can now start to write some code. You’re supported with code completion and the power of the .NET framework, so for (a simple) example:

Dump is a LINQPad extension method that dumps out the types, names and values of all of the properties of any object that it meets.

What you really want to do, of course, is to talk to a running instance of Visio and you can do that like this:

try
{
    Application vApp = (Application)System.Runtime.InteropServices.Marshal.GetActiveObject("Visio.Application");
}
catch (Exception ex)
{
    "Couldn't find running Visio instance".Dump();
}

You can now save your query and it will be available in the ‘My Queries’ treeview at any time in the future.

Alternatively you could add the above snippet to a global ‘My Extensions’ query that will be available to all other queries you create.  For example, if you add the following to your ‘My Extensions’ query:

void Main()
{
    // Write code to test your extensions here. Press F5 to compile and run.
}
 
public static class MyExtensions
{
    // Write custom extension methods here. They will be available to all queries.
    public static Application GetRunningVisio()
    {
        Application vApp = null;
        try
        {
            vApp = (Application)System.Runtime.InteropServices.Marshal.GetActiveObject("Visio.Application");
        }
        catch (Exception ex)
        {
            "Couldn't find running Visio instance".Dump();
        }
 
        return vApp;
    }
}
 
// You can also define non-static classes, enums, etc.

…you could then reference that static method from ‘Query 1’ like this:

Each query can be saved as a standalone file (.linq) that can then be used in the future and called as a command line argument.

One last thing to be aware of is that, in company with the rest of Office, most of Visio’s collection types implement IEnumerable allowing you to foreach over their items.  LINQ, however, is looking for an IEnumerable<T> to play with and so you just need to cast your collections prior to iterating over them.

Here’s a list of all of the types that implement IEnumerable (and so can be cast to IEnumerable<T>):

• AccelItems
• AccelTables
• Addons
• Colors
• Comments
• Connects
• DataColumns
• DataRecordsets
• Documents
• Fonts
• GraphicItems
• Hyperlinks
• Layers
• Masters
• MasterShortcuts
• MenuItems
• Menus
• MenuSets
• OLEObjects
• Pages
• Path (exposes an array of points)
• Paths
• Selection
• Shapes
• StatusBarItems
• StatusBars
• Styles
• ToolbarItems
• Toolbars
• ToolbarSets
• ValidationIssues
• ValidationRules
• ValidationRuleSets
• Windows

So, for example, if you wanted to sweep up all of the hyperlinks on each shape on a page you could do something like this (ensuring you cast to the correct type of t:

I think this is a really cracking product. I’ve used it for some time as a tool to debug various LINQ queries, but I can really see it taking a lot of the work load off of how I used VBA.