I’ve been using MassTransit over NServiceBus lately … for reasons I won’t delve into now.

Sometimes there is an error when processing a message and it gets thrown in the [name of queue]_error queue. If you have some logging or monitoring setup, you will get messages about the error and want to re-process those messages.

MassTransit comes with another utility called BusDriver that is a command line tool that can move messages from one queue to another.

To just move one message

> BusDriver.exe move –from “msmq://localhost/queue_name_error” –to “msmq://localhost/queue_input”

You can also provide another argument, “-count” that takes the number of messages to move.

> BusDriver.exe move –from “msmq://localhost/queue_name_error” –to “msmq://localhost/queue_input” –count “20”

The above command will move 20 messages from my queue named “queue_name_error” to “queue_input”

Pretty nifty.

There are some other commands in the program that I have not used yet, but feel free to take a gander from the source code @ https://github.com/MassTransit/MassTransit/blob/master/src/Tools/BusDriver/CommandParser.cs


    email = joseph.vano@gmail.com
    name = Joey Vano
    autocrlf = false
    external = c:/users/jvano.fcs/difftool.sh

    keepBackup = false;
    tool = p4merge

[mergetool "p4merge"]
    cmd = "p4merge.exe" "$BASE" "$LOCAL" "$REMOTE" "$MERGED"
    keepTemporaries = false
    trustExitCode = false
    keepBackup = false
    ui = auto

Just dropping some stuff on my blog to keep as reminders

  • ctags
  • matchit
  • NERD commenter
  • NERD tree
  • snipmate
  • sparkup
  • surround
  • taglist
  • ragtag
  • a.vim

Resources for plugins and learning Vim:

call pathogen#runtime_append_all_bundles()

syntax on
filetype plugin indent on
set tabstop=2
set smarttab
set shiftwidth=2
set autoindent
set expandtab

let mapleader= ","

set nocompatible
source $VIMRUNTIME/vimrc_example.vim
source $VIMRUNTIME/mswin.vim
behave mswin

