Last week I was down in London and spoke at DevWeek 2010. As usual, it was a great conference! Thanks to everybody who attended my talks!
I promised to put up my slides and samples – my apologies, it didn’t work out earlier. Here’s everything you need:
Post-con Workshop: Functional Programming in C# Deep Dive
I just twittered a few minutes ago, saying “Seems like VS 2010 can still not show the same file twice in panels next to one another. Am I missing something?". I’m still interested in the answer, if there is one, but meanwhile I thought I’d blog about something I’ve found interesting for a long time: the way our heads seem to work differently when it comes to applications of the words “horizontally” and “vertically".
You see, in Visual Studio (and that has been the same thing with MDI windows before that), they have a thing called a “Tab Group", which comes in horizontal and vertical varieties. These days the difference is illustrated in little icons at least, defining it like this:
Horizontal group (exhibit A):
+--------------------+ | | +--------------------+ | | +--------------------+
Vertical group (exhibit B ):
+-------+-------+ | | | | | | | | | | | | | | | | | | +-------+-------+
Now here’s my gripe with that: it’s the wrong way round!
In my eyes, exhibit A might be described as “a tab group with a horizontal splitter", but it is not a horizontal tab group. These things are not the same. A horizontal tab group is one where the tabs, the defining feature of a tab group, surely, are shown “horizontally", i.e. next to each other in horizontal direction. Just like exhibit B, in fact. And vice versa, of course.
I don’t know what somebody was thinking when they came up with those names, or maybe it’s just my head that works differently. It doesn’t make sense to me, in any case. And that’s the important point of this post: if you never realized that these terms might be confusing to somebody, here you are now!
One important factor in successful communication is about understanding misunderstanding – which is why, in my tweet, I was avoiding the terms “horizontal” and “vertical” as being confusing in the context. Of course the first and so far only reply I got to my tweet (and I’m not naming any names here <g> ) went “hey, do you mean vertically?” Hmpf.
Oh, and yes, according to the MS definition I mean vertically, yes. A tab group with a vertical splitter, that has been split in vertical direction, or whatever. A tab group with the tabs showing horizontally next to one another. And the same file on both sides of the splitter. Not possible, is it?
I have a solution with several projects that I currently work on in VS 2008. I would like to use VS 2010 for it instead, to benefit from new debugger features etc… but it should remain on the .NET 3.5 platform, and I would also like to keep things compatible so the solution can be opened and built in VS 2008 later on, if necessary.
I’m sure I haven’t looked at everything yet, and perhaps there will be issues down the line. But it certainly seems that this is pretty simple. Of course, right when you open such a solution in VS 2010, it doesn’t look simple at all: the import wizard comes up and wants to convert your projects. After you’ve done that, VS 2008 won’t open your solution anymore. Hm… so Microsoft doesn’t want you to do this?
Looking at the project (.csproj) files, quite a lot of changes have been made. The version number has been increased, but there’s also lots of new stuff included in the various sections of the file. That looks difficult. The solution (.sln) file on the other hand has only one change made, which is the version number. Now guess which of the two is the one that causes the problem? Wrong.
The problem is in fact the solution file. Although it’s only the version number that has changed, that number is evidently used to prevent opening the solution in an older VS version. Fair enough – until you find out that it is perfectly possible, and apparently even safe, to open the vastly more complex project files in an older VS version. Go figure.
So, the solution I went for is simple: I moved aside the modified .sln file and reverted the old one from svn. Now I have two different .sln files, one for VS 2008 and one for VS 2010. Both include the same projects, and these are in the VS 2010 format. Nevertheless, they work in both versions of VS without a hitch.
There’s one complaint during the build process in VS 2008, which is about the ToolsVersion – this is a parameter in the project file, which has been set to 4.0 by the conversion wizard. Fortunately, msbuild reverts to 3.5 automatically, so there’s no damage done and the build still works just fine. Other than that, I haven’t found any problems yet. I even tried to change project settings in VS 2008, and this leaves the versions intact even though 2008 must be a bit surprised to see 4.0 in there… again, go figure.
I just blogged about this problem I was having with Gallio/MbUnit. I don’t regard the issue as fixed, but I’ve certainly worked around it.
I found that the delay happened when the tool Gallio.Utility.exe was being run during the startup process of Icarus. I noticed that the same thing happened when I tried to run other included tools like the control panel, and it also happened when using TestDriven to run an MbUnit test from VS. I had the impression that the tool was being run multiple times, but that turned out to be a mistake – the tool was simply running for a rather long time, jumping up and down a bit in the task manager list. I finally ran the tool on its own and found that (a) it has something to do with the plugins that Gallio apparently uses (for purposes unclear to me, I have to admit) and (b) even to just run the tool and display the usage info message in a console, it takes 25 seconds or so.
So, simple solutions are sometimes the best: I deleted Gallio.Utility.exe. Next run of Icarus, it was restored. Okay, MSI is more cleverer than I. Or so it thinks – I went and configured the file access permissions on the file and removed all access permissions. Hah, take that, MSI. Next run, Icarus comes up within about 3 seconds, taking another 2-3 to load my test assembly. Hah!
Running a test through TestDriven from VS takes about 3.9 seconds now, so it’s at least 2 times slower compared to running the same test through the CodeRush test runner. Weird, but then who am I to complain.
Now, could somebody please fix that Utility program before I end up needing it for something?
I just started playing with MbUnit, or at least that’s what I had in mind – found out then that it comes in that Gallio package these days, with all sorts of stuff on board that doesn’t all have a clear purpose. Clear to me, that is. Well, I think at this point that I would prefer to have a simple package comparable to NUnit, but maybe when I see what’s in there, I’ll change my mind.
Anyway, so far, so good – I took a small test project with five tests in it, which was working with NUnit so far. Threw out the NUnit references and added MbUnit ones instead. I went for MbUnit as well as MbUnit35, since the project uses .NET 3.5, and I found I also had to add Gallio in order for everything to build. Then I ran my tests using the CodeRush Test Runner, and everything behaved exactly like before. Brilliant! All five tests run through in about 1.6 seconds, for future reference – roughly the same as I got with NUnit.
For some reason I had the idea to look around a bit, and I ran one of my tests through TestDriven.NET, which I’ve also still got installed (I mean in addition to the CodeRush thing, which I really use most of the time these days). And there’s a surprise: it took almost exactly 60 seconds (!) to run the one single test!
The process had two stages, which seemed to take roughly an equal amount of time. Stage one is up to the point where the Test tool window in VS says “Initializing the test runner. … Running the tests", and it took about 33 seconds. The stage after that is when the test actually runs, and it took about 27 seconds. Wow. Now, stage 1 must have had something to do with first-run initialization, because on subsequent runs the time of stage 1 is now down to less than a second. The time for stage 2, however, is still the same as before, comes up with about 27-28 seconds every time I try it.
Obviously I was glad to have the CodeRush runner, but then I thought it might be interesting to see the standard runner that’s included in the package. It’s called Icarus, and here’s surprise number 2: that thing is equally slow! I’ve now started it a few times, so I guess it’s now faster than it was in the beginning. I just did a rough test, and it takes almost 30 seconds for the UI of Icarus to even show up on screen. During that time, I can see in task manager that a process called Gallio.Util.exe (or is it Utility?) pops up many times and goes away again - no idea what the … thing… is going on there. Well, when the UI finally comes up, a progress bar dialog appears, telling me that the program is now exploring my tests. It moves to 49% pretty quickly, then hangs around for >20 seconds before finishing after an overall 25 seconds or so. Phew.
This is the same 5 test assembly I was using before. So, final test: run everything. The progress bar at the bottom of the window comes up to 53% very quickly, then stops. After a good while it continues and makes its way up to the top. Overall outcome: rather close to those 27-28 seconds I got from TestDriven.
Okay, this is the weirdest thing I can imagine… I don’t suppose there’s anything intentional about all this, but I can’t imagine what the problem is either. Why do those delays happen? How does CodeRush manage to run the tests without the delays, something that neither the much more mature TestDriven nor the standard runner can do? Very odd. I might go hunt around for the right place to report a bug on this etc etc. But who knows.
Update: I added a bug report here
Another update: I just notice that running the Gallio Control Panel app shows the same startup behavior as Icarus – takes forever, with that Gallio.Utility.exe thing popping up probably ten times or so. What sort of a weird application architecture is this? Hm…
Whoa: Sorry for all the updating :-) But this is interesting… I thought I’d see what the Utility thingy even did, so I ran it just like that. Comes up with a console window, and, well…. does absolutely nothing for a really long time, perhaps something like those 30 seconds long. I had enough time to read the helpful output in the console and think about it, before the window suddenly closed because the program was finally done doing nothing. I thought it was waiting for a keystroke by then :-)
In case somebody’s interested – I’m running in a VM with 2GB RAM, 2 cores available to the VM exclusively. Windows 7, VS 2008 and 2010 RC installed, working in 2008.