When building software isn’t fun
geek, programming, rant, visual studio, wix September 18th, 2008Some of the software I’ve been working on has been a pleasure to create. It’s all managed code, it’s very unit testable, the frameworks are well designed and developer-friendly. Castle Project and Asp.Net MVC for example are a joy to work with.
Two other things which came up this week were really brutal by comparison. One of them is Windows Installer XML (WiX) and the other is the Visual Studio Integration SDK.
Not that I’m saying they’re “bad.” I’m sure many people would swear by WiX as the best tool for creating installers there is. On the other hand maybe that’s just because all of the others are so much worse. The model of Product-Package-Feature-Component overlying a rats nest of Directory-File-Fragment-DirectoryRef elements, all bound up and interconnected with an overwhelming mass of Properties, Ids, Guids, Etc. Ouch! I know a lot of it is a function of the msi architecture, but the whole thing could use a serious injection of convention over configuration.
The thing with making Visual Studio Packages… It’s also kind of harsh going… It’s remarkable how the development environment is so modular in a way that enables you to provide so many different types of extensions. But since the interface is so firmly grounded in the world of Com, even Ole, it’s very challenging to implement. Plenty of deja vu, returning lots of VSConstants.S_OK, and trying to figure out what’s expected from a component by how the dozens of methods are invoked and in what order. And the biggest kicker is Reflector isn’t there to help you. My fingers are crossed Visual Studio 2010 will be a 100% managed rewrite.
So I guess you could say I’m mostly ranting. It’s just frustrating working with tools that take a great deal of effort to accomplish very modest, incremental tasks.
September 19th, 2008 at 12:41 am
I feel your pain, having worked on the Boo visual studio integration. It was very irritating not being able to use refactor for once, the IronPython reference implementation is so basic I always wanted to refactor the C# language provider to see how they did it but all that is unmanaged code.
September 19th, 2008 at 1:58 am
Yep, I was looking at the IronPython example also to try and find some type of starting point. The solution templates that come with Visual Studio seem to be based on some strange assumptions and existing language parsing tools.
I’m looking into making a language extension for Spark, of course. Some very early code is checked in at src\Tools\SparkVsPackage that has nothing more than colorization. Based on that experience I’m guessing it would take as much effort to get a fully functional editor experience as it did to make the view engine in the first place. :[