Tuesday 5 September 2006

NAnt, NUnit and mono 1.1.17

The new release of mono contains various bug fixes, many of them concerning the AppDomain class, creation of application domains and communication between them. Unfortunately, those changes broke the <nunit2> task in NAnt scripts run on Linux (strangely, everything works fine on Windows). When executed, task reports an incompatible version of NUnit assembly used to compile the tests. However, when nant is run with -verbose switch, the real exception can be examined - mono is unable to load the NAnt.NUnit2Tasks.dll into the new AppDomain.


A temporary workaround is to execute the tests with the <exec> task. Start with defining a template target:



<target name="test-assembly">
<if test="${platform::is-unix()}">
<!-- nunit2 task is borked on linux with mono 1.1.17 -->
<property
name="nunit.exe"
value="${framework::get-assembly-directory(framework::get-target-framework())}/nunit-console.exe" />
<echo message="${test-assembly}" />
<exec program="${nunit.exe}" workingdir="${binaries-dir}" useruntimeengine="true">
<arg value="/nologo" />
<arg value="${test-assembly}" />
</exec>
</if>
<if test="${not platform::is-unix()}">
<nunit2 verbose="true">
<test assemblyname="${binaries-dir}/${test-assembly}" />
<formatter type="Plain" />
</nunit2>
</if>
</target>

The target still calls <nunit2> task when run on Windows, as it is faster then executing nunit-console.exe. On Linux it finds the nunit-console.exe from the appropriate framework version and uses it to execute the test. To use the template, two properties have to be set:



<target name="TestObject.test" depends="TestObject.dll">
<property name="binaries-dir" value="bin_test"/>
<property name="test-assembly" value="TestObject.dll" />
<call target="test-assembly" />
</target>

You can hardcode the binaries-dir or set it once for the entire build to avoid repeating it in every call to test-assembly.

D-Link G604T

W piątek odebrany z drugiej naprawy serwisowej. Za pierwszym razem (po dłuższej pracy zaczynał gubić pakiety, moc sygnału skakała zupełnie losowo, firewall - wylączony! - odcinał nagle połączenie itd.) - 3 tygodnie w serwisie i dostałem nowy sprzęt. Zgodnie z instrukcjami producenta zabrałem sie do instalacji nowego firmware'u i na tym sie skończyło. Instalator sie wysypał, router umarł. Druga naprawa poszła szybciej - szybciej tez access point zepsuł sie ponownie. W niedziele (niecałe dwa dni pracy!) zaczął szwankować cache DNS. Wylączylem cache - wszystko wróciło do normy, ale nieopatrznie chciałem zapisać zmiany. To wymaga restartu urządzenia... Po którym nie podniósł sie juz interfejs WiFi. Owszem, jestem w stanie go włączyć ponownie - pod warunkiem, ze wepnę sie do routera poprzez kabel ethernetowy. Wspaniale. Nie chce kolejnej naprawy, chce pieniądze z powrotem, D-Link nie nadaje sie do użytku.