After playing a few great games of Links and Project Gotham Street Racing 2 (catch name) last weekend with Jason Bock and James Avery, I was especially interested to read his piece in MSDN a couple of months ago about 10 must have tools for .NET developers. The piece has since been republished (and I hope James really stung them for reprint royalties on that one, hehe) online at http://msdn.microsoft.com/vstudio/default.aspx?pull=/msdnmag/issues/04/07/musthavetools/default.aspx. It's got a rating of 8 so far - nice going James.
One tool mentioned in the article is Regulator, a neat app designed to make working with, and writing, regular expressions a lot easier. But, it's a stand alone tool. I agree with James, it's a fantastic tool, but if I'm writing code in Visual Studio that needs to use Regular Expressions it just feels so darn wrong to have to Alt Tab out to some other app to do my testing. I got to discussing this with James yesterday and the idea of writing a Visual Studio plug in came up. I've been thinking of diving into learning how to do that for quite some time and neat little RegEx tool seems ideally suited. Basically it will run as a tool window (just like the solution explorer, task list, properties window and so on) in VIsual Studio and allow you to key in a RegEx. That RegEx will then run over the currently opened document and display results in a list within the tool window. If you use pattern groups (is that what they are called) then each pattern group will also be shown so you can easily make sure that you're RegEx groups just the right information you need. Ultimately, you'll also be able to search RegExLib's extensive RegEx catalogue (they supply a webservice for just that very thing - good on them) and also when running an expression be able to click on matches and have them highlighted in the open document.
Since I've never written an add-in, some research followed. Add-ins in Visual Studio use COM and scripting. For example, the Properties tool window is really a COM ActiveX control hosted inside a window of Visual Studio's creation. So, to develop an add-in that lives as tool window in VS, you need to learn how to create ActiveX controls in .NET right? Thankfully, no. If you head on over to msdn.microsoft.com/vstudio, click on Downloads and then click on Code Samples you'll see a heading that takes you to a bunch of add-in sample code. Microsoft also supply a fantastic ATL control called VSUserControl which is a container for .NET managed user controls. Adding a new tool window to Visual Studio then involves little more than instantiating the container in your add-in project's OnConnection handler, letting VS know about it, and then dropping a user control right into the container. Fantastic stuff. There's a little more to it than that of course, but not much, and it really didn't take very long at all to get a basic toolwindow up and running for RegExinator as it's now known.
Of course, it's very early days, and the layout and design is all wrong and nasty, but it's a great step in the right direction. I'll be setting up a GotDotNet workspace for the project pretty soon so that you all can take a look. James has also threatened to help out, which I'm very grateful for, although I am a little nervous about such a guru seeing my code.
Despite all of that though, I did run into some really peculiar problems that needed solving, not with .NET, but with Windows XP. First up, when you create an Add-in Project in Visual Studio, the add-in project wizard actually goes ahead and sets up the necessary registry keys for VS to pick up the add-in and runs regasm on the resulting add-in binaries so that you're already to start coding and debugging. I didn't realize this in my eagerness to get something on screen and when the add-in promptly crashed on first run with Visual Studio asking me if I wanted to remove it as a result, I stupidly said Yes. Bye bye registry keys. Bye bye regasm's hard work. It took some digging around but to get over this I simply ran regasm on the assembly again, then went into RegEdit and searched for HKEY_CURRENT_USER/Software/Microsoft/VisualStudio/7.1/Addins and added a new key referencing my assembly and the startup class. In this case the new key is called RegExinator.Connect.
WIth that out of the way I was at last able to write my code and debug it. Hitting F5 runs a new version of Visual Studio where I can use add-in manager to kick off the add-in and step through it, breakpoint it etc to my hearts content. Then I got hit by the big problem.
I don't know what I did, or how I did it, but suddenly when I tried to add new classes to my solution, Visual Studio started complaining about "Automation Server unable to create object". I rebooted thinking I'd obviously borksed up the container control (it's actually called a Shim control) somewhere along the line. No joy there. I loaded up a different project and tried adding a new class to that. Same error. I tried creating a new project and ended up with an empty solution following exactly the same error. Visual Studio appeared to have died on me completely and I broke out in a hot sweat at the thought of uninstalling and then re-installing all the express products, Whidbey and Visual Studio.NET 2003.
Windows rules the desktop all over the world because of the volume of users it has (eat number dirt Linux-monsters). This means that it's incredibly unlikely that you'll ever run into a problem that's not been found, and solved, before. A quick scoot around Microsoft's support libraries confirmed this. Visual Studio uses a huge amount of scripting behind the scenes. When you add a class or a form to a project, scripts run to create that class, or build an empty form for you. The error I was getting occurs when the Scripting Engine in XP has been corrupted. Like I said earlier, no idea how that happened, but it did. The solution was to download version 5.6 of the Windows Script engine and install it. A quick reboot later and everything was back as it should be.
Fun fun. Anyways, I'm having a ball learning all about what I can and can't do with add-ins and of course getting the add-in working across the board in 2003, Whidbey and Express. I'll let you know when it gets uploaded somewhere public, and yes, of course it will be free and open source.
2:15:29 AM 
|
|