set diffexpr=MyDiff()
function MyDiff()
  let opt = ‘-a –binary ‘
  if &diffopt =~ ‘icase’ | let opt = opt . ‘-i ‘ | endif
  if &diffopt =~ ‘iwhite’ | let opt = opt . ‘-b ‘ | endif
  let arg1 = v:fname_in
  if arg1 =~ ‘ ‘ | let arg1 = ‘"’ . arg1 . ‘"’ | endif
  let arg2 = v:fname_new
  if arg2 =~ ‘ ‘ | let arg2 = ‘"’ . arg2 . ‘"’ | endif
  let arg3 = v:fname_out
  if arg3 =~ ‘ ‘ | let arg3 = ‘"’ . arg3 . ‘"’ | endif
  let eq = ”
  if $VIMRUNTIME =~ ‘ ‘
    if &sh =~ ‘\<cmd’
      let cmd = ‘""’ . $VIMRUNTIME . ‘\diff"’
      let eq = ‘"’
      let cmd = substitute($VIMRUNTIME, ‘ ‘, ‘" ‘, ”) . ‘\diff"’
    let cmd = $VIMRUNTIME . ‘\diff’
  silent execute ‘!’ . cmd . ‘ ‘ . opt . arg1 . ‘ ‘ . arg2 . ‘ > ‘ . arg3 . eq

colorscheme xoria256
set ic
set wildmenu
nmap <silent> <leader>, :NERDTreeToggle<CR>

set number
set nowrap
syntax on
filetype on

cd C:\dev\dovetail.search\branches\2.0\

set tag=c:\temp\ctags\seeker

nmap <silent> <leader>tt :TlistToggle<CR>
nmap <silent> <leader>n :silent :nohlsearch<CR>

Creating Windows Installers is no fun.  Seriously, no fun.  The feedback cycle is way too long.  In order to shorten the cycle, here are a few command-line options to use to speed it up.

This will install the package with no UI at all (headless):

msiexec /i MyInstaller.msi /qn
It will save you time you don’t have to keep clicking “Next” … “Next”, “Finish”.  This will vary depending on how complicated your Install UI Sequence is.
This will uninstall the package without prompting you to confirm the action:
msiexec /x MyInstaller.msi /qn

Here are options I use frequently:
  • /i
    • install the package
  • /qn
    • shows no user interface
  • /x
    • uninstall the package
  • /l*v [path to log file]
    • verbose logging
If you are trying to debug the installation, use the log option with a tail:
/msiexec /i MyInstaller.msi /qn /l*v installer.log

I just finished watching a session by Remy Sharp at NDC 2010 on jQuery.

I highly recommend checking out his session as it’s not your starter jQuery talk.

Here are a few of the tips:

  • Event delegation: live vs delegate, delegate FTW
    • Live checks from the top of the document.
    • Live is slower
    • Delegate will listen at a specific point instead of the whole document.  Event bubbling will only happen at the element you specify
  • Avoid the DOM, try to do as much preprocessing as possible before using append or any other type of manipulation

Don’t do this:

$("#foo").css({ top: "20px", left "100px" })

Use CSS classes instead.  It’s cleaner markup and it really is where you should be controlling your presentation markup.


  • Traversing: find vs context

Using $(“#foo”).find"(p”) to find all the ‘p’  tags is faster than $(“p”, “#foo”) since it uses it under the former underneath the hood.

  • Avoid .get(0).  Just use [0] if you need to get the first element.  Same reason as above.
  • Use $(“#foo”).bind(“click”,fn) vs $(“#foo”).click(fn)
    • The click|mouseover|blur|etc methods are shortcuts for the bind method.
  • Use $.data(this, key) vs. $(this).data(key)
    • Same reason as above
  • $(“div”).length to check of there any matched elements.  Simple, but effective before you go on processing anything.

Check the video to see the rest of the tips.  NDC put up a torrent link for all 121 sessions that comes in a whopping 56GB!

In SharePoint,  inline code is not allowed.  If you need to add some inline code to an aspx page, there is a setting in the web.config that must be set. 

The following XML is wrapped in the SafeMode node. 

   1: <PageParserPaths>

   2:     <PageParserPath VirtualPath="/pathtopage/*" CompilationMode="Always" AllowServerSideScript="true" />

   3: </PageParserPaths>

Remember to change the VirtualPath attribute to your specific path where inline code is to be expected.  This should be set conservatively to now allow all pages with inline code.

Test Driven Development By Example outlines a few strategies for getting your tests to green.

  1. Fake It
    1. This is the quickest way to get it green.  Simply supply a constant value at first to get it passing.  Once it turns green, replace it with  a variable and continue until you have the real code that is needed there.
  2. Use Obvious Implementation
    1. If you are confident and you know the correct implementation, simply write it.  The test will validate that you are right.
  3. Triangulation
    1. Write two or more examples that generalize code.  This is the most conservative approach.

These strategies can be used interchangeably when doing TDD.  If you put it on a scale of when to use which strategy, Obvious Implementation is on the far left, being the most free and not needing to check with dummy values.  The far gaspedalright is Triangulation.  It requires multiple examples to validate the code.   This does create some duplication, but enables you to make small steps in the code.

When coding, you can use these strategies like a gas pedal.  If you know the implementation, step on the pedal and use Obvious Implementation.  But if you hit a red light, time to switch gears and maybe go to Fake It or Triangulation to get back green.

From time to time you may come across a customer who needs to get data from a 3rd party or external application into their internal database.  One of the easiest integration solutions is to FTP (File Transfer Protocol) the file to a folder that can be picked up for further processing or an ETL (Extract Transform Load) process.

I won’t show the code that picks up the file automatically, but I will show how you can use SSIS (SQL Server Integration Services) to get the flat file into the existing infrastructure.

One of my use cases was that the file was always going to have a different name each time it was uploaded.  For that I created a variable in SSIS at the Package Scope level.image

Next we have modify the File Connection in order to have it reference the variable.  We want to set the ConnectionString property to the variable filename we created above.  SSIS has a interesting syntax when referencing variables where they are prefixed with @ symbol.

To get to the screen below, select the object and hit F4 to bring up the properties pane. Expand the Expressions property and click on the button next to it to bring up the dialog below.


Once you have created your package in Business Intelligence Studio, copy that .dtsx file to your bin folder of your C# library that will execute the package programmatically.  This will give us a common location to execute the package.

In your C# project, add a reference to Microsoft.SQLServer.ManagedDTS.  In my case I have two different versions since I have both SQL Server 2008 and SQL Server 2010 installed on my box.  Select the appropriate one for your environment.


In the code sample below, it shows how easy it is to execute the package from code.

   1: public string ExecutePackage(string filePath, string packageName)

   2: {

   3:     DTSExecResult results;


   5:     var path = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, packageName);

   6:     var app = new Application();

   7:     var pkg = app.LoadPackage(path,null);


   9:     Variables variables = pkg.Variables;

  10:     variables["filename"].Value = filePath;


  12:     results = pkg.Execute(null, variables, null, null, null);


  14:     string result = "";

  15:     if(results == DTSExecResult.Success)

  16:     {

  17:         // log

  18:         result = "Success";

  19:     }

  20:     else

  21:     {

  22:         // log

  23:         result = "Failure";

  24:     }


  26:     return result;

  27: }

NServiceBus can be configured for logging with log4net.  It is also a good practice to keep your logging configuration in a separate file.

In your [web | app].config file add the following lines:

   1: <configSections>

   2:     <section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler, log4net"/>

   3: </configSections>


   5: <log4net configSource="log4net.config" />

In your service bus bootstrap code simply add Log4Net() extension method:

   1: var bus = NServiceBus.Configure

   2:    .WithWeb()   // in a web context

   3:    .Log4Net()   

   4: // rest of config ommitted

That’s it!  Remember you can control the logging level within the configuration file also by specifying the namespace and the logging level.

The following configures the NServiceBus.Utils and NServiceBus.Unicast to log only INFO levels:

   1: <logger name="NServiceBus.Utils">

   2:   <level value="INFO" />

   3: </logger>


   5: <logger name="NServiceBus.Unicast">

   6:   <level value="INFO" />

   7: </logger>