Continuous Disintegration

I’ve been working with NServiceBus at work lately, and it’s useful to be able to look at the messages that are landing in the queues. Unfortunately, the MMC snap-in provided by Microsoft is woefully inadequate when it comes to this task. There are some commercial tools available, but I thought I should be able to find a free tool out there somewhere with this seemingly simple functionality. I found Msmq Studio , a nice little app that enables you to do many different queue management tasks both locally and remotely. However, it doesn’t seem to work on my machine now (or any of the servers at work), though it did at one time. I need something reliably do one simple thing , so I decided to take the opportunity to experiment with WPF, a platform for which I’ve never written an app. The result is what I’ve tentatively titled ‘Queue View’:   This app does one thing and one thing only – it shows, in XML format, the contents of messages in private queues on the local machine (assuming, of co

You can find code for adapting a DataRow to the IDataRecord interface all over the place. One scenario in which this might be useful is [when the dregs of coding society are forced to perform] mapping the results of a database call to a custom object with the results sometimes coming back as a DataSet and sometimes as a DataReader. IDataRecord has a lot of members that you probably wouldn’t use, simply because they are for retrieving strongly-typed values from the record based on numeric index. You’re probably doing these conversions manually and getting the values by named index. If that’s the case, why not constrain the consumption of these types with the following interface: public interface IIndexedDataRecord { object this[string name] { get; } } and these adapters: public class DataReaderAdapter : IIndexedDataRecord { private readonly IDataReader reader; public DataReaderAdapter(IDataReader reader) { this.reader = reader; } public obj

I’ve read a few posts   about   Kobe , a new sample ASP.NET MVC application intended to provide guidance for web application development. One thing that really jumps out at me (taking the bloggers at their word) as a glaring mistake is the absence of any unit tests. I mean, isn't testing one of the driving factors for the creation of ASP.NET MVC (second bullet point)?

I got bitten by not knowing some Rhino Mocks API details today. I had some tests written a certain way which were passing and some others written the same way which were failing. (Code can be found here .) In the case of the successful tests, Rhino Mocks appeared to be properly returning a mock object when a property was called on another mock, and in the case of the failing tests it was returning nulls for the property on a mocked object. There didn’t appear to be any difference in the way I needed to declare and setup the mocks used in the test, but there was a subtle one: the code that passed the tests only accessed the property once , whereas the code that failed accessed it multiple times . Because of the way I set up my mocks, a mock was returned for the property the first time it was accessed only. If you use Expect.Call(…).Return(someObject) , by default the method/property will only return the specified object once . If you use a stub or SetupResult.For(…).Return(someObject)

UPDATE: As I suspected, this functionality was right in front of my face – it’s called PredicateConstraint in Rhino Mocks. I also realize that I managed to completely ignore the existence of Predicate<T> in the framework, and write my own predicate delegate. Hey, I was on a roll. Rhino Mocks has a PropertyConstraint class that allows you to check the values on properties of objects passed into the method as part of the verification for that method being called. Unfortunately, the name of the property is specified as a string, which means the benefits of strong-typing that Rhino Mocks is normally so good at preserving are lost. Here’s an example (using Rhino Mocks 3.3 and .NET 2.0): [Test] public void Main_Form_Should_Show_Start_Panel_On_Load() { MockRepository mockRepository = new MockRepository(); IMainFormView mockView = mockRepository.DynamicMock<IMainFormView>(); IEventRaiser loadEventRaiser = GetEventRaiserFor(delegate { mockView.Load += null; });

Sooo... long time, no post! All zero readers of this blog might be curious about why I disappeared. The short story is I’ve been sidetracked by personal issues combined with a butt-ton (sorry to those in far away lands; I don’t know how to convert this to metric) of work at my paying gig. We’ve all been there and done that. I’m sure you can relate, non-existent reader. But I’m not making any more excuses! This post serves as a list of topics I want to cover in future posts. It’s long, so I doubt I’ll get to all of these. More ‘SharpMock’ – I haven’t abandoned this project, but I was saddened when I realized I had forgotten all I learned about PostSharp when I cracked open the [smelly from having gone so long without bathing] spike code. Creating DSLs with MGrammar – I’ve noticed a lot of bloggers are unsure about the vision Microsoft has for ‘Oslo’. Count me among them. But I definitely have had some fun playing around with Intellipad and MGrammar recently. I see a lot of pot