.Net Head

Integrating ASP.NET SQL Registration with Entity Framework Code First

Ken — Sun, 20 May 2012 02:19:10 +0000

I am using Microsoft’s Entity Framework 4.1′s Code First approach to rapidly develop a basic MVC 3 application for a friend of mine. The app is also leveraging the standard MVC Internet Website template and its build-in membership management functionality. Hence it uses the SQL Membership Provider which adds a bunch of tables to the database by means of the aspnet_regsql.exe utility. Thus not all database access is via the EF.

To get it all working together, my initial, naive approach was to use the utility to generate the SQL script needed to build out the database and then execute that script as part of the Seed() method of my database initializer. (I was subclassing both DropCreateDatabaseIfModelChanges for my website and DropCreateDatabaseAlways for my automated tests.)

The method to actually execute the script looked like this:

public static void ExecuteSqlSript(Database database, string scriptPath)
{
    var conn = database.Connection;
    if (conn.State == ConnectionState.Closed)
        conn.Open();
 
    var fullScript = File.ReadAllText(
        scriptPath);
 
    foreach (var command in Regex.Split(fullScript, @"\bGO\b"))
    {
        var cmd = conn.CreateCommand();
        cmd.CommandText = command;
        try
        {
            cmd.ExecuteNonQuery();
 
        }
        catch (Exception e)
        {
            throw new ApplicationException(e.Message + 
                "\r\n\r\nCommand: " + command, e);
        }
    }
}

This worked great for my first few iterations, until I needed to add a model to the framework to represent some of the data on the aspnet_User table.

Mapping my new User entity to the existing table name was easy. It just required adding the following to my DbContext implementation:

protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
    base.OnModelCreating(modelBuilder);
    modelBuilder.Entity<User>()
        .ToTable("aspnet_Users");
    modelBuilder.Entity<User>()
        .Property(u => u.Name).HasColumnName("UserName");
}

This lead to the aspnet_regsql generated script failing because EF now was creating the aspNet_User table before the script ran. So my next step was to hack the script by adding the following just before the code to create the table:

IF EXISTS (SELECT name
                FROM sysobjects
                WHERE (name = N'aspnet_Users')
                  AND (TYPE = 'U'))
   AND NOT EXISTS(SELECT * FROM sys.COLUMNS 
                  WHERE Name = N'ApplicationId'  
                    AND Object_ID = Object_ID(N'aspnet_Users'))
BEGIN
	--This indicates the presense of a the table 
        --as created by the Entity Framework Code First
	--My EF schema does no use/create the full table 
        --so just drop it so that the script below will do its job.
    DROP TABLE [dbo].aspnet_Users
END
 
IF (NOT EXISTS (SELECT name
                FROM sysobjects
                WHERE (name = N'aspnet_Users')
                  AND (TYPE = 'U')))
BEGIN
  PRINT 'Creating the aspnet_Users table...'
/* Actual CREATE TABLE statement omitted for brevity...

This was a hack, but this was rapid development of the “just get it working” sort. And it worked great, until I added a new model that referenced a user, like so:

public class Record
{
    public int RecordId { get; set; }
 
    public Guid UserId { get; set; }
 
    [Required]
    [ForeignKey("UserId")]
    public virtual User Recorder { get; set; }
 
    [MaxLength(4000)]
    public string Notes { get; set; }
}

This busted my hack because I could no longer just drop the table. There was now a foreign key constraint that had to be deleted first. While I could certainly patch my hack to drop the key too, with more foreign keys on the horizon, it was obvious that this approach was going to quickly become unmanageable.

The problem was that, especially for my automated tests, I wanted to drop and recreate the database regularly. The right solution, therefore was to somehow execute the aspnet_regsql script after EF created the database itself, but before EF built out any tables. If I could do that, EF was smart enough to just use the existing aspnet_User table.

In my search for a solution, I found this article which described how to create a database initializer that would just drop all the table and recreate them w/o dropping and recreating the database itself. This seems promising but its approach to dropping all the tables didn’t account for foreign keys or any other objects that might need dropped too. Modifying it to do so might be possible but could also become a real maintenance headache. My concern was how complex the code would become to find and drop all dependencies which my code might create against the aspnet tables w/o dropping those that the aspnet_regsql script itself created. It might be easy; it might not. I still felt that simply dropping the whole database and rebuilding it was the best approach. So I set out to find a way to inject some functionality between EF’s database creation and schema build out actions. I posted on the EF forum and got a suggestion to try migrations. That wasn’t a bad idea, but still seemed more complicated than I wanted.

Going back to the blog on custom initialization strategies, I looked harder at the provided code, and googled around for some additional examples of custom strategies and in the end was able to come up with a custom initializer that did what I wanted. It

drops the database (conditionally or always, base on a constructor arg).
creates the database itself.
runs the aspnet_regsql script.
uses EF to build out the remaining schema.

Without further adue, here is the code:

using System;
using System.Data;
using System.Data.Entity;
using System.Data.Entity.Infrastructure;
using System.Data.SqlClient;
using System.IO;
using System.Text.RegularExpressions;
using System.Transactions;
 
public class CreateDatabaseWithAspNetRegSql<TContext> 
    : IDatabaseInitializer<TContext>
    where TContext : DbContext
{
    public enum CreationStrategy { AlwaysCreate, CreateIfModelChanged }
 
    private readonly CreationStrategy _creationStrategy;
 
    public CreateDatabaseWithAspNetRegSql(
        CreationStrategy creationStrategy)
    {
        _creationStrategy = creationStrategy;
    }
 
    #region IDatabaseInitializer Members
 
    public void InitializeDatabase(TContext context)
    {
        bool dbExists;
        using (new TransactionScope(TransactionScopeOption.Suppress))
        {
            dbExists = context.Database.Exists();
        }
        if (dbExists)
        {
            if (_creationStrategy == CreationStrategy.CreateIfModelChanged
                && context.Database.CompatibleWithModel(false)) 
                return;
 
            context.Database.Delete();
        }
 
        CreateDatabase(context);
 
        DbInitializer.DoAspNetRegSql(context.Database);
 
        CreateTablesForModels(context);
 
        Seed(context);
        context.SaveChanges();
    }
 
    #endregion
 
    #region Private/Protected Methods
 
    private static void CreateDatabase(TContext context)
    {
        var masterDbConnString = context.Database
            .Connection.ConnectionString
            .Replace(context.Database.Connection.Database, "master");
 
        //TODO: Find way to create db in an agnostic way.
        using (var conn = new SqlConnection(masterDbConnString))
        {
            conn.Open();
 
            using (var cmd = conn.CreateCommand())
            {
                cmd.CommandText = string.Format("CREATE DATABASE [{0}]", 
                    context.Database.Connection.Database);
                cmd.ExecuteNonQuery();
            }
        }
    }
 
    private static void DoAspNetRegSql(Database database)
    {
        //TODO: This file name reference is a hack, 
        //need a better way of handling this!
        ExecuteSqlSript(database, @"C:\Users\Ken\Documents\Visual Studio 2010\Projects\MVCSandbox\_Resources\aspnet_regsql.sql");
    }
 
    protected static void ExecuteSqlSript
        (Database database, string scriptPath)
    {
        var conn = database.Connection;
        if (conn.State == ConnectionState.Closed)
            conn.Open();
 
        var fullScript = File.ReadAllText(
            scriptPath);
 
        foreach (var command in Regex.Split(fullScript, @"\bGO\b"))
        {
            var cmd = conn.CreateCommand();
            cmd.CommandText = command;
            try
            {
                cmd.ExecuteNonQuery();
 
            }
            catch (Exception e)
            {
                throw new ApplicationException(e.Message + 
                    "\r\n\r\nCommand: " + command, e);
            }
        }
    }
 
    private static void CreateTablesForModels(TContext context)
    {
        var modelBuildoutScript = ((IObjectContextAdapter)context)
            .ObjectContext.CreateDatabaseScript();
 
        RemoveTableCreationCommandsForTablesCreatedByAspNetRegSql(ref modelBuildoutScript);
 
        context.Database.ExecuteSqlCommand(modelBuildoutScript);
    }
 
    private static readonly Regex __aspNetCreateTableCommandFinder 
        = new Regex(@"create table \[dbo\]\.\[aspnet_\w+\][^;]*;");
 
    private static void RemoveTableCreationCommandsForTablesCreatedByAspNetRegSql
        (ref string script)
    {
        script = __aspNetCreateTableCommandFinder.Replace(script, string.Empty);
    }
 
    #endregion
 
    #region Public Methods
 
    protected virtual void Seed(TContext context)
    {
 
    }
 
    #endregion
}

Rebasing can fail with an updated .gitignore file.

Ken — Wed, 07 Dec 2011 05:43:32 +0000

When using version control and working on a branch other than the master, one should periodically pull any changes made to master into the working branch. If you are using Git, the preferred way to do this is with the rebase command rather than merge. (Here is a good explanation of the difference between the two and why rebase is usually preferred.)

However, rebase sometimes does not work as you would like. I hit a good example of this this evening and wanted to document it. The scenario is that of working on my own working branch of a rails project where we had just started using RubyMine. I had created my working branch just prior to switching to RubyMine. To my chagrin, I discovered that RubyMine had created a bunch of files to manage its view of the project in a folder named .idea, and I had committed them in my branch.

In the meantime another developer discovered the same issue and coincidentally added the .idea directory to .gitignore on master. The natural thing to do, I thought, was to rebase my branch on master. I was promptly told that I could not do this. I failed to capture the exact error message, but basically the problem was that rebase was attempting to replay the addition of files to the .idea directory on top of a git repository that now called for the .idea directory to be ignored.

Because I only had a few commits on my branch, I decided the quick solution would be to create a new working branch based on the current master and then cherry-pick my commits from the old working branch onto the new one.

My first cherry-pick command resulted in a “commit not found error.” I thought this was very odd, but in examining the contents of the commit I was attempting to cherry-pick, it turns out that it only contained files in the .idea directory. So it seems a better error message would have been “nothing found in the commit.”

Seeing as I could safely omit that commit, I went on to cherry-pick the remaining ones. Each failed initially due to merge errors, because each attempted to modify files under .idea. To solve this I had to execute a git rm -f command for each such file to resolve the conflict.

After resolving the conflict, I followed the onscreen instructions that were given at the point that the cherry-pick failed. Namely to run the commit -c command specifying the hash of the commit I had cherry-picked.

The -c option creates a new commit with the same message and author as the one referenced by the hash. I had not seen this option before and as it turns out I really wanted to use the capitalized -C version. Both do the same thing but the lowercase version throws you into vi to edit the commit message where as the uppercase one uses the commit message as-is.

Fluent APIs Violate the Open/Closed Principle

Ken — Sun, 20 Nov 2011 17:40:36 +0000

In a recent design session, we were discussing the API for an event bus that supports asynchronous RPC. A colleague of mine proposed a fluent interface. A simplified version of it looked roughly like this:

bus.for(event).replyTo(handler).withATimeOutOf(500).Send();

The proposal lead to some debate because some members of the team liked the idea and others preferred the more traditional approach of using overloaded methods as follows.

bus.Send(event, replyHandler);
bus.Send(event, replyHandler, timeout);

In the end it was agreed that the traditional API was essential, and if some of the team wanted a fluent API, one could be written as a wrapper around it.

I think this was the right call and the point of this post is to explain why. One of the reasons that was given against the fluent interface was that they are very hard to extend if you do not have the ability to modify the original source. In short, they violate the Open/Closed Principle, one of the core principles of SOLID object oriented design.

Lets take a look at why.

Here is a pseudo implementation of the fluent API.

class Builder
{
    Builder for(IEvent event) { ... ; return this }
    Builder withReplyTo(IHandler handler) { ... ; return this }
    Builder withATimeOutOf(int milliseconds) { ... ; return this }
    void send() { ... }
}

Omitted is the operative code that would collect the various arguments and ultimately invoke the base API in Send(). What remains is just what is needed to do the fluent call chaining, namely returning an instance of the builder itself. It is this return value that violates OCP.

Suppose a third party wants to add a second event handler to be invoked in case of a timeout. We will presume the base Bus class is otherwise well factored and adheres to OCP. Because of this, adding a new Send overload to the traditional API can be achieved by subclassing the base implementation. Invoking the new method will look like this.

bus.Send(event, replyHanlder, timeout, timeoutHandler);

But what happens if we try to extend our fluent API by subclassing the Builder?

class NewBuilder : Builder 
{
    NewBuilder andHandleTimeoutsWith(ITimeoutHanlder handler)
    { 
        ...
        return this;
    }
}

Now we see the problem with the base class methods returning Builder. From our subclass, even if the return value is actually an instance of MyBuilder, it is returned by the inherited members as Builder. In a statically typed language, the new method is not accessible without a very un-fluent explicit cast.

A Generic Solution?

In a simple API, if the original designers are prescient enough, one might get around this by using generics. Suppose the orignal builder had been written generically.

class Builder<T> where T : Builder
{
    T for(IEvent event) { ... ; return this }
    T andReplyTo(IHandler handler) { ... ; return this }
    T for(int milliseconds) { ... ; return this }
    void send() { ... }
}

As can be seen, we still need the non-generic Builder so that the generic one can be instantiated in terms of it. If we would normally access the fluent API like so: bus.GetFluentBus(), we could then access our extended API like this: bus.GetFluentBus().

This approach gives us a builder that complies with OCP. The down side is we have muddied up our GetFluentBus method with a generic argument just to allow for what is likely to be an edge case. But supporting edge cases is what extensibility is all about.

A bigger problem is that the generic approach only works well for a simple, single-builder API. Most fluent interfaces use a set of builder classes and/or interfaces in order to limit the methods available at any point in the call chain to those that make sense. In this scenario, genericizing the API gets ugly. Every builder will need to be generic not only with respect to itself but with respect to every builder that it returns directly or indirectly, and our GetFluentBus method is going need generic arguments for all of them. Consequently, generics are not a good general purpose solution.

Conclusion

Fluent APIs do have an appeal and a legitimate place in software design. However, they are not extensible and therefore should never be the only means of doing something. Rather they need to be seen as an augmentation and approached with the understanding that their purpose is to make the common use cases fluent for those who want the option.

How to Change your App.Config Location file at Run Time

Ken — Thu, 04 Aug 2011 00:43:28 +0000

This is one of those pieces of functionality which I have been in search of for a long time. When writing integration tests and other automated tests, you frequently want to test with different application configurations. Unfortunately, switching App.Config files on the fly is not something that the .Net framework supports. There are some alternative approaches to this problem which rely on dependency injection or using AppDomains. Depending on what you are trying to accomplish, these are not always simple or satisfactory techniques. This is especially the case when performing integration tests with third party components that rely on app.config settings and you want to test out alternatives of those settings.

But today, I found this great solution provided by Daniel Hilgarth on StackOverflow. It is something of a hack in that it relies on mucking with the internals of how AppDomains work. I don’t think I would recommend it for production code, but for automated testing, its just what the doctor ordered.

Here is my slightly modified version of the code, as well as a usage example. Please take a look at the example in the article as well, you may like it better.

using System;
using System.Configuration;
using System.Linq;
using System.Reflection;
 
public class AlternateAppConfig : IDisposable
{
    private readonly string oldConfig =
        AppDomain.CurrentDomain.GetData("APP_CONFIG_FILE").ToString();
 
    private bool disposedValue;
 
    public AlternateAppConfig(string path)
    {
        AppDomain.CurrentDomain.SetData("APP_CONFIG_FILE", path);
        ResetConfigMechanism();
    }
 
    public void Dispose()
    {
        if (!disposedValue)
        {
            AppDomain.CurrentDomain.SetData("APP_CONFIG_FILE",oldConfig);
            ResetConfigMechanism();
 
 
            disposedValue = true;
        }
        GC.SuppressFinalize(this);
    }
 
    private static void ResetConfigMechanism()
    {
        typeof(ConfigurationManager)
            .GetField("s_initState", BindingFlags.NonPublic |
                                        BindingFlags.Static)
            .SetValue(null, 0);
 
        typeof(ConfigurationManager)
            .GetField("s_configSystem", BindingFlags.NonPublic |
                                        BindingFlags.Static)
            .SetValue(null, null);
 
        typeof(ConfigurationManager)
            .Assembly.GetTypes()
            .Where(x => x.FullName ==
                        "System.Configuration.ClientConfigPaths")
            .First()
            .GetField("s_current", BindingFlags.NonPublic |
                                    BindingFlags.Static)
            .SetValue(null, null);
    }
}

And the usage:

[Test]
public void Application_should_behave_differently_with_alternate_config()
{
    using (new AlternateAppConfig(@"Path\to\Alternate.App.Config")))
    {
        //Your test goes here
    }
}
//The original configuration is restored upon disposal of the alternate.

Happy testing!

Log4Net Integration with Unity IoC Container

Ken — Fri, 29 Jul 2011 01:18:53 +0000

The Castle Project has a great logging integration facility that lets you integrate Log4Net (or NLog) into your dependency resolution such that if you declare a dependency on ILogger (Castles wrapper around Log4Net.ILog), the dependancy that gets injected is initialized with the type into which it is being injected. If you understand how Log4Net logger names work, you’ll know why this is important.

But on my current project, I am not using Castle; I am using Microsoft’s Unity IoC container. Figuring out how to do the same thing in Unity took me most of a day and I didn’t like my solution, so I posted a question on Stack Overflow and got a response that pointed me to exactly what I wanted. The links were to a blog post and ultimately to an obscure thread on the Unity – Patern’s and Practices forum. I find that forums are notorious for not being there for the long haul, and the blog did not provide any details on its own, so I am re-posting it it all here in a slightly cleaned up form for posterity’s sake.

Implementing this in Unity requires three steps.

Creating a Build Tracking Extension
Creating a Logger Creation Extension
Wire the extensions into Unity

The Build Tracking Extension

The first step is to a create Unity extension that installs a build tracking strategy. This strategy uses a policy to keep track of the stack of dependencies being built as part of handling the current resolution request. This is needed so that when resolving the logger dependency, we can consult the stack to see what type the dependency is being resolved for.

Here is the code, pretty much taken straight from the aforementioned post.

using System;
using System.Collections.Generic;
using Microsoft.Practices.ObjectBuilder2;
using Microsoft.Practices.Unity;
using Microsoft.Practices.Unity.ObjectBuilder;
 
public class BuildTracking : UnityContainerExtension
{
 
    protected override void Initialize()
    {
        Context.Strategies.AddNew<BuildTrackingStrategy>(UnityBuildStage.TypeMapping);
    }
 
    public static IBuildTrackingPolicy GetPolicy(IBuilderContext context)
    {
        return context.Policies.Get<IBuildTrackingPolicy>(context.BuildKey, true);
    }
 
    public static IBuildTrackingPolicy SetPolicy(IBuilderContext context)
    {
        IBuildTrackingPolicy policy = new BuildTrackingPolicy();
        context.Policies.SetDefault(policy);
        return policy;
    }
}
 
public class BuildTrackingStrategy : BuilderStrategy
{
 
    public override void PreBuildUp(IBuilderContext context)
    {
        var policy = BuildTracking.GetPolicy(context)
            ?? BuildTracking.SetPolicy(context);
 
        policy.BuildKeys.Push(context.BuildKey);
    }
 
    public override void PostBuildUp(IBuilderContext context)
    {
        IBuildTrackingPolicy policy = BuildTracking.GetPolicy(context);
        if ((policy != null) && (policy.BuildKeys.Count > 0))
        {
            policy.BuildKeys.Pop();
        }
    }
}
 
public interface IBuildTrackingPolicy : IBuilderPolicy
{
    Stack<object> BuildKeys { get; }
}
 
public class BuildTrackingPolicy : IBuildTrackingPolicy
{
 
    public BuildTrackingPolicy()
    {
        BuildKeys = new Stack<object>();
    }
 
    public Stack<object> BuildKeys { get; private set; }
}

The Logger Creation Extension

With the build tracking extension in place, it is now possible to create a logger creation extension that will use it to create an instance of ILog. (This implemenation is not generic like the Castle implemenation but specific to Log4Net).

Again here is the code, pretty much straight from the forum thread. All I have done is incorporated the patch (also from the thread) to handle direct resolution requests for an ILog instance.

using System;
using System.Diagnostics;
using System.Linq;
using Microsoft.Practices.ObjectBuilder2;
using Microsoft.Practices.Unity;
using Microsoft.Practices.Unity.ObjectBuilder;
using Log4Net;
 
public class LogCreation : UnityContainerExtension
{
 
    protected override void Initialize()
    {
        Context.Strategies.AddNew<LogCreationStrategy>(UnityBuildStage.PreCreation);
    }
}
 
public class LogCreationStrategy : BuilderStrategy
{
 
    public bool IsPolicySet { get; private set; }
 
    public override void PreBuildUp(IBuilderContext context)
    {
        Type typeToBuild = context.BuildKey.Type;
        if (typeof(ILog).Equals(typeToBuild))
        {
 
            if (context.Policies.Get<IBuildPlanPolicy>(context.BuildKey) == null)
            {
                Type typeForLog = LogCreationStrategy.GetLogType(context);
                IBuildPlanPolicy policy = new LogBuildPlanPolicy(typeForLog);
                context.Policies.Set<IBuildPlanPolicy>(policy, context.BuildKey);
 
                IsPolicySet = true;
            }
        }
    }
 
    public override void PostBuildUp(IBuilderContext context)
    {
        if (IsPolicySet)
        {
            context.Policies.Clear<IBuildPlanPolicy>(context.BuildKey);
            IsPolicySet = false;
        }
    }
 
    private static Type GetLogType(IBuilderContext context)
    {
        Type logType = null ;  
        IBuildTrackingPolicy buildTrackingPolicy = BuildTracking.GetPolicy(context);
        if ((buildTrackingPolicy != null) && (buildTrackingPolicy.BuildKeys.Count >= 2))
        {
            logType = ((NamedTypeBuildKey)buildTrackingPolicy.BuildKeys.ElementAt(1)).Type;
        }
        else
        {
            StackTrace stackTrace = new StackTrace();
            //first two are in the log creation strategy, can skip over them
            for (int i = 2; i < stackTrace.FrameCount; i++)
            {
                StackFrame frame = stackTrace.GetFrame(i);
                logType = frame.GetMethod().DeclaringType;
                if (!logType.FullName.StartsWith("Microsoft.Practices"))
                {
                    break;
                }
            }
        }
        return logType;
    }
}
 
public class LogBuildPlanPolicy : IBuildPlanPolicy
{
 
    public LogBuildPlanPolicy(Type logType)
    {
        LogType = logType;
    }
 
    public Type LogType { get; private set; }
 
    public void BuildUp(IBuilderContext context)
    {
        if (context.Existing == null)
        {
            ILog log = LogManager.GetLogger(LogType);
            context.Existing = log;
        }
    }
}

Wiring It All Up

Lastly, to wire this up to your container all you need is the following (also stolen) code:

var container = new UnityContainer()
    .AddNewExtension<BuildTracking>()
    .AddNewExtension<LogCreation>()
    .Register<MyClassWithLoggerDependency>();
 
var myClass = container.Resolve<MyClassWithLoggerDependency>();
 
//Or
var myLogger = container.Resolve<ILog>();  //return logger with a name of this.GetType().Fullname

Hope this code helps you as much as it did me. Many thanks to wageoghe, David Keaveny, Marco and Scott!

Automatically Selecting an Available TCP Port

Ken — Wed, 20 Jul 2011 01:39:50 +0000

If you are doing low level TCP networking in .Net and in particular are using a TcpListener on a client to listen for callbacks form a server, you need to select a port on which to listen. Typically, in this scenario, you don’t want to have to specify a port in the .config file. You just want to pick any open port (well actually, any open port, in the IANA private port range).

After looking around the net, I found some almost correct but not quite code for this, so I though I should post my improved version here.

The below function will return the first open port in the IANA port range that is not currently being used on the local machine.

Be careful however. Just because the port is not used at the point the code is called, doesn’t mean it won’t be in use when you go to open your listener. Just incase some other process grabbed the port in the interim, you should always open your listener in a try catch block and if the call fails because the port is in use, grab another available port and try again.

private static int SelectAvailablePort()
{
    const int START_OF_IANA_PRIVATE_PORT_RANGE = 49152;
    var ipGlobalProperties = IPGlobalProperties.GetIPGlobalProperties();
    var tcpListeners = ipGlobalProperties.GetActiveTcpListeners();
    var tcpConnections = ipGlobalProperties.GetActiveTcpConnections();
 
    var allInUseTcpPorts = tcpListeners.Select(tcpl => tcpl.Port)
        .Union(tcpConnections.Select(tcpi => tcpi.LocalEndPoint.Port));
 
    var orderedListOfPrivateInUseTcpPorts = allInUseTcpPorts
        .Where(p => p >= START_OF_IANA_PRIVATE_PORT_RANGE)
        .OrderBy(p => p);
 
    var candidatePort = START_OF_IANA_PRIVATE_PORT_RANGE;
    foreach (var usedPort in orderedListOfPrivateInUseTcpPorts)
    {
        if (usedPort != candidatePort) break;
        candidatePort++;
    }
    return candidatePort;
}

Disclaimer: I am by no means an network programming guru. If you find issues with this snippet or have a better one, please let me know.

Unit Testing for Memory Leaks

Ken — Sat, 11 Jun 2011 03:10:36 +0000

I just found this gem in a post on another subject on Krzysztof Koźmic’s blog and thought it merited its own post. Beautifully simply solution for asserting that a class doesn’t hold a reference to an object that it should not.

[Fact]
public void Freezable_should_not_hold_any_reference_to_created_objects()
{
    var pet = Freezable.MakeFreezable<Pet>();
    var petWeakReference = new WeakReference(pet, false);
    pet = null;
    GC.Collect();
    Assert.False(petWeakReference.IsAlive, "Object should have been collected");
}

Add Decorator Chaining Support to Unity IoC

Ken — Sat, 02 Apr 2011 12:26:06 +0000

This is just a quick plug for a post on Jim Christopher’s blog, beefycode.com, that explains how to create a Unity Extension to support IoC Chaining in much the same way as Castle Windsor does. I am going to need this someday and don’t want to loose the link. Thanks Jim.

Using Extension Methods and Lambda Expressions to create some Syntactical Sugar

Ken — Thu, 24 Mar 2011 22:23:18 +0000

This post grows out of my previous post on creating a C# equivalent to the Visual Basic With statement. I have since come up with a hand full of other lambda-accepting extension methods that do other handy things.

Improving on the With Statement

First off, the original with function can be extended to return values if need be as follows:

public static TReturn With<T,TReturn>(this T obj, Func<T, TReturn> action)
{
    return action(obj);
}

The As Method

The following As methods are very handy when you have a variable that is of one type but you need to perform some actions on it in the context of another type which the it also implements.

public static void As<T>(this object obj, Action<T> action)
{
    action((T) obj);
}
 
public static TReturn As<T,TReturn>(this object obj, Func<T, TReturn> action)
{
    return action((T) obj);
}

IfIs, the Conditional form of As

What if you are not sure if the type you have can be cast to the other type? The following IfIs methods are just like the As method but only execute the code if the cast can be made.

public static void IfIs<T>(this object obj, Action<T> action)
{
    if(obj is T)
        action((T) obj);
}
 
public static TReturn IfIs<T,TReturn>(this object obj, Func<T, TReturn> action)
{
    return obj is T ? action((T)obj) : default(TReturn);
}

Again I can see that this sort of syntactical sugar may drive some people nuts. Others may just not see the need. But for some of us, this sort of thing makes it easier to write expressive code.

A C# Equivalent to the Visual Basic With Statement

Ken — Mon, 27 Dec 2010 12:13:01 +0000

I moved from Visual Basic to C# when I migrated to .Net back on ’04. I have never regretted this. C# is so much nicer a language in my opinion. One of the things I especially like about C# is its conciseness. I hate typing.

The one and only thing I missed from VB was the WITH statement. It drove me nuts that in C# for all its brevity, if I needed to do half a dozen things with Object.Child.Grandchild.GreatGrandchild, I had to write that whole thing out or put GreatGrandchild in a local variable like so:

Object.Child.Grandchild.GreatGrandchild.Property1 = 1;
Object.Child.Grandchild.GreatGrandchild.Property2 = 2;
Object.Child.Grandchild.GreatGrandchild.Property3 = 3;
Object.Child.Grandchild.GreatGrandchild.Property4 = 4;

The advent of object initializers in C# 3.0 alleviated the primary use case for the With statement. But object initializers don’t do much for the above case or any situation where you have a pre-existing instance.

I recently realized though that I can get 99% of the way there with a combination of two other C# 3.0 features, extension methods and lambda expressions. Putting the two together, I came up with the following method:

public static void With<T>(this T obj, Action<T> action)
{
    action(obj);
}

Which lets me rewrite the example code like this:

Object.Child.Grandchild.GreatGrandchild.With(x =>
    {
        x.Property1 = 1;
        x.Property2 = 2;
        x.Property3 = 3;
        x.Property4 = 4;
    });

Its not perfect and I can see that depending on your stylistic preferences this might drive you nuts, but I think its some very clean code.

Author’s Update:

I recently discovered that Anay Kamat posted a different solution on his blog a way back in ’09. His approach uses reflection and results in a different usage syntax. I recommend you take a look and use whichever approach you like best.