Archive | .NET RSS feed for this section

Stop playing with the LightSwitch

25 Aug

If you’ll excuse me for a moment, I just got the sudden urge to totally geek out. Oh, who am I kidding? Here’s my latest techno-nerd-babble:

(FYI: It’s not a groove, it’s not slightly transformed, but it is a bit of a break from the norm.)

Yesterday I installed the new Visual Studio LightSwitch (Beta 1) app. After playing with some samples, I tried to create a simple app that calls an external web service and displays the data. I read somewhere that this isn’t possible unless you first call a WCF RIA Service, which could itself call the external service and send the result back to LightSwitch. Kind of like driving from Kansas City to St. Louis to get to Denver.

So, I added a WCF RIA Services project to the solution. To this project I added a service reference to a free web service I found which takes a given year and returns the date Black Friday took place that year. Delightful! And almost completely useless. But hey, it’s free.

I created a service method in my RIA service that simply calls the external service five times with five different dates. I wanted multiple results so I could return an IEnumerable<T> back to the UI. Next, I went through LightSwitch’s Add Data Source wizard and chose “WCF RIA Service”. After waiting an eternity (they take the word “Beta” very, very seriously at Microsoft), I was finally able to complete the wizard and add a reference to my RIA service.

Finally, I added a simple screen to display the data in a grid when the app loads. I hit F5 and…hey, it worked! That was both fun and educational. Maybe I’ll post screenshots if I get something interesting built with the production version of the tool. In the meantime, I better quit playing with the LightSwitch before I start a fire.

Right…like THAT’S really gonna happen, Dad.


What’s your name?

20 Apr

In .NET, having access to the name of a property can be valuable in several scenarios, such as data-binding. However, hard-coding the name of the property in the designer or in a string variable is error prone and can be a pain to deal with when refactoring.¬†We need an easy way to get the “code” name of an object’s property, not it’s property value.

The Props class below has a static method for getting the name (as a string) of a given object’s property. This method uses the generic Expression type to build an expression tree and access the member (property/field) information. I wish there was a way to get rid of the “() =>” syntax, but I can’t seem to find one.

Try it out:

using System;
using System.Linq.Expressions;

namespace PropertyNames
    class Program
        static void Main(string[] args)
            Car audi = new Car();

            Console.WriteLine("The name of the property with the engine data is {0}",
                Props.GetName(() => audi.Engine));

            Console.WriteLine("The name of the property with the spoiler flag is {0}",
                Props.GetName(() => audi.HasSpoiler));


    internal class Car
        public bool HasSpoiler { get; set; }
        public string Engine { get { return "V8";} }

    internal static class Props
        public static string GetName<T>(Expression<Func<T>> expression)
            MemberExpression memberExpression = expression.Body as MemberExpression;
            if (memberExpression == null)
                throw new ArgumentException("Property specified is invalid");
                return memberExpression.Member.Name;

My Take On JPeck’s TDD Example

9 Mar

I had some spare time today, so I caught up on my friend James’ blog. He recently posted a real-world example of TDD taken, I assume, from his real-world job of developing software for a bank.

In the comments section of this particular post, someone named Darren made a case for using interfaces and mocks in the design of the tests and the resulting software. James stated that he would probably try that approach next. Well, the original post is about one month old now and I happen to have T.A.D.D. (Technical Attention Deficit Disorder). So, I’ve posted my version of James’ real-world TDD example. A few comments about my design:

  • I changed the design of the HumanResourcesService. I renamed it to “IEmployeeService”, extracted and renamed the methods and created a criteria-based lookup.
  • I renamed the “HumanResources” class to “EmployeeManager” and made it work against the IEmployeeService abstraction.
  • I exposed the GetEmployeeById as a public method in EmployeeManager. I figured this would be a good thing to provide consumers.
  • I used Rhino Mocks and SpecUnit as the mocking and TDD frameworks, respectfully.
  • I generated a report (HR.Specs.html) showing the different specifications the test code is exercising. The report looks nice, but to get it I had to use underscores in the spec class names (yuck). Was it worth it? Probably.

In general, I tried to follow the AAA (Arrange, Act, Assert) pattern in the spec code. I’ve included James’ very-slightly-modified code in the solution for reference (I renamed a couple of variables I found offensive). Click here to download the code. Rename it to a .zip file to access the contents.