Because why anyone would want to write VBA in the Visual Studio macro editor is beyond me. All the bits and pieces below are pretty much known, but I think the overall result is new. For the bewildered (I don’t blame you), what you’ll be able to do is, from F# Interactive, for example enumerating the current projects in the open solution:
> myDTE.Solution.Projects |> Seq.cast<Project> |> Seq.map (fun p -> p.FullName);;
val it : seq<string> =
seq
["C:\Users\Kurt\Projects\FsCheck\doc\FsCheck\FsCheck.fsproj";
"C:\Users\Kurt\Projects\FsCheck\doc\FsCheck.Examples\FsCheck.Examples.fsproj"; "";
"C:\Users\Kurt\Projects\FsCheck\doc\FsCheck.Checker\FsCheck.Checker.fsproj"; ...]
You get access to the DTE top level automation object of the Visual Studio instance the current FSI is running under. This DTE is a COM interface that basically allows you to do programmatically what you can do using the Visual Studio UI interface – it’s the thing you get access to in the Macro IDE as well. So you can do pretty cool things – like add files, generate code, listen to build events, find dependencies of projects and such.
But…how?
The Macro IDE gives access to the DTE object automagically. But fsi is actually a separate process, that just happens to input and output through Visual Studio. So basically we need to get access to a Visual Studio instance’s DTE object from outside of Visual Studio. Luckily, each instance of Visual Studio registers its DTE object in the Running Object Table (hereafter called ROT) with two keys:
- As a string of the form “!VisualStudio.<VS version>.0:<processid>”. E.g. for VS2008 with process id 1234: !VisualStudio.9.0:1234
- As the path to an open solution file, if any.
We’ll use the first option. That means we need to find out the process id of the Visual Studio instance the current FSI instance is running under. FSI is started as a child process of Visual Studio – each Visual Studio has its own FSI.
Let’s tackle each of these in turn – first finding the process id of the current Visual Studio instance, then its DTE object via the ROT.
Step 1: Finding the Visual Studio process id
Not as straightforward as it sounds. System.Diagnostics.Process does not give you direct access to a process’ parent. There are at least two ways to go about it – using the Windows API or, maybe surprisingly, through performance counters. I used the latter because that didn’t require me to do interop.
The code is pretty straightforward – remember the point is that this is being executed in F# interactive:
open System open System.Diagnostics let getParentProcess (processId:int) = let proc = Process.GetProcessById processId let myProcID = new PerformanceCounter("Process", "ID Process", proc.ProcessName) let myParentID = new PerformanceCounter("Process", "Creating Process ID", proc.ProcessName) myParentID.NextValue() |> int let currentProcess = Process.GetCurrentProcess().Id let myVS = getParentProcess currentProcess
You should just be able to paste that into an F# Interactive window and myVS will contain the process id of the Visual Studio instance it’s running under. (No doubt this will crash spectacularly when you’re running FSI standalone or something.)
Step 2: Getting the DTE object
This was a bit harder, as we’re now going to have to do some interop with OLE32. Code for this is floating around on the internet if you know where to look – I just translated it to F#. Here’s what we need:
#r "EnvDTE" #r "EnvDTE80.dll" #r "EnvDTE90.dll" open EnvDTE open EnvDTE80 open EnvDTE90
open System.Runtime.InteropServices open System.Runtime.InteropServices.ComTypes module Msdev = [<DllImport("ole32.dll")>] extern int GetRunningObjectTable([<In>]int reserved, [<Out>] IRunningObjectTable& prot) [<DllImport("ole32.dll")>] extern int CreateBindCtx([<In>]int reserved, [<Out>]IBindCtx& ppbc)
These two interop functions allow us to enumerate the ROT and get the registered object with the key we want:
let tryFindInRunningObjectTable (name:string) = //let result = new Dictionary<_,_>() let mutable rot = null if Msdev.GetRunningObjectTable(0,&rot) <> 0 then failwith "GetRunningObjectTable failed." let mutable monikerEnumerator = null rot.EnumRunning(&monikerEnumerator) monikerEnumerator.Reset() let mutable numFetched = IntPtr.Zero let monikers = Array.init<ComTypes.IMoniker> 1 (fun _ -> null) let mutable result = None while result.IsNone && (monikerEnumerator.Next(1, monikers, numFetched) = 0) do let mutable ctx = null if Msdev.CreateBindCtx(0, &ctx) <> 0 then failwith "CreateBindCtx failed" let mutable runningObjectName = null monikers.[0].GetDisplayName(ctx, null, &runningObjectName) if runningObjectName = name then let mutable runningObjectVal = null if rot.GetObject( monikers.[0], &runningObjectVal) <> 0 then failwith "GetObject failed" result <- Some runningObjectVal //result.[runningObjectName] <- runningObjectVal result
I won’t go into the virtues of this particular piece of code. Suffice to say it’s an acquired taste. (Bonus points for anyone who can write a function that returns the ROT as a nice, lazy seq<string*obj>. Yes I know it seems easy – but please try and prepare to be frustrated.). So we now have a function that returns the COM object in the ROT based on the name. If you put in the code in comments and change a few bits and pieces, it should be easy to get a function that outputs the ROT completely.
Putting two and two together
Armed with these functions, here’s the DTE object that you can use to call the Automation API:
let getVS2008ROTName id = sprintf "!VisualStudio.DTE.9.0:%i" id let myDTE = (tryFindInRunningObjectTable (getVS2008ROTName myVS) |> Option.get) :?> DTE2
This is for Visual Studio 2008. For 2010, it should be as easy as changing the 9 to 10 in the ROT key string. It’s possible to make this more general if you can come up with a way to check whether the current process is .NET 4 or .NET 3.5 – the former would indicate an FSI running in VS2010, the latter in VS2008.
And that’s it. Have a look around using Intellisense to see what is possible. Also check out the Macro IDE – it has some code examples in VBA that involve the DTE. Some ideas:
- myDTE.ExecuteCommand lets you execute any command – the things you can bind keyboard shortcuts to in the Options. For example, use ProjectandSolutionContextMenus.Item.MoveDown to move the currently selected item one place down.
- myDTE.Events to register event handlers for all sort of Visual Studio events. For example, myDTE.Events.BuildEvents.add_OnBuildDone notifies you when a build is done. Nice for post-build steps that need to run after a solution is built (as opposed to after a particular project is built).
- myDTE.Quit(). The l33t hax0r way to exit Visual Studio. You’ll be the envy of your less tech-savvy colleagues.
If you find an imaginative use for this, please let me know.
| Share this post : |  |
 |
 |
 |
 |
 |
 |
