ReSharper 4.5 - Tip #2 - Generate Members

One of the other developers on the team I'm on pointed out a very handy feature in R# yesterday. It is the "Generate Members" feature and can be accessed using Ctrl+Ins. This handy tool is like a central point to accessing the generation features in R#. The nice thing is that the generated members are placed at the current location and you can generate as many members as you like in one shot. This makes doing things like wrapping a bunch of private fields really easy. So, the next time you are using Alt+Enter (Quick Fix) to generate some code using R#, consider using Alt+Ins and see what it can do.

ReSharper 4.5 - Tip #1 - Wildcards in Go To Type shortcut

I tend to use the Go To Type shortcut in R# alot (ctrl+N for you keyboard junkies). It was only recently that I found out that you can use simple wildcards when using the shortcut.

In the above screenshot you can see that I'm looking for all classes that start with "Pet" and end with "View". I don't use this feature every time I want to jump to a type, but often I can't remember the exact name of a class but I'll know pieces of the name and this helps in those cases (it's especially helpful when I just know how the class name ends, eg. "*Presenter").

Build steps in Team Build

This is mostly for my own sake, but here's a link to the list of targets that are run during a Team Build on TFS 2008. Customizable Team Foundation Build Targets

Visual Studio Team System - The option that I've been missing all these years (Filter by Solution)

I've been using Team System for a number of years, and one thing that was frustrating was that the Pending Changes window showed all files in the current workspace. This becomes unmanageable when you have several projects sharing a workspace (whether that's "best practice" is irrelevant).

Today I happened upon the option that I've been thinking should exist but could never find: Filter by Solution.

Consistency in APIs

One thing that I feel is very important when building APIs is consistency in how method parameters are ordered. Abrams and Cwalina's Framework Design Guidelines talks about this as well.

I came across one instance of inconsistency that is a good example, I think. We're using MSTest for unit testing on our current project and so we make extensive use of it's "Assert" class. For most of the assertions that do a comparison between and expected and actual object, you pass the expected object first. For example:

Assert.AreEqual(Of T)(expected as T, actual as T)

or

Assert.AreSame(expected as Object, actual as Object)

And now we come to the exception.

Assert.IsInstanceOfType(value as Object, expectedType as System.Type)

When using the assertion for IsInstanceOfType, suddenly it takes the actual object in the first position. This becomes annoying because now I have to remember if I put the actual or expected object first every time I use an assertion method.

Additionally, they've also named the expected object parameter "value" instead of "expected".

So, when building APIs even if you are not planning on publishing them for devs outside of your project, remember to be consistent with parameter ordering and naming. It helps with discovery and adoption of the API.

Splitting PDFs

Today I needed to split up a PDF and went looking for a tool that would do that for me.  I came across the project named PDF Toolkit (http://www.accesspdf.com/pdftk/).

Using this tool I executed the following command and, voila, I had one PDF document for each page in my input document:

pdftk.exe input_file.pdf burst

Check the included .txt file for the full set of command-line parameters.

WCF service blocking when self-hosting (or How The ServiceBehavior's UseSynchronizationContext parameter saved me)

Today I was working on a feature in our application that uses WCF.  We wanted to make it possible to run the service piece in-process or as a service with minimal changes.  This is quite easy with WCF using the ServiceModelEx library from the iDesign crew.  Simply reference the ServiceModelEx.dll and wherever you'd normally create your WCF client proxy, just use the following code instead:

1. Dim channel = InProcFactory.CreateInstance(Of TServiceImpl, TServiceInterface)()

However, when I ran this code the first call on the client proxy hung and timed out.  I started digging into why it was timing out.  Eventually I remembered reading about WCF's ability to use a SynchronizationContext with the ServiceBehaviorAttribute.  Essentially WCF will use a SynchronizationContext to manage some of the threading issues that arise from writing a WCF service and/or client.  (See more here).  It gets even better when you are hosting a WCF service within a Windows Forms application.  In that case the WCF service will grab the WinForm SynchronizationContext that manages threading of the UI thread.

It turns out that was exactly my problem.  Using the InProcFactory (which uses the Named Pipe binding to host the service implementation in the same process as the client) my service was being hosted in my WinForms application.  This caused the default WCF behaviour of attaching to the UI thread's SynchronizationContext to occur.  When I called my WCF service, the service blocked because the WCF client proxy was invoked from the UI.  When the timeout occurred and the client-side had finished with the UI thread, the service happily proceeded to execute (which was far too late at this point).

The Solution

The solution turns out to be extremely easy.  The ServiceBehaviorAttribute can be applied to your WCF service implementation.  One of the parameters to that is "UseSynchronizationContext".  Set that to false on your service and the service will create it's own SynchronizationContext and your client will no longer block when hosting the service in process.

1. ServiceBehavior(ConcurrencyMode:=ConcurrencyMode.Reentrant, UseSynchronizationContext:=False)> _
2. Public Class MyService
3.              Implements IMyService