… normally I only argue above problems with Smalltalk systems not supporting this or that or examples are simply not working.
Asus XtionPRO Live
Then I bought the alternative Kinect from Asus – the XtionPro Live. This device also comes with OpenNI – the development SDK for this device – in an old version.
When installing this old version nothing is working – most of the examples (though 32 bits) are not working under my W7/64 bit. All examples crash with wrong “side-by-side-configuration” exceptions. Its a very bad example how to deliver software.
The solution is to go to OpenNI size and download the PrimeSense Package Stable Build and install the stuff from that. Its around 100 MB and installs also the OpenNI packages.
After all now the device is working and even the examples are also working.
Another story is MonoDevelop (3.0.3) and testing with NUnit. I do not know, if anyone has tested the stuff but it does not work – from within MonoDevelop. MonoDevelop always fails loading the dll with test cases. And the reason is: it can not find its “nunit.framework” dll (which is located within the Mono framework – but the worse thing is: MonoDevelop does not give you the information why it fails to load the est cases). The solution: copy an instance of “nunit.framework” to the output bin directory of your test solution and it works.
But even then testing and debugging are years behind Smalltalk …
Then I went into another problem with MonoDevelop. Within a test project I had source code containing the german umlauts and I had a console projects with the same source code. One of these lines was:
var sourceString = "äöü";
The console project was working, the test case always failed. It took quite a long time (in both cases the editor shows you “äöü” and even the VS2010 editor shows you both source files as visually identical) to understand the reason for this strange behaviour:
Within the test case source code this line was (somehow) saved with ISO8859-1/15 code page, while within the console project source code it was saved as UTF8.
Now within MonoDevelop you “simply” define a different code page for the C# compiler in the test case project and the problems were gone.