The core of the issue is that ClientBase<T> implements IDisposable. With this knowledge, just about any programmer would naturally wrap its usage in a using{} block. Digging deeper, you'll find that the ClientBase<T> Dispose() method simply calls Close() on the underlying connection. This is problematic because in certain connection states (such as "Faulted"), the Close() will fail. As I said, this is well documented elsewhere, for example: on MSDN, Stack Overflow, and here.

There are a few different solutions to this issue. I went with a simple Disposable wrapper...

// Get a disposable MyClientWrapper object
using(var clientWrapper = ClientFactory.GetMyClientWrapper())
{
    clientWrapper.Client.DoSomething();
}
 
public class MyClientWrapper : IDisposable
{
    private readonly MyClient _client;
 
    public MyClientWrapper(Binding binding, Uri endpoint)
    {
        // creates an instance of MyClient, which is derived from ClientBase<T>
        _client = new MyClient(binding, new EndpointAddress(endpoint.ToString()));
    }
 
    public MyClient Client
    {
        get { return _client; }
    }
 
    public void Dispose()
    {
        // safe dispose with extension method (below)
        _client.CloseProxy();
    }
}
 
// extension method for safe Close() on ClientBase<T>
public static void CloseProxy(this ClientBase<T> proxy) where T : class
{
    try
    {
        if (proxy.State != CommunicationState.Closed 
                && proxy.State != CommunicationState.Faulted)
        {
            proxy.Close(); // may throw exception while closing
        }
        else
        {
            proxy.Abort();
        }
    }
    catch (CommunicationException)
    {
        proxy.Abort();
        throw;
    }
}

The first thing I was doing...
> ps aux | grep Foo
find the process ID (PID) with my eyes, and then kill it...
> kill -9 123456

Next, I started finding complex piped commands to find and extract the PID. For instance...
> pid=`ps -eo pid,args | grep Foo | grep -v grep | cut -c1-6`

and slightly simpler...
> ps aux | grep Foo | grep -v grep | awk '{print $2}'

Finally, I discovered pgrep and pkill. There are quite a few options for each command, but simply put:

To get the PID for a process with a name containing 'Foo'...
> pgrep Foo

To get the PID for a process with a command line containing 'Bar' (as in > Foo -n Bar)...
> pgrep -f Bar

Let's say we have a repository that gets documents from a database.  The assumption is that a repository interface, IDocumentRepository, is being implemented.

In my case, I found it easier to deserialize results from file, rather than building the results by hand for each mocked response.  I used System.Xml.Serialization to serialize real responses to file.

Let's Moq it...

var mockRepository = new Mock<IDocumentRepository>();
 
// if the query is for text/plain documents only, mock a response for that
mockRepository.Setup(p => p.FindDocuments(
	It.Is<DocumentQueryParams>(q => q.MimeType == "text/plain")))
	.Returns(DeSerializeResults<List<Document>>("TextDocuments.xml"));
 
// use It.IsAny to return the same result regardless of the parameters
mockRepository.Setup(p => p.FindDocuments(
	It.IsAny<DocumentQueryParams>()))
	.Returns(DeSerializeResults<List<Document>>("AllDocuments.xml"));

Implement a custom XmlUrlResolver to find schema references as embedded resources.

public class ManifestResourceResolver : XmlUrlResolver
{
    private readonly Assembly _resourceAssembly;
    private readonly string _baseNamespaceForReferences;
 
    public ManifestResourceResolver(Assembly resourceAssembly, string baseNamespaceForReferences)
    {
        _resourceAssembly = resourceAssembly;
        _baseNamespaceForReferences = baseNamespaceForReferences.EndsWith(".") ? baseNamespaceForReferences : baseNamespaceForReferences + ".";
    }
 
    override public object GetEntity(Uri absoluteUri, string role, Type ofObjectToReturn)
    {
        if (absoluteUri.IsFile)
        {
            var file = Path.GetFileName(absoluteUri.AbsolutePath);
            var stream = _resourceAssembly.GetManifestResourceStream(_baseNamespaceForReferences + file);
            return stream;
        }
        return null;
    }
}

Create a XmlSchemaSet, and set the XmlResolver property to the custom resolver implemented above. Then, load up the main XSD schema.

var xmlSchemaSet = new XmlSchemaSet();
xmlSchemaSet.XmlResolver = new ManifestResourceResolver(Assembly.GetExecutingAssembly(), "MyApp.Schemas");
using (var stream = Assembly.GetCallingAssembly().GetManifestResourceStream("MyApp.Schemas.MainSchema.xsd"))
{
    var xmlSchema = XmlSchema.Read(stream, null);
    xmlSchemaSet.Add(xmlSchema);
}

Create a XmlReaderSettings object and set the Schemas property to the schema set loaded above. Lastly, load up an XML file with an XmlReader and read it.

XmlReaderSettings settings = new XmlReaderSettings();
settings.ValidationType = ValidationType.Schema;
settings.Schemas = xmlSchemaSet;
settings.ValidationEventHandler += new ValidationEventHandler (ValidationCallBack);
 
XmlReader reader = XmlReader.Create("SomeXml.xml", settings);
while (reader.Read());

The validation callback function will be invoked on each validation error while reading the file with the XmlReader.

private static void ValidationCallBack(object sender, ValidationEventArgs e)
{
    Console.WriteLine("Validation Error: {0}", e.Message);
}

References:

• Validation Using the XmlSchemaSet
• Loading XmlSchema files out of Assembly Resources
  (contains some obsoleted code, but it was still helpful)

First, we'll want to create an interface for our database session.  The implementation of this interface can be swapped out depending on the backing store.

1
2
3
4

public interface ISession : IDisposable
{
    System.Linq.IQueryable<T> All<T>() where T : class, new();
}

Add a MongoDB implementation of ISession.  This implementation will eventually be used in our repository.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

public class MongoSession : ISession
{
    private readonly IMongo _provider;
 
    public MongoSession()
    {
        //this looks for a connection string in your Web.config
        //<connectionStrings>
        //  <add name="db" connectionString="mongodb://localhost/testdb?strict=true"/>
        //</connectionStrings>
        _provider = Mongo.Create("db");
    }
 
    public IQueryable<T> All<T>() where T : class, new()
    {
        return _provider.GetCollection<T>().AsQueryable();
    }
 
    public void Dispose()
    {
        _provider.Dispose();
    }
}

Create an interface for the repository.  This is what the controller will expect to be injected via it's constructor.

1
2
3
4

public interface IRecipeRepository
{
    IEnumerable<RecipeCard> GetAll(int page = 1, int pageSize = 10);
}

Add the IRecipeRepository implementation, which is created with a new()-able type of ISession.  Why didn't I just inject an ISession into the repository?  It's because Mongo sessions are expected to be disposed of after use, as connections are pooled and reused.  Therefore we have to create and dispose of our sessions when using them.  This might require some workarounds if you really did switch repositories (do nothing on Dispose(), etc).

1
2
3
4
5
6
7
8
9
10

public class RecipeRepository<SessionT> : IRecipeRepository where SessionT : ISession, new()
{
    public IEnumerable<RecipeCard> GetAll(int page = 1, int pageSize = 10)
    {
        using (var session = new SessionT())
        {
            return session.All<RecipeCard>().OrderByDescending(r => r.UpdatedDate).Skip(pageSize * (page - 1)).Take(pageSize).ToList();
        }
    }
}

Now it's time set up our IoC container.  We'll do this in the Global.asax.cs.  Here we are registering a recipe repository of type MongoSession such that any controller that expects an IRecipeRepository in the constructor will get this.  We're letting Autofac handle controller creation and dependency injection.  See the Autofac MVC3 integration page for more details.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

protected void Application_Start()
{
    var builder = new ContainerBuilder();
    builder.Register(r => new RecipeRepository<MongoSession>()).As<IRecipeRepository>().InstancePerLifetimeScope();
    builder.RegisterControllers(Assembly.GetExecutingAssembly());
 
    var container = builder.Build();
    DependencyResolver.SetResolver(new AutofacDependencyResolver(container));
 
    AreaRegistration.RegisterAllAreas();
 
    RegisterGlobalFilters(GlobalFilters.Filters);
    RegisterRoutes(RouteTable.Routes);
}

Finally, here is our controller.  Notice we never have to create a repository object - one was injected for us.

1
2
3
4
5
6
7
8
9
10
11

private readonly IRecipeRepository recipeRepository;
 
public RecipesController(IRecipeRepository recipeRepository)
{
    this.recipeRepository = recipeRepository;
}
 
public ViewResult Index()
{
    return View(recipeRepository.GetAll());
}

That's it.

I decided this was a good time to give MVC3 and MongoDB a test drive.  After diving in, I realized that I could benefit from some dependency injection via MVC3's DependencyResolver.  I've been wanting to learn Autofac, so I threw that in as the container.  This was sweet, as it injected my repository implementations into my controllers with very little setup.

At this point, I've learned all about the Razor view engine, DI with Autofac and DependencyResolver, MongoDB with the NoRM driver, jQuery, jQuery-ui, and some other MVC3 goodness.

For various reasons, including the fact that my web hosting provider is a Linux/non-ASP.NET provider, I ported the whole thing to Rails/MySql.  I'm glad I went through the MVC3 process, because I learned a lot, but in the end, Rails is just simpler.  As for MongoDB, and NoSQL in general, I think it's best served as an edge case storage medium for fast read operations.  Data is relational.

Alas, here is a screenshot of the recipe database.  I'll be adding lots of features, including menus and weight management.  You can't see it here, but it has a cool tag cloud feature and theme switching.

The UI is pretty lame, but it works...

I just installed Windows Live Writer as a tool to publish stories to my web site.  It has some promising features, and works with WordPress (yay MS).

I also just installed DropBox because I've been meaning to find a way to create offsite copies of some of our important files.  I haven't tried it yet, but I hear good things about it.

Hmm, now that I'm about to publish, I'm wondering if it will handle WordPress tags... it did not.

I know the sidebar isn't very elegant (especially the photos/movies/music links). I am soooo bad at design. Fooling around with those 3 links took longer than anything else I've done with this update. Every time I tried to get fancy, the layout would go to hell. I have grand ideas - really.