A coworker swung by a few days ago to ask some questions about using Reflection. I learn really well by example so I decided to use Powershell to show using Reflection. Below is the session I used and later emailed to him. You can see a few spots at the bottom of the example where I was unsure of the syntax on passing an empty parameter array, but I figured it out.

This is a good example of why I like Powershell

Note - I used the :toHTML command from Vim along with Peter Provost's Powershell syntax file to get the color. Powershell doesn't support color at the console like this yet without explicitly passing color arguments to Write-Host.

(Warning - this post is both a rant against the Mutex as well as a guide for its usage. Also, don't blindly copy code, only the bottom code snippet works. )

I'm a big fan of an API that is so easy to use that I don't have to look at the documentation.

I had to look up the documentation for System.Threading.Mutex... multiple times.

Taking a look at Mutex, I see that it implements IDisposable. Great, that means I can wrap it in a using block.

My first try:

Looks good, right? Nope, that is a big negative. Nowhere does this actually acquire the mutex. When you run this application twice, they both show the message box just fine. Maybe I should actually check the createdNew value?

Let's change the code to look like this:

However, that didn't work, either. It turns out that the createdNew parameter just tells you if you're the one who created the mutex, not if you currently own the mutex. That is what the purpose for the WaitOne method is for. Of course, the documentation just says that it "blocks the current thread until the current WaitHandle receives a signal." Okay. Well, I'm glad that I now know that it also waits for my thread to acquire a lock on the mutex. (note, if you pass in 'true' as the first parameter, you'll request to be the owner, but you'll only be the owner if the createdNew out parameter comes back with true)

Third try. Third time's the charm, right?

Great, now when I run my app twice, the second one is blocking on the WaitOne call. Cool. You can even tell in the below screenshot, because the button's paint event is blocked and is whiting out (like Solitaire does when you win!).

Let's click okay and see if the second form gets the mutex, thus displaying the message. That's weird - the form still isn't responding. Let's close the first form.

Ouch! That was unexpected. What? Abandoned mutex? This sounds like I never even released the mutex. Hmmm... ReleaseMutex? Shouldn't that be called from the Dispose (end of the Using block)? Might as well try it.

Finally! Now, it works like I'm wanting. I'm keeping the using block in place, because that disposes the WaitHandle that Mutex uses (Mutex in face inherits from WaitHandle).

Anyway, I'm hoping there is a reason for the API to be designed in this way, but man, it doesn't seem very intuitive to me.

While learning this, I unfortunately tried putting the Mutex in some of my code without trying it small scale first. After struggling for quite a while, I went to the small application and discovered everything that I've posted here. I hope this helps you with the Mutex when you have to deal with it.

Here is a simple script I wrote which was inspired by this post on terminal color highlighting and by ColorDiff that does essentially the same thing.

# Out-ColorDiff.ps1
Process {
    if ($_) {
        foreach ($line in $_) {
            if ($line -match '^[<|-]') {
                Write-Host -ForegroundColor red $line
            }
            elseif ($line -match '^[>|+]') {
                Write-Host -ForegroundColor green $line
            }
            else {
                Write-Host $line
            }
        }
    }
} 

Here is a screenshot of sample output from the script:

You can use it by piping the diff output to the script, like 'svn diff somefile | out-colordiff' or if you're stuck using something like MKS, you can use 'si diff somefile | out-colordiff'.

Possible (and easy) additions would be to add direct parsing of a file instead of taking an argument off of the pipeline. This is all I need currently, but if you wish to add more features, feel free to leave them in the comments.

(Sorry for the lack of substance with this blog post - I'm hoping that just posting anything will spur me on to post something with substance. Wish me luck.)

Just a reminder to anyone in the Fort Smith area - we'll be meeting next Monday night at 6:00 to hear Chris Koenig talk about Silverlight. Chris is a Microsoft Developer Evangelist located out of Dallas. I got to meet Chris last year for a grand total of about 5 minutes when I went down for the .NET Roadshow that was hosted at Microsoft's office in Dallas. Chris got to escort me and the others between floors on the elevator

Anyway, if you're in the area, swing by. We'd love to see you. For more information, check out the FSDNUG website.

If you've been working with the .NET Framework for a while, you're hopefully already using some form of static analysis to help you catch problems with your code. One of the most well known is Microsoft's FxCop, which is now integrated as the Code Analysis feature in Visual Studio 2005 ^[1] and up. If you're not already using this tool, then please start because it can help you find problem areas like potential NullReferenceExceptions as well as globalization and security issues.

However, while FxCop is great at catching small problems and details, it isn't the best tool to see the big picture regarding your software. Enter NDepend by Patrick Smacchia. Chances are, you've already read Scott Hanselman's great review of NDepend a while back (or heard his podcast on static analysis with NDepend). If you haven't read it, go ahead and check it out. Scott uses NDepend to analyze dasBlog (which I'm running), so you can get the general feel for working with NDepend and what the reports look like.

I'd like to run through a few of the features of NDepend using Rhino Mocks as the target of my static analysis. Rhino Mocks is a neat example because it is only one assembly, but it is the result of an ILMerge of quite a few different libraries, so we get to see how NDepend handles this. Here is NDepend's class browser showing Rhino Mocks:

As you can see, it handles Rhino Mocks accurately. In fact, it almost feels like the class browser in Reflector, so that is already a plus. In fact, as you can see, the context menu supports jumping to Reflector for the selected type.

The "Who is directly using me?" option is also pretty cool and highlights the extensive use of CQL in NDepend:

CQL, or Code Query Language, is the centerpiece of NDepend and is how all of the analysis happens. You can think of it as SQL against IL. The massive benefit that NDepend has over FxCop IMHO is that you can create your own analysis rules in CQL instead of having to write and compile a DLL to extend FxCop (for an example of this, check out this FxCop rule that ensures that ArrayLists are List<T>s instead). Even better, NDepend provides a complete editor with intellisense that allows you to test your queries out against your assemblies.

Take a look at this screenshot. You can see the intellisense at the bottom right hand of the screen. At the top left is the CQL Query Results. The top right is all of the types in the assemblies, but the highlighted ones in blue are those that were returned by the query. This all happened as I typed the query in. Actually, I got red when I typed it in the first time, because my query had some mistakes in it, but NDepend was very helpful in showing me how to correct my query.

The query editor also has different types of intellisense depending on the value.

I'll admit that it might seem weird to have a slider when you're just typing a number in, but the cool part is when you change the value, the query results automatically change to reflect the new value. In this case, you can watch the results of the query to get a feel for which types have the most methods.

From an agile coding perspective, NDepend ties in well with Continuous Integration. It ships with both a NANT and an MSBuild task to run the NDepend console against an NDepend project file (which is just XML). The report that it provides is insanely detailed. I'd say this where the value of application-specific CQL queries would come in handy, because you can come up with some detailed queries that are run on every CI build to ensure that the code still matches whatever design criteria was decided upon when the queries were written.

For future versions of the tool, I'd think it would be neat to have a lightweight version of the CQL tool that you could ad hoc queries against assemblies, like as a Reflector addin or something. That'd be cool. Or maybe a Powershell cmdlet/PSDrive provider so that you could do something like this:

Get-ChildItem -Include *.dll -Recurse | Select-Cql -Top 10 -Methods -Where MethodCa -ge 5

Or maybe:

Get-ChildItem -Include *.dll -Recurse | Select-Cql -Top 10 -Methods | Where { $_.MethodCa -ge 5 }

I'm not sure exactly how the syntax might look, but it would be really cool

Hopefully, I've given you a good picture of the some of the features of NDepend. If your interest is at all piqued, there is a "Trial / Open Source / Academic Edition" that you can download for free. Its feature set isn't quite as broad as the Professional edition, but I've used it before and it still provides a lot of functionality. Check it out!

Full Disclosure - I used a review copy of NDepend for this post. My company is not (yet) using this tool, but I think that there is interest. I wasn't paid to do this. <kidding>If you, dear reader, would like to pay me, please contact me.</kidding>

^[1] I don't believe that all of the SKUs of Visual Studio have the Code Analysis feature.

Anyone else find this funny? I know I do! I told you I was a beta junkie.

If you haven't already read Joel's commentary on the current situation with browsers, specifically the Internet Explorer 8 beta, you should check it out¹. As always, read the opposing viewpoint as well. I would say that some of the comments to that post might provide more value than the sarcasm in the post, specifically this comment from Mark himself.

But you know, I'm not really posting to talk about the problems with browser compliance, web standards, or anything like that. I'm talking more about how commenters really have no clue what they're talking about. From Joel's post, "99% of the participants in the flame wars are not going to understand what they’re talking about."

The most recent post on the IEBlog revolved around how the WebBrowser control will render sites. One of the first comments is a complaint about naming regarding the WebBrowser control. The thing is, that is what it is named! Just try a Google search on the topic!

I guess this is exactly what Joel was talking about when he questioned the value of comments on sites that have enough traffic. Good thing my site doesn't get that much traffic Comments to my posts (when they come) are still quite welcome!

¹ While you're there, read the rest of his posts. And subscribe to his blog. Why aren't you already?

I am a huge fan of the immediate window in Visual Studio. I say forget the watch window - I'd rather use code to check values. In case you didn't know, you can get values in the Immediate window by typing "?" and the variable name. Like so:

? myCoolVar

You can also execute commands at the immediate window by just typing them. It is a nice way to change values at debug-time.

myCoolVar = "some other blah"

What I didn't realize until today is that you can create completely new variables at the Immediate window as well! Just type in the variable declaration as you normally would in code. (note that you need the semi-colon in this case)

string myNewCoolVar = "I'm a brand new variable!";

Here's a screenshot of this behavior in action:

Right now, I'm using this behavior while working with a new WPF application. I've got an IMultiValueConverter and it is a hassle casting my generic array of objects into types, especially when I'm still deciding on the various bindings I'd like to pass in. With this, I can just set a breakpoint and use the Immediate window to play with the code.

This gets me a lot closer to an interactive console (like IRB) with .NET. Though I can do all of this with IronPython, F#, or IronRuby, it is nice to be able to do this at debug time from Visual Studio.

Last night kicked out the Fort Smith .NET User Group's first meeting. It went great! I would guess that we had at least 20 or 30 people show up.

Raymond Lewallen spoke to us about Behavior Driven Design (BDD). I thought I'd share links to a few of the resources that he brought up last night.

• Dan North - He came up with the BDD idea
  • Also check out this blog post for more detail regarding BDD
• specunit-net - A set of extensions to strive for more behavioral tests (specifications) based on SpecUnit for Ruby
• NUnit - The testing framework Raymond used
  • MbUnit - I actually use MbUnit for most of my tests, but NUnit is fine.
• Castle Windsor - The IoC container that Raymond mentioned.
• Here are a few other IoC/DI containers available for .NET development
• StructureMap - From Jeremy Miller
• Unity - The Microsoft offering
• Rhino.Mocks - A mocking framework by Oren Eini.
• Automocking Container - An IoC container that takes advantage of Rhino.Mocks for mocking out dependencies.
• General BDD resources
  • Behavior-Driven.org
  • The Wikipedia entry on BDD

All in all, a great presentation. Considering the breadth of information that BDD covers, I think Raymond did a great job. I hope that FSDNUG can continue to bring topics like this to the area.