.NET

I’ve spent a bit of my spare time in the past week looking at Windows Phone 7 from a developer’s point of view.  I’d have started sooner, but honestly, I didn’t see the point until there were actually devices that I could hold and use.  I know that in the U.S., some guys got developer phones from Microsoft, but I don’t think that anybody up here in Canada was that lucky. So, over the past year or so I’ve been dabbling with Android and I actually like programming for Android. 

I guess I forgot to mention this:  On April 1, 2010, I received an e-mail from Microsoft that my MVP in C# was renewed for the third year.  This makes me a happy, because with Resharper 5 (and therefore Visual Studio 2010) and Windows Mobile 7, I’m hoping that this will be an exciting year for the .NET crowd. 

Well, okay, perhaps I didn’t forget.  Given that it was April 1st when I got the e-mail, I like to give things a few days to settle down.  I am acquainted with some mischievous pranksters who would think it was a funny April Fools joke.

If you using a unit testing framework such as NUnit, you’re no doubt familiar with the [Ignore] attribute.  (Note:  I haven’t used MbUnit in a while, but I’m pretty sure that all this applies there as well.)

For those who aren’t, when you adorn your [Test] with this attribute, then your test runner should pay no heed to this particular [Test].  Instead of going green or red, your test turns up as yellow in your test runner. At first blush, this seems handy - rather than deleting a failing or broken test you can have it [Ignore]d.

One of the nice things about Dependency Injection is that it can really help write a more flexible, modular application.  These days, it seems that there is no shortage of choice in the .NET community when it comes to IoC frameworks:

• StructureMap
• Castle Windsor
• Ninject
• Autofac
• Unity
• Spring.NET
• And probably others that I’m missing.

Ironically, when you first start using an IoC framework, you might find that in trying to make a loosely-coupled, modular, application you end up shackling yourself to the framework you’re using for IoC. For example, you start off using your own homegrown IoC framework, and then decide at some point in the future to use a different framework, like say StructureMap.  Going through your codebase to make these changes can be quite the exercise in pain. There are a couple of ways to isolate yourself from this kind of situation.  I won’t get into all of them but instead will focus on the Common Service Locator.

Lately I’ve been experimenting with TypeMock Isolator,  and it’s new AAA syntax.  For the past two years I’ve been a diehard Rhino.Mocks kind of guy, but figured that it’s time to check out other tools.  Anyway, I had a situation where a unit test of mine was failing when I ran it with TestDriven.NET, but would pass when I ran it using the unit test runner in Resharper 4.1.

Usually when I develop, I write individual tests and then run individually with TestDriven.NET and collectively with Resharper.  In this case, as I was writing one unit test, it kept failing with TestDriven.NET.  At first I thought it was just me being stupid (always a good place to start), and then I was worried that perhaps the documentation for TypeMock was to blame.  So, I sent a email to Avi at TypeMock, mostly expecting confirmation of my stupidity.

Lately I’ve been experimenting with TypeMock Isolator,  and it’s new AAA syntax.  For the past two years I’ve been a diehard Rhino.Mocks kind of guy, but figured that it’s time to check out other tools.  Anyway, I had a situation where a unit test of mine was failing when I ran it with TestDriven.NET, but would pass when I ran it using the unit test runner in Resharper 4.1.

Usually when I develop, I write individual tests and then run individually with TestDriven.NET and collectively with Resharper.  In this case, as I was writing one unit test, it kept failing with TestDriven.NET.  At first I thought it was just me being stupid (always a good place to start), and then I was worried that perhaps the documentation for TypeMock was to blame.  So, I sent a email to Avi at TypeMock, mostly expecting confirmation of my stupidity.

As I was driving home today, I couldn’t help notice something.  Microsoft’s ASP.NET MVC framework is still in beta, and was only announced last October.  To my knowledge, there are currently three projects in the Edmonton area based off this framework.

Castle Monorail has been around for much longer, three years or so?  It’s still listed as a release candidate on it’s website, but I’d say Monorail is suitable for production.  Currently, I am not aware of any projects in the Edmonton that are based off this framework.

*Note:  I originally wrote this post on August 23, 2008.  As things change with the book NHibernate in Action, I will be updating this post and resetting the date. *

I’d like to take a break from boring you two readers of my blog, and take a moment to annoy you with a rant.  Diversity is the spice of life after all.

This little remonstration of mine is about the Manning Early Access Program (MEAP).  Well, specifically just  one book.  I’ve got my eye on a couple of other books available with MEAP to see how they pan out before considering the whole “early access” useless.  Anyway…

At the last Edmonton Agile Methods User Group meeting, we had a brief discussion around code coverage, and what should be an acceptable number to shoot for.  Is it okay when the unit tests cover 80% of the code?  Or should 100% be the only acceptable value?  After all, how can you be confident in your code knowing that 20% of it isn’t tested.

Allow me to go out on a limb here, and state with absolute certainty that the correct answer is “It depends on your situation”.  Allow me to elaborate.

Last night (Thursday, June 26th) Rod Paddock gave a talk on using Silverlight 2.0 to the Edmonton .NET User Group.  I’d say that Rod did a pretty good job, despite the fact that the beta of both Silverlight and Expression Blend didn’t exactly want to play nice all the time.  It’s definitely perked my interest in the technology, and I can see a lot of business potential for it.

The rich user experience that Silverlight brings to the web-browser, will, I think raise the bar for what web applications will do for businesses.  Forget all the buzz about ASP.NET MVC or MonoRail or ASP.NET 3.5.  This is just another layer of makeup on the tired, old, hooker that is application development in .NET.  Silverlight is what will make business users oh and ah and get excited about web apps again.