Kernel Mustard

OK, I’ve spent my entire holiday weekend working with Visual Studio 2005 Express Edition. In particular, I’ve been working with VC++, writing what they tell me is unmanaged code, whatever that means. After logging a few hours, I thought I’d share some feedback.

First, let me start by saying that this thing is really the real deal. If you’re trying to learn how to be a coder (on Windows), this toolkit will do it for you. There are some annoying holdbacks from Standard Edition and better, but overall this thing will work for producing serious software. If anything, Microsoft dramatically under-bills its capabilities on the website.

I’ve covered the missing SAL support, missing x64 compiler, and missing profile-guided optimization before, so I won’t re-hash all that. A couple of other irritating points came up, though. First off, Express Edition [apparently] doesn’t support building ATL projects, at least on x86. Getting the PSDK doesn’t help either; it is broken in at least two ways: it has a #pragma in atlbase.h to statically include atlthunk.lib, but there is no atlthunk.lib in the SDK. There’s no way to explain that one away. And, for the icing on the cake, there’s actually a c++ conformance bug in atlwin.h [IIRC] related to standard for() scoping.

I’ve complained about FrankenKits before, and while I was able to work around the atlthunk.lib issue by re-coding the missing functions in my own static library, I was reduced to editing the atlwin.h file in place. That is a huge no-no, and while it’s obviously not Express Edition’s fault per se, Standard Edition comes with enough ATL machinery that the PSDK’s crappy ATL is unnecessary. And as a parting shot: If you’re not going to support a feature (i.e. ATL), don’t include options in the project config for letting you specify how you want to link to ATL.

Which brings me to my second minor beef. One of the things I like about Standard Edition is the capability for organizing projects into sub-folders in Solution Explorer. I hate long lists – as much as I love build.exe, its requirement to keep everything in one directory[*] is really terrible. Same goes for projects in the IDE. So imagine my surprise when, after organizing all of the 40-ish projects in one of my workspacessolutions into folders using Standard Edition, Express Edition flatly refused to load those projects. I guess they had to pick some things to differentiate Express over, but maaaan, that one is just annoying. Fine, no profiler. But seriously: no subfolders?

A couple of other 1.0-ish problems happened now and again. For some reason, the IDE kept wanting to build projects that were unchanged on a couple of occasions. The compiler would fire up, realize there were no relevant changes, and rip through the file list in no time. But, it was annoying; a re-start of the IDE fixed it each time. Another nitpick is related to dependency ordering in the .sln file – every time you save the .sln, it reverses the order of the dependencies in the XML file. This has no effect when it comes to the IDE, but it’s hell on source control. I have tons of revisions of my .sln files that are essentially NOPs. Any white noise like this just makes it harder to keep your eyes open for relevant changes in a multi-user environment. Anyway, I suspect both of these bugs are in all of the 2005 editions, and I bet they’ll both be gone by SP1.

So, overall I’d give Express Edition an A-. If it had cost me money, it’d be a pretty solid B, but the price sure is right, and what they do ship is really very good. Enthusiastically recommended.

I was just surfing around trying to identify some phantom property sheets that seem to have attached themselves to my Visual Studio projects, when I ran across this post from Peter Huene. It’s the best description of this property sheet inheritance functionality that I’ve seen so far.

I’m gratified to see that they had some trouble figuring out how to graphically represent this:

This is where the view can get slightly confusing (we toyed with several different representations early on in Whidbey). Where as the configuration nodes are “contained” by their parent project nodes, the configuration nodes inherit from their child nodes (likewise for each property sheet node). Projects have no relation, property-wise, to configurations in our build system, so the project nodes simply act as a method of grouping configurations together.

At Positive Newtorks, we have a remarkably flexible configuration system called the Policy Manager (catch naame, eh?) that has been dealing with this exact problem since 2001. After a lot of early gnashing of teeth over the GUI, we settled out on something similar to this. I remember thinking at the time that there had to be a better way to organize the information, but nothing any better came up during design discussions, so we went with the tree.

Now, I’d hesitate to hold out the VS 2005 UI as the paragon of interface design, but I know they spend a lot of time on this sort of thing at Microsoft, so I’m intrigued to see that they came up with the same solution. And, on the flip side, I know how hard this design problem can be – the level of flexibility they’re trying to provide here is very difficult to represent visually.