Archives
-
Top 10 signs you're addicted to VMWare
10. You're more excited about the next release of VMWare than the release of Longhorn.
9. Your home network has 3 machines, but your router reports 15 IP addresses in use.
8. Your Windows reports 418MB of RAM. Just because you can.
7. Every time a Windows patch is released, you need to run Windows Update 15 times.
6. You have no qualms about installing every Microsoft beta product there is.
5. You'd rather have an ISO image of a product than a real CD.
4. Before alt-tabbing to Outlook to check your email, you always hit Ctrl-Alt first.
3. Before installing any software, your first instinct is to take a snapshot.
2. When sitting down in front of a freshly booted Windows XP machine, you hit
Ctrl-Alt-Insert.
1. 1GB RAM? Not nearly enough!
-
CruiseControl, MSBuild, and Unit Tests
While converting our continuous integration process from Nant to MSBuild, I ran into a problem with unit tests. The build script runs our unit tests by calling the nunit-console.exe test runner with the Exec task. The tests reside in a number of assemblies, so I used an ItemGroup to list test assemblies, and batched the call to nunit-console.exe (as described in Peter Provost's blog posting). I wanted to run all of the tests, even if some of them failed, and my first thought was to set the ContinueOnError attribute of the Exec task to true. Unfortunately, there's a problem with this - it turns out that "Continue On Error" really means "Pretend task succeeded". In other words, even with test failures the outcome of the build was "success", and CruiseControl wouldn't report the build as failed. No good.
The solution to this turns out to be trickier than it probably should be, but it is possible. The idea is to store the exit code of the Exec task into an item group (one item per Exec), then use an Error task to check if any of the Exec's returned errors. Building on Mr Provost's example, the UnitTest target becomes:
<Target Name="UnitTest" DependsOnTargets="Compile">
<Exec ContinueOnError='true' Command='$(NUnitEXE) $(NUnitArgs) @(TestAssembly)' WorkingDirectory='%(WorkingDirectory)'>
<Output TaskParameter="ExitCode" ItemName="ExitCodes"/>
</Exec>
<Error Text="Test error occurred" Condition="'%(ExitCodes.Identity)'>0"/>
</Target>
-
ObjectDataSource and Caching in .NET 2.0
One of the disappointing limitations in .NET 2.0 beta 2 is that the ASP.NET ObjectDataSource control only supports caching when binding to DataSets and DataTables. Since ObjectDataSource is really intended for binding to domain objects, that design limitation didn't make much sense to me.
According to Nikhil Kothari, demi-god of ASP.NET, this limitation is being addressed for the final release. This is great news!