A blog post by Bembeng Arifin describes how to use xUnit.Net’s console test runner but I wanted to clarify one important point and simplify his recommendations.
I am using xUnit.net with C++/CLI invoking native DLLs and so I need to have the working directory set to where these reside. The settings I use are (note the fixed directory for Command, obviously changing to that of your local install).
Initial Directory: $(BinDir)
Use Output Window: checked
Shown in context in the dialog:
In case anyone’s curious about the appearance of the above dialog, it was captured on a Mac using Remote Desktop into my Windows 7 box so the rendering lacks a bit of Aero gloss.
We have a standard environment variable pointing to the location of thirdparty code which I wanted to use but the tool definition dialog refused to accept a path for the Command like $(thirdparty)\xUnit_net\blah.exe.
It also refuses to accept just an executable name, even when it’s on the PATH and can be run in a command window with just that executable name.
Bembeng’s post showed using the longer way to compose the Arguments of $(BinDir)$(TargetName)$(TargetExt) but I prefer simply $(TargetPath) which is easier to type and read.
If anyone’s curious, I eventually picked xUnit.net over NUnit and mbUnit/Gallio because it allows for similar parameterised testing but has a GUI test runner that copes with C++/CLI and I like their style and rationale.
Musing today whilst discussing various XAML coolness (I really love binding properties), I wonder how long it will be before it is possible to just include little bits of Ruby or Python script as a ValueConverter or other tiny algorithm. It’s entirely possible that WPF 4 already supports this and I’ve been too busy to notice. That starts sounding awfully like a Rails view written in XAML!
I did a 10 minute presentation on a WPF application architecture using C++/CLI as a ViewModel to wrap a pure C backend, at the DevJam held by the Perth .Net Community of Practice. Here are the slides in PDF and PPTX format including a few notes which cover the points I made verbally.
This post mainly exists to publish pictures and a sample source download link for the question on Stack Overflow about which pattern to adopt. Petzold, in Applications = Code + Markup, is flexible when choosing how to implement menus – he uses commands when they are from the standard command set, such as Application.Cut. For application-specific work he uses the Click event of the MenuItem.
Right now, most of the Silverlight samples indexed by Google are for version 2b1, such as Microsoft’s own gallery.
Given the key role of Silverlight in broadcasting the Olympics, I assume anybody and everybody related to the team is either exhausted or busy and if they aren’t working, are on standby should disaster strike. We will probably see some progress in a few weeks’ time.
However, it has been irritating the whatever out of me for weeks now that when I try to point people at a Silverlight example, I’m left looking faintly like an idiot because the behaviour of a Silverlight 2b1 site when you arrive there with 2b2 installed is to tell you that you don’t have Silverlight installed and give you a nice shiny button to click on to install. If you bother to click on the button you get a nice MS page explaining how you really do have Silverlight installed but the previous site is to blame for not realizing that. That kind of exception handling and disclaimer looks professional and works, up to the point where it is in your face all the !@#$ !@#$ time because practically every site of interest is hitting the exception.
Oh, and should you go to MS to install Silverlight, of course you are offered the current 2b2 installer, hence every new user gets dropped in the same mess.
Note to MS – whoever thought up the “ain’t installed” approach for handling a later version needs their butt kicking – that is never a good way to go. A lot of people, I suspect the majority, will not bother following the link to find out they are running a later version.