Hitting Host Machine’s SQL Server from within a VM

I had a situation at home where I was running some code in Visual Studio on a virtual machine. The virtual machine was running using VMWare Player on my desktop machine.

I needed to access the database which was running on my host machine (the desktop machine) from within the VM. So I had to come up with a Connection String which was able to target the host machine. The following Connection String achieves that:

<add name="DefaultConnection" connectionString="Data Source=192.168.25.1,2310;Network Library=DBMSSOCN;Initial Catalog=AdventureWorld;Integrated Security=True;MultipleActiveResultSets=True" providerName="System.Data.SqlClient" />

Note, I had to open port 2310 on the host machine’s firewall.

Now, I don’t need to install Sql Server on my virtual machines (which always seems to be a pain in the proverbial).

NDepend

I’ve wanted to take a look at NDepend for quite a while now. So today I am going to write about my initial impression of this excellent static-analysis tool. To get an immediate feel for what NDepend is and what it does, there is a short video that can be viewed here.

Managed code comes with many advantages. And one of the most significant (possibly the most significant) is the mountain of meta-data that .NET assemblies carry about themselves, and those that they interact with. This plethora of information can be tapped, analysed and presented in a meaningful way which gives coders/architects a great, bird’s eye view of the state of a given code base.

This post will not be a tutorial. But it will contain screenshots and some explanations. It will fall short of being a tutorial, because I am not setting out steps from end-to-end. Think of it as a summary of one developer’s experience analysing a real .NET solution with NDepend. The solution that I will analyse is my Home Library sample application (which is nowhere near finished and currently in a state of rampant architectural experimentation).

The first thing I wanted to check out once I had run the analysis on my solution (including all of its projects) was the metrics stuff. That looks interesting to me and I immediately decided to hone in on the Most Complex... - Types metric. When you select that from the NDepend menu (NDepend > Metric > Most Complex… > Types), it loads 2 separate panes:

  1. Search Results pane
  2. Metrics pane (which shows a treemap of the results)

Once I got my head around what I was looking at, it occurred to me that it was showing me the same information, but through different prisms:

Panes

Figure 1 – Metrics and Results Panes

Looking carefully at Figure 1, we can see that the way in which that information was retrieved was by way of the query that can be seen in the Search Results pane. Now that is pretty awesome, because NDepend has its own version of LINQ called CQLinq, which is used to pull out data from the static analysis (I am not sure if it is a fully-fledged LINQ provider, as I haven’t seen the word “provider” in any of their doco – but still über cool to have your own flavour of LINQ). Their documentation about syntax etc is a very good reference for writing CQLinq.

If you hover over the various methods in the tree-view (at the foot of the Search Results pane), you will see the corresponding rectangle in the treemap light up. You can see in Figure 2 that
I have honed in on the ExpressionBuilder type, as I do recall that carrying quite a bit of complexity. By the size of the rectangle in contrast to the rest of the treemap, that complexity is represented well. Obviously, the UI-related types in this WinForms app have the most complexity, each with quite a large Initialize method for all the controls on the forms.

Hover Cause and Effect

Figure 2 – Hover Cause and Effect

Another excellent feature in the Metrics pane is a drop down list which filters the top n items which match the query. In fact, if you look over to the right in the query window, you can see Take(10) has been added to the CQLinq query in Figure 3:

Top n

Figure 3 – Top n

I was correct in my feeling about the ExpressionBuilder class, as it is featuring in that top 10. If you click on the Edit Query button in the Search Results pane (visible in Figures 1 and 2 above), it launches a pane with a text-box for query manipulation. You can then add a new query, which is a pretty cool extension point. But that’s just the tip of the iceberg when it comes to customising NDepend to your needs.

The other feature that I wanted to highlight, as something that I found really cool, is the ability to see Dependency Graphs of your code. Figure 4 shows a graph I created from the NDepend menu NDepend > Graph> View ApplicationAssemblies Only:

Dependency Graph Assemblies

Figure 4 – Dependency Graph Assemblies


That’s a really nice representation of my architecture (just as I envisioned it). You can see the UI stuff towards the left, and then as you move through the middle (the domain), you eventually hit the data stuff on the right.

You can also create one for namespaces. Check out Figure 5 below:

Namespaces

Figure 5 – Mutually Dependent Namespaces


I’ve highlighted a problem there, which the tool found, regarding mutually dependant namespaces. The tooltips (the light-yellow boxes) provide some information to assist me in hunting down the reason for this unseemly coupling issue. This is a very valuable view of the relationship between your objects. You can also drill down further by right-clicking on the connector “edges” between the nodes in the graph to look at member dependencies etc.

The really cool thing about those tooltips is that they are dynamic. When you change a query or selected-item in a drop-box, the data displayed in those tooltips changes before your very eyes.

There are a heap of other things NDepend offers, some of which will have to be the subject for a future post.

But I’ll leave the reader with this – the developers of NDepend use NDepend to develop it. To use their words, they eat their own dog-food. And a very high quality kibble it is.

WebAPI Method Returning 404

There is something I absolutely hate when programming. When you hit a bump in the road that brings everything to a halt; and it is something which should definitely not be getting in the way. I hesitate to call them bugs. It’s just those little annoyances where I have overlooked some little thing and it has cost me hours.

Welcome to my day today. I had an ASP.NET MVC application which, when I created it, did not have the WebAPI stuff in the solution (I deliberately unchecked the checkbox which would have included all that stuff). So, when I decided that I did, in fact, want to use the WebAPI, I manually added all the necessary nuget packages etc.

There was one thing I got wrong. And troubleshooting this took me around 1.5 hours. Apparently, you need to register the WebAPI routes before the standard MVC routes:

protected void Application_Start()
{
  AreaRegistration.RegisterAllAreas();
  FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
  GlobalConfiguration.Configure(WebApiConfig.Register); // this 1st
  RouteConfig.RegisterRoutes(RouteTable.Routes); // then this
  BundleConfig.RegisterBundles(BundleTable.Bundles);
}

I’m not saying it shouldn’t be that way. It’s just that, when you are trying to get that thing, which should have taken 5 minutes, working 90 minutes later, you get a little peeved. Especially when you hear the clock ticking and time slipping away. In effect, it’s not even having wheels on the ground until the annoying oversight is rectified.

Filing this one under stuff I do not want to forget. Ever.

Unit Testing Private Methods

Some very smart and experienced people say not to test private methods. Fair enough. The reasons are good – read here.

This post is not going to buy into that debate. It’s purpose is to demonstrate how to test private methods. The answer is painfully obvious – use reflection.

In my StringExtensions class, I have a private static helper method called GetIndexOfNthCharHelper. I wanted to unit test it (hey it’s my API and I can control it, so some of the Just Say No reasons go away). This is the test I wrote:

[TestMethod]
public void GetIndexOfNthCharHelperDoes()
{
	//  Arrange
	var type = typeof (StringExtensions);
	var getIndexOfNthCharHelperMethod = type.GetMethod("GetIndexOfNthCharHelper", BindingFlags.NonPublic | BindingFlags.Static);

	//  Act
	int index = (int)getIndexOfNthCharHelperMethod.Invoke(null, new object[] { path, 2, 0, Path.DirectorySeparatorChar });

	//  Assert                        
	Assert.AreEqual(15, index);
}

Not too complex. But I do heed the warnings of others and definitely wouldn’t be too keen to unit test a private method of a 3rd party API over which I have no control.

Lock – the Good, the Bad and the Enhanced

The Good

The lock keyword in C# is very useful for writing thread-safe code. However, it does have its limitations. Before we get to those, I’ll talk you through how to use lock.
The following class FileAccessorNoThreadSafety has a single method called DoOperation. It writes a FileStream to disk, writes text to it and then reads it in again.

public class FileAccessorNoThreadSafety
{
	private static int _count;

	public void DoOperation()
	{
		try
		{
			var fs = new FileStream(Constants.TextFileName, FileMode.Append, FileAccess.Write);

			using (var sw = new StreamWriter(fs))
			{
				sw.Write("writing line with count {0}", _count);
				Console.WriteLine("writing line with count {0}", _count);
				sw.Flush();
			}

			fs = new FileStream(Constants.TextFileName, FileMode.Open, FileAccess.Read);

			using (var sr = new StreamReader(fs))
			{
				_count++;
				Trace.WriteLine(string.Format("{0}", sr.ReadToEnd()));
			}
		}
		catch (IOException ioException)
		{
			Console.WriteLine("{0} - {1}", ioException.GetType().Name, ioException.Message);
			Console.WriteLine("Execution deliberately ended due to {0}", ioException.GetType().Name);
			Console.WriteLine("Exiting");
			Trace.WriteLine(string.Format("Execution deliberately ended due to {0}", ioException.GetType().Name));
			Trace.WriteLine(string.Format("Exiting {0}", Thread.CurrentThread.ManagedThreadId));

			Environment.Exit(0); // kill the whole process
		}
		catch (Exception exception)
		{
			Console.WriteLine("{0} - {1}", exception.GetType().Name, exception.Message);
			Console.WriteLine("Execution deliberately ended due to {0}", exception.GetType().Name);
			Console.WriteLine("Exiting");
			Trace.WriteLine(string.Format("Execution deliberately ended due to {{0}}{0}", exception.GetType().Name));
			Trace.WriteLine(string.Format("Exiting {0}", Thread.CurrentThread.ManagedThreadId));

			Environment.Exit(0); // kill the whole process
		}
	}
}

Note that the FileStream is in append mode, so every time that method is invoked, the line of text is appended to the end of the existing text in the file.

The following method is the Main method of a console application which spins up 1000 threads, all looking to invoke DoOperation at the same time (relatively):

private static void Main()
{
	EnsureTextFile();
	Trace.WriteLine(string.Format("Main thread {0}", Thread.CurrentThread.ManagedThreadId));

	Thread[] threads = new Thread[1000];
	string oi = string.Empty;

	var fileAccessor = new FileAccessorNoThreadSafety();
	//var fileAccessor = new FileAccessorThreadSafe();

	for (int i = 0; i < threads.Length; i++)
	{
		threads[i] = new Thread(fileAccessor.DoOperation);
	}

	for (int i = 0; i < threads.Length; i++)
	{
		threads[i].Start();
	}

	Console.ReadLine();
}

private static void EnsureTextFile()
{
	if (!File.Exists(Constants.TextFileName))
	{
		using (File.CreateText(Constants.TextFileName))
		{
			//  do nothing
			//  "using" disposes of Stream returned by CreateText method
		}
	}
}

As all of those threads are simultaneously trying to access the same resource (the file written by DoOperation), it very quickly throws an IOException. So, we have code which is not thread-safe that results in an exception, if more than one thread attempts to invoke it. How can we fix that?

The easy way, is with the lock keyword, which I have used in a method of the same name in another class called FileAccessorThreadSafe:

public class FileAccessorThreadSafe
{
	private static int _count;
	private readonly object threadLock = new object();

	public void DoOperation()
	{
		try
		{
			lock (threadLock)
			{
				var fs = new FileStream(Constants.TextFileName, FileMode.Append, FileAccess.Write);

				using (var sw = new StreamWriter(fs))
				{
					sw.WriteLine("writing line with count {0}", _count);
					Console.WriteLine("writing line with count {0}", _count);
					sw.Flush();
				}

				fs = new FileStream(Constants.TextFileName, FileMode.Open, FileAccess.Read);

				using (var sr = new StreamReader(fs))
				{
					_count++;
					Trace.WriteLine(sr.ReadToEnd() + " " + _count);
				}
			}
		}
		catch (IOException ioException)
		{
			Console.WriteLine("{0} - {1}", ioException.GetType().Name, ioException.Message);

		}
		catch (Exception exception)
		{

			Console.WriteLine("{0} - {1}", exception.GetType().Name, exception.Message);
		}
	}
}

You’ll find that every thread is able to successfully complete the DoOperation method. In effect, you have a blocking call on each thread until each thread is able to acquire a lock on the resource. In layman’s terms, each thread waits patiently for the resource to be released until it is able to acquire a lock. That being the case, no 2 threads are working with the resource at the same time. Lets take a closer look.

The lock keyword is actually a shortened version of something like this (using the DoOperation method to demonstrate):

bool acquired = false;
object tmp = threadLock;

Monitor.Enter(tmp, ref acquired);

try
{
	var fs = new FileStream(Constants.TextFileName, FileMode.Append, FileAccess.Write);

	using (var sw = new StreamWriter(fs))
	{
		sw.WriteLine("writing line with count {0}", _count);
		Console.WriteLine("writing line with count {0}", _count);
		sw.Flush();
	}

	fs = new FileStream(Constants.TextFileName, FileMode.Open, FileAccess.Read);

	using (var sr = new StreamReader(fs))
	{
		_count++;
		Trace.WriteLine(sr.ReadToEnd() + " " + _count);
	}
}
finally
{
	if (acquired)
	{
		Monitor.Exit(tmp);
	}
}

The Monitor class is what is actually used to lock down the resource for the use of that particular thread and in a finally block, so long as the lock was successfully acquired, the Monitor releases its hold on the resource.
Thus, if you do need finer grain control, you may want to use that longer notation. You may find yourself in situations where you want to clean things up in such a way that having that full code is required.

The Bad

So what is the problem with lock? One word – deadlocks. Whilst I’ve never experienced a deadlock, smarter people than I have stated that they are possible. To demonstrate a deadlock, I have written a class with the 2 methods, LockIntThenFloat and LockFloatThenInt, which are specifically designed to deadlock each other:

public class TypeLocker
{
	public void LockIntThenFloat()
	{
		lock (typeof(int))
		{
			Console.WriteLine("Thread {0} got its first lock", Thread.CurrentThread.ManagedThreadId);


			Thread.Sleep(500);

			Console.WriteLine("Sleep over for thread {0}", Thread.CurrentThread.ManagedThreadId);

			lock (typeof(float))
			{
				Console.WriteLine("Thread {0} got both locks", Thread.CurrentThread.ManagedThreadId);
			}

		}
	}

	public void LockFloatThenInt()
	{
		lock (typeof(float))
		{
			Console.WriteLine("Thread {0} got its first lock", Thread.CurrentThread.ManagedThreadId);

			Thread.Sleep(500);

			Console.WriteLine("Sleep over for thread {0}", Thread.CurrentThread.ManagedThreadId);

			lock (typeof(int))
			{
				Console.WriteLine("Thread {0} got both locks", Thread.CurrentThread.ManagedThreadId);
			}
		}
	}  
}

To see that in action, the following console application will never exit:

static void Main()
{
	Console.WriteLine("Deadlock means that the app will never exit.{0}", Environment.NewLine);

	TypeLocker typeLockerInt = new TypeLocker();
	TypeLocker typeLockerFloat = new TypeLocker();

	Thread floatLockFirst = new Thread(typeLockerFloat.LockFloatThenInt);
	Thread intLockFirst = new Thread(typeLockerInt.LockIntThenFloat);

	floatLockFirst.Start();
	intLockFirst.Start();

	//  This will never ever exit
}

So, now that we know that deadlocks are possible and have actually seen one in action, what does the framework give us to solve the problem that sees the lock keyword come a cropper?

The Enhanced

A couple of really switched on guys tackled this issue and put their work on Github.
We can now modify our code in the following way and avoid deadlocks by using timeouts:

public class TypeLockerWithTimeout
{
	public void LockIntThenFloat()
	{
		lock (typeof (int))
		{
			Console.WriteLine("Thread {0} got its first lock", Thread.CurrentThread.ManagedThreadId);

			Thread.Sleep(500);
		}

		Console.WriteLine("Sleep over for thread {0}", Thread.CurrentThread.ManagedThreadId);

		try
		{
			TimedLock timedLock = TimedLock.Lock(typeof (float), TimeSpan.FromSeconds(2));

			Console.WriteLine("Thread {0} got both locks", Thread.CurrentThread.ManagedThreadId);

			timedLock.Dispose();
		}
		catch (LockTimeoutException e)
		{
			Console.WriteLine("Couldn't get a lock!");
			StackTrace otherStack = e.GetBlockingStackTrace(5000);
			if (otherStack == null)
			{
				Console.WriteLine("Couldn't get other stack!");
			}
			else
			{
				Console.WriteLine("Stack trace of thread that owns lock!");
			}
		}
	}

	public void LockFloatThenInt()
	{
		lock (typeof (float))
		{
			Console.WriteLine("Thread {0} got its first lock", Thread.CurrentThread.ManagedThreadId);

			Thread.Sleep(500);
		}

		Console.WriteLine("Sleep over for thread {0}", Thread.CurrentThread.ManagedThreadId);

		try
		{
			TimedLock timedLock = TimedLock.Lock(typeof (int), TimeSpan.FromSeconds(2));
			Console.WriteLine("Thread {0} got both locks", Thread.CurrentThread.ManagedThreadId);
			timedLock.Dispose();
		}
		catch (LockTimeoutException e)
		{
			Console.WriteLine("Couldn't get a lock!");
			StackTrace otherStack = e.GetBlockingStackTrace(5000);
			if (otherStack == null)
			{
				Console.WriteLine("Couldn't get other stack!");
			}
			else
			{
				Console.WriteLine("Stack trace of thread that owns lock!");
			}
		}
	}
}

In the methods of that modified class, you can see that I am still using lock to get the first lock. When it comes to locking down that next resource, I employ Haack’s TimedLock class which uses a timeout of 2 seconds. That is enough time to wait for the locked resource (which was locked by the other method) to be released.

This exercise gave me a much better understanding of lock. I hope it does for you as well.

The source code for this article can be downloaded here: