Thanks to a comment from Daniel Richardson on my previous MSTest post (and a lot more research, testing, & debugging), I’ve found a more flexible way of calling MSTest from MSBuild. The main drawback of the solution I blogged about earlier was that new test assemblies added to the solution would not be run in MSBuild unless the Exec call to MSTest.exe was updated to include them. But thanks to a combination of MSBuild transforms and batching, this is no longer necessary.
First, I needed to create a list of test assemblies. The solution is structured in a way that makes this relatively simple. All of our test assemblies live in a “Tests” folder, so there’s a root to start from. The assemblies all have the suffix “.Test.dll” too. The following CreateItem task does the rest:
<CreateItem Include=”$(TestDir)\**\bin\$(Configuration)\*.Test.dll” AdditionalMetadata=”TestContainerPrefix=/testcontainer:”>
<Output TaskParameter=”Include” ItemName=”TestAssemblies” />
</CreateItem>
The task above creates a TestAssemblies element, which contains a semicolon-delimited list of paths to every test assembly for the application. Since the MSTest command line needs a space between each test assembly passed to it, the TestAssemblies element can’t be used as-is. Each assembly also requires a “/testcontainer:” prefix. Both of these issues are addressed by the combined use of transforms, batching, and well-known metadata as shown below:
<Exec Command=”"$(VS90COMNTOOLS)..\IDE\mstest.exe” @(TestAssemblies->’%(TestContainerPrefix)%(FullPath)’,’ ‘) /runconfig:localtestrun.testrunconfig” />
Note the use of %(TestContainerPrefix) above. I defined that metadata element in the CreateItem task. Because it’s part of each item in TestAssemblies, I can refer to it in the transform. The %(FullPath) is well-known item metadata. For each assembly in TestAssemblies, it returns the full path to the file. As for the semi-colon delimiter that appears by default, the last parameter of the transform (the single-quoted space) replaces it.
The end result is a MSTest call that works no matter how many test assemblies are added, with no further editing of the build script.
Here’s a list of the links that I looked at that helped me find this solution:
If you need to determine what versions of the .NET Framework are available on a machine programmatically, you’d ideally use a C++ program (since it has no dependencies on .NET). But if you can guarantee that .NET 2.0 will be available, there’s another option. The source code (written by Scott Dorman) is ported from a C++ program. I’m using the library for an application launcher that verifies the right version of the .NET Framework is available (among other prerequisites).
When one of my colleagues left for a new opportunity, I inherited the continuous build setup he built for our project. This has meant spending the past few weeks scrambling to get up to speed on CruiseControl.NET, MSTest and Subversion (among other things). Because we don’t use TFS, creating a build server required us to install Visual Studio 2008 in order to run unit tests as part of the build, along with a number of other third-party tasks to make MSBuild work more like NAnt. So the first time a build failed because of tests that had passed locally, I wasn’t looking forward to figuring out precisely which of these pieces triggered the problem.
After reimplementing unit tests a couple of different ways and still getting the same results (tests passing locally and failing on the build server), we eventually discovered that the problem was a bug in Visual Studio 2008 SP1. Once we installed the hotfix, our unit tests passed on the build server without us having to change them. This hasn’t been the last issue we’ve had with our “TFS-lite” build server.
Build timeouts have proven to be the latest hassle. Instead of the tests passing locally and failing on the build server, they actually passed in both places. But for whatever reason, the test task didn’t really complete and build timed out. Increasing the build timeout didn’t address the issue either. Yesterday, thanks to the Microsoft Build Sidekick editor, we narrowed the problem down to the MSTest task in our build file. The task is the creation of Nati Dobkin, and it made writing the test build target easier (at least until we couldn’t get it to work consistently). So far, I haven’t found (or written) an alternative task, but I did find a blog post that pointed the way to our current solution.
The solution:
<!– MSTest won’t work if the tests weren’t built in the Debug configuration –>
<Target Name=”Test:MSTest” Condition=” ‘$(Configuration)’ == ‘Debug’”>
<MakeDir Directories=”$(TestResultsDir)” />
<MSBuild.ExtensionPack.FileSystem.Folder TaskAction=”RemoveContent” Path=”$(TestResultsDir)” />
<Exec Command=”"$(VS90COMNTOOLS)..\IDE\mstest.exe” /testcontainer:$(TestDir)\<test assembly directory>\bin\$(Configuration)\<test assembly>.dll /testcontainer:$(TestDir)\<test assembly directory>\bin\$(Configuration)\<test assembly>.dll /testcontainer:$(TestDir)\<test assembly directory>\bin\$(Configuration)\<test assembly>.dll /runconfig:localtestrun.testrunconfig” />
</Target>
TestDir and TestResultsDir are defined in a property group at the beginning of the MSBuild file. VS90COMNTOOLS is an environment variable created during the install of Visual Studio 2008. Configuration comes from the solution file. Actual test assembly directories and names have been replaced with <test assembly> and <test assembly directory>. The only drawback to the solution so far is that we’ll have to update our MSBuild file if we add a new test assembly.
When I was trying to debug a continuous build timeout at work recently, I came across this Scott Hanselman post about parallel builds and builds with multicore CPUs using MSBuild. While adding /m to the buildArgs tag in my ccnet.config didn’t solve my timeout problem (putting the same unit tests into a different class did), pooling multiple MSBuild processes will certainly help as our builds get bigger.
I was about to write a method that checked to see if a character was a hexadecimal value when it occurred to me that I should google for it. I was going to name it IsHexDigit, and googling for that revealed this link. I’m not sure why it’s in the System.Uri class, but it’s less code for me to write.
We’ve spent the past couple of weeks at work giving ourselves a crash course in Windows Presentation Foundation (WPF) and LINQ. I’m working on a code example that will switch the datatemplate in a list item when the mouse hovers over it. Unfortunately, WPF has no MouseHover event like Windows Forms does. The usual googling didn’t cough up a ready-made answer. Some hacking on one example did reveal a half-answer (not ideal, but at least a start).
First, I set the ToolTip property of the element I used to organize my data (in this case, a StackPanel). Next, I added a ToolTipOpening event for the StackPanel. Here’s the code for StackPanel_ToolTipOpening:
private void StackPanel_ToolTipOpening(object sender, ToolTipEventArgs e)
{
e.Handled = true;
ContentPresenter presenter = (ContentPresenter)(((Border)((StackPanel)e.Source).Parent).TemplatedParent);
presenter.ContentTemplate = this.FindResource("Template2") as DataTemplate;
}
The result: instead of a tooltip displaying when you hover over a listbox row, the standard datatemplate is replaced with an expanded one that displays more information. This approach definitely has flaws. Beyond being a hack, there’s no way to set how long you can hover before the templates switch.
Switching from an expanded datatemplate back to a standard one involved a bit less work. I added a MouseLeave event to the expanded template. Here’s the code for the event:
private void StackPanel_MouseLeave(object sender, MouseEventArgs e)
{
ContentPresenter presenter = (ContentPresenter)(((Border)((StackPanel)e.Source).Parent).TemplatedParent);
presenter.ContentTemplate = this.FindResource("ScriptLine") as DataTemplate;
}
So once the mouse moves out of the listbox item with the expanded template, it switches back to the standard template. Not an ideal solution, but it works.
This link started me down the path to finding a solution (for reference).
Here’s the e-mail home page.
They’ve got a little announcement, technical specs, even a blog with annoying, cutesy music.
If you’ve bought a new PC or Windows laptop recently, it probably came “bundled” with a bunch of free software. It is a near certainty that the bundled software you got is awful. Most people I know who make their living from computers (the ones who use Windows instead of Mac OS X anyway) reformat the hard drive and install only what they need to avoid this junk. Why this software is on your computer in the first place is another story. This post is about where you can find free software you actually want on your computer.
The Google Pack (http://pack.google.com) is a great place to start adding software you actually need. As of this writing, the pack contains 14 applications. This includes applications like Adobe Acrobat Reader, Firefox, Picasa, Skype, and RealPlayer. The biggest benefit of adding these applications to your new computer via Google Pack is the updater software. You can configure it to automatically update applications when there are new versions.
Open Source Windows is another great source for free software. Unlike the Google Pack offerings, none of the software you’ll find at Open Source Windows is offered by Google. The types of software are broader in many ways as well. They include instant messaging (IM) clients, RSS clients, video playback, sound recording, graphics/photo editing, even games.
So if you’ve got a new Windows machine you need to get running, get rid of the bundled software and pay those sites a visit. It will only cost you a little time, and the quality of the software you’ll get in return makes it a worthwhile investment.
If you want to know how long ago the seeds of the current financial crisis were sown, definitely listen to this episode of Fresh Air. Terry Gross’ interview of Frank Partnoy reveals not just how derivatives came to be unregulated, but who some of the players were in making it possible. What may disturb you is how many of the people who made the current situation possible are playing key roles in trying to fix it. Partnoy also authored F.I.A.S.C.O.: Blood in the Water on Wall Street. He first wrote this book 12 years ago–before the collapse of the internet and telecom bubbles, before Enron, and the subprime mortgage meltdown that triggered our latest financial calamity.
I’m at the airport to pick up a couple of friends, just back from a week in Spain. Adam asked me last week if I could pick him and his fiancée up from the airport. Somehow, we didn’t exchange a flight number along with the airport and arrival time, so I had no easy way to see if anything changed. Thanks to the web, this was no problem.
A search for Dulles Airport brought up their website. A search for today’s arrivals from Spain revealed the flight number and scheduled arrival time (which turned out to be about 30 minutes later than Adam and I discussed last week). I put the flight number into flightstats.com, and not only did it give me both segments of the return flight, it updated the scheduled arrival time and provided a near real-time map of their flight as it approached.
So instead of showing up way too early, I got to Dulles just a few minutes before Adam called to let me know they’d landed. I was able to do all that (and write this post) with my iPhone 3G.