December 1st, 2009 by Mark Harris
No comments »
This post has been sitting in my drafts for a while. After my day today i felt that it was best that i put my thoughts about service broker down.
In a project that i worked on about 2 years ago Service Broker was used as part of the system to perform data validation. If success was measured by the amount of time that a system has been in production without major issues then i can say that it was successful.
But if a system was to be judged by how much of a pain it is to maintain then l must say that its was not a glowing success. Below is a list of things that i found as good or bad about it.
Bad things
- Limited information on the internet
- Testing is extremely hard (compromises everywhere)
- Troubleshooting is a pain
- It could stop working and you may never know, (if using a fire and forget mechanism)
- Poison messages disable queues (would have been nicer if it moved the message to a error queue)
Good things
- Its Asynchronous
- Its Asynchronous
- Its Asynchronous
Yes this list is one sided but true. The question that is important though is
Would i use Service Broker again?
The answer to that question is strangely YES. Only in very specific circumstances where system is ok with not having some data loss because of queue being disabled
What would I use instead?
NServiceBus of course. It provides an answer to all the negatives of service broker and is still asynchronous.
October 22nd, 2009 by Mark Harris
No comments »

First off i know there should be no reason for me to do this as there are hosting options galore, but sometimes its just easier having the code running in your LAN, so with that in mind i remembered reading that Scott Hanselman wrote about his experience setting up VisualSvn on WHS.
So i decided to follow his work and rather than reinvent the wheel, however as i went through the process i found that a couple of things needed changing to make this whole processes much easier.
Setup a new share on your home server using the Windows Home Server Console. The recommended approach is to Uncheck the Enable Folder Duplication Check Box, though i have yet to experience any of the locking issues described here
- Log on to your Windows Home Server using Remote Desktop
- Give the Network Service access to the share as well as permissions on the folder to Read/Write/Modify files as required. For a detailed walkthrough on what and how to modify the permissions are available in the VisualSvn Knowledge base article for Storing Repositories on a Network Share.
NOTE: it is recommended that you create a special user that has Run As Service Account as well as the permissions to the folder and not use the Network Service.
- Go to VisualSVN Download and begin installation
- When prompted by the installation for a location for the share provide it with the share location that you have just setup.
- Set choose port 8443 for your port and complete the installation. If the installer gives you any warnings its likely that you have not given the Network Service its required permissions.
- Setup up port forwarding on your router. and you should then be able to access the Visualsvn from your Home Server url either http://server:8443/ if your inside your network or http://my-dynamic-dns.homeserver.com:8443/
The interesting thing about this is that while this is one of about 6 different ways i could count to do this installation while i found this the most straight forward for me YMMV.
October 9th, 2009 by Mark Harris
No comments »
Jeremy Miller tweeted this today which got me thinking. Jeremy’s comment was that being part of a small team mean that it mattered more. However i think that regardless of the team size or whether your a developer, a salesman, a business owner, you want an employee that will be committed to moving the business forward. A half interested developer will be bad for the entire team regardless of the size. For that matter any person not moving in the same direction of that team is not worth the hire, while just like Jeremy said it might be harsh but its just my opinion. 
Regardless of what the job is you want to find the most motivated individual. Sales people for example are motivated by great commission schemes. Interested Developers are generally motivated by good jobs and a great environment. Finding either a good job or a motivated developer is the hard bit. Simon Segal posted a while back about “Semi Invested Developers” and some ways to better understand the individual during the hiring process. If a developer was to have read his post in preparation for an interview and used some canned answers for those questions and managed to get hired he still shows more interest that one who has not bothered to take that step.
On a personal note I have reduced the number of hours I spent in front a computer since having my daughter (a time and energy vampire), however I have not lost my passion or motivation to better myself, and be a more interested developer. I find my self picking and choosing what tasks/technologies I will devote my attention to much more wisely, a skill that is very hard to acquire.
Just out of curiosity i created this poll to find out what people thought about hiring a half interested person /developer.
September 27th, 2009 by Mark Harris
No comments »
One of the great things that NServiceBus ships with is a dll called “NServiceBus.Testing” which provides us with the ability to easily test your sagas. This enables us to move forward with greater confidence in knowing that the code that we have written will function as expected when we move the code into integration testing and then production. Most of what i talk about here is in direct reference the 1.9 release of NServiceBus. If you have not seen how Saga’s are unit tested in NServiceBus have a read of Udi’s post on the forum. This post however is about how to test a Plain old Message Handler.
Let us being with looking at a sample handler.
1: public class FileProcessMessageHandler:IMessageHandler<ProcessFileMessage>
2: {
3: public IBus Bus { get; set; }
4: public IFileProcessor FileProcessor {get;set;}
5: public void Handle(ProcessFileMessage message)
6: {
7: if (FileProcessor.Run(message.FileIdentfier,message.FileSystemLocation))
8: {
9: var msg = Bus.CreateInstance<FileProcessedMessage>(m => {
10: m.FileIdentifier = message.FileIdentfier; });
11: Bus.Publish(msg);
12: }
13: else
14: {
15: Bus.Publish<UnknownFileTypeMessage>(m => {
16: m.FileIdentifer = message.FileIdentfier; });
17: }
18: }
19: }
This code in and of itself is highly testable. We have two interfaces that are injected into the class, excellent candidates for a mock. However when i first started down this path my first inclination was to use a manual mock, before moving on to trying to use Moq, however after spending time the fluent saga testing API in NServiceBus I realized that it was what was needed in this situation a MockBus.
MockBus is essentially the same as what is in the NServiceBus.Testing library. However because that version is geared towards testing sagas, it required changing the way the Saga class was created, and to allow for creating a version that would work with message handler. The new structure looks like the class diagram below.

What Changed
- The Saga class has become the MockBus class and no longer has the static method called Test() which created the Saga instance.
- The MockBusForSaga has the method CreateInstance<T> which replaces the Test() method in the old Saga class.
- Introduced a MockBusForMessageHandler which has a CreateInstance<T,TK>() method that creates the message handler.
Having this structure now enables us to write our tests for our message handlers very simply in a fashion that does not require to understand Rhino Mocks, though having a understanding of the errors you get from the mock bus is important as all the messages that are bubbled out are Rhino Mock Messages.
1: [Test]
2: public void when_file_processor_succeds_message_handler_will_publish_a_file_processed_message()
3: {
4: FileProcessMessageHandler msgHandler;
5: var mock_bus = MockBusForMessageHandler.CreateInstance
6: <FileProcessMessageHandler,ProcessFileMessage>(out msgHandler);
7: var fileID = Guid.NewGuid();
8: msgHandler.FileProcessor = SetupAndReturnFileProcessor(true);
9: mock_bus.ExpectPublish<FileProcessedMessage>(d => d.FileIdentifier == fileID)
10: .When(() => msgHandler.Handle(CreateProcessFileRequest(fileID)));
11: }
Lets have a look when make a call to CreateInstance<FileProcessMessageHandler,ProcessFileMessage>(out msgHandler)
1: public static MockBusForMessageHandler CreateInstance<T, TK>(out T handler)
2: where TK : IMessage
3: where T : IMessageHandler<TK>, new()
4: {
5: handler = (T) Activator.CreateInstance(typeof (T));
6: var mocks = new MockRepository();
7: var bus = mocks.DynamicMock<IBus>();
8: try
9: {
10: typeof (T).GetProperty(“Bus”, BindingFlags.Instance | BindingFlags.Public)
11: .SetValue(handler, bus, null);
12: }
13: catch
14: {/**swallow if they dont have a Bus defined in the class**/}
15: List<Type> typesToMap;
16: MessageMapper mapper = GetMapperAndInitialize(out typesToMap);
17: return new MockBusForMessageHandler(mocks, bus, mapper, typesToMap);
18: }
The beauty in this code is all hidden away in the MockBus (aka NServiceBus.Testing.Saga) thank you Udi for this,
The bus is instantiated when the object is created however no expectations are recorded until the When() method is called in the test just before the delegate is run. Once the delegate is run you will get the callbacks to the ExpectPublish where you can assert that not only did you get the correct type of message but the contents as well.
The code for this is available on the downloads page or go to it NServiceBus.Extensions.Testing download here
March 31st, 2009 by Mark Harris
5 comments »
About 2 weeks ago Simon and I started to work on building a fluent interface to configure WCF. Our main aim in doing so is to cover the the scenarios of configuring Services and Clients 80% (or 20%) of the time.
Our goals at this stage are
- Services over Basic HTTP or TCP
- Either No Security and Windows Transport Security
- No message level Security
- Include Service Meta Data
What this should enable us to do on the Service Host end would look like
var host = new WCFHost()
.AtAddress("http://localhost:8080/")
.UsingContract(typeof (IHelloService))
.WithBinding(new BasicHttpBinding())
.EnableMex()
.Start();
I expect more on this shortly.
del.icio.us Tags:
Fluent WCF,
.net
December 10th, 2008 by Mark Harris
No comments »
The last month has been really been one of change. I have moved both home and job and the dust has barely settled. What I can say with some certainty is that moving home is much harder than changing jobs.
During the last month there has been a few requests for Flickrlight and where its at. I still intend to move the code onto codeplex however the finding the time has been my greatest difficulty. If anyone has any experience with setting up a project on codeplex and is volunteering to help it will be appreciated.
October 31st, 2008 by Mark Harris
No comments »
A While back Ian Cooper blogged about the need for active development of LINQ To SQL, he had this to say
As a community, as people begin to realize the suprising power of LINQ to SQL, I would like to see us dispel many of the myths that seem to have grown up around that product. I would like to see us put pressure on the Data Platform team to provide the support for LINQ to SQL that we want going forward. Community reaction is everything and if the LINQ to SQL community remains silent in the face of the more vocal, but probably less numerous, EF community, we won’t get the product we deserve
David Hayden has made a call to Microsoft to Open Source the development of LINQ to SQL in response to the ADO.NET Teams announcement on the future of the Entity Framework and its
forgotten other LINQ To SQL.
The ADO.net team says that they will improve LINQ to SQL based on community feedback then there is please head what David Hayden and Ian Cooper are saying.
Simon Segal has previously made a Save LINQ to SQL badge which apart from bring really cool is apt.
So if you want to keep POCO objects free of the IPOCO interface (at least in V1 of EF), I would ask the Data Dudes to set LINQ To SQL Free as per David Hayden’s Suggestion.