Visual Studio 2010 library referencing issue using Client Profile

So I’m working in a solution with a library domain that is shared among all of the projects in the solution.  I decided to create a test windows form app to experiment with using WCF MSMQ a little more than the few times I’ve used it in the past. 

Created the windows form project the old fashioned way using Create New Project, Windows Forms.  For some reason the .NET version chosen by VS was .NET 4 Client Profile…?  Huh?  Not sure what that represents, but I didn’t notice it until I tried using the mentioned library above.  No matter what I tried, I was getting this error in the build:

The type or namespace name ‘***********’ could not be found (are you missing a using directive or an assembly reference?)

Even though the library was clearly in the same solution and that library was compiling successfully.  Not to mention other projects in the solution had no trouble compiling using this library.

Here was the issue:

Again, I’ll have to read up on what the Client Profile framework is, but changing this to .NET Framework 4 fixed the problem.

Using Generic Constraints

I came across an issue of wanting to have a function carry out any Action (or say Func) on any type within my domain.

Generally when I wanted to cut down on repeatable code using one class, say a Foo class, I’d follow this format:

private static void DoFoos()
{
      DoFooAction(d => d.DoFoo());
      DoFooAction(d => d.DoFooWithInput("Hello Foo World!"));
}

private static void DoFooAction(Action<IFoo> action)
{
      IFoo foo = new Foo();
      action(foo);
}

public class Foo : IFoo
{
      public void DoFoo()
      {
         Console.WriteLine("Foo.");
      }

      public void DoFooWithInput(string input)
      {
         Console.WriteLine("Foo input: " + input);
      }
}

This way, I could just use a lambda expression for any use of a Foo method that needed to be invoked.

What if instead, I want the same DoFooAction method to carry out the action of any Type?

In comes Generics and specifically Generics with constraints, and now I can use any other type, say a new type Moo:

private static void DoAllActions<T>(Action<T> action) where T : new()
{
      action(new T());
}

public class Moo
{
    public void DoMoo()
    {
       Console.WriteLine("Moo!");
    }

    public void DoMooCalc(int a, int b)
    {
       var sum = a + b;
       Console.WriteLine("a + b = " + sum.ToString());
    }
 }

The above Generic method can do both Moo and Foo with the appropriate Lambdas:

   private static void DoMooandFoo()
   {
      DoAllActions<Foo>(d => d.DoFoo());
      DoAllActions<Foo>(d => d.DoFooWithInput("hello."));
      DoAllActions<Moo>(d => d.DoMoo());
      DoAllActions<Moo>(d => d.DoMooCalc(1, 2));
   }

Generics allow type safety at compile time and cut down even more on the amount of code needed in the past to carry out the same action but on different types.

Struggling with NUnit

NUnit is a free open source framework and software to help run automated Unit Tests.  It’s great, it’s widely documented, and has a good community.  But for some reason I’ve been having trouble with the newest versions (currently 2.5.5).

Basically what was happening was that I would create the TestFixture class, the simple test functions, compile this into a .dll and open it in NUnit, like so:

Great, everything passed (as it should, I’m working out of Roy Osherove’s “The Art of Unit Testing”).

Except one problem kept showing up, when I’d then make a new function/change/whatever to the test class in Visual Studio 2008, I’d get the compile error that the .dll that VS is trying to rebuild “is being used by another process.”   This simply means another application is using the .dll or really that NUnit hasn’t released the file.  The frustrating solution was to close NUnit after each test, recompile then reopen the NUnit GUI and re-run the test.  That’s too much, and shouldn’t have to be done.

So I searched their googlegroups http://groups.google.com/group/nunit-discuss, and the only other posts about this mentioned memory leaks or not properly cleaning up resources in the Test.  I realized (the latter) can’t be the case seing that this was happening with the sample C# solutions/projects that shipped with NUnit!

Surprised to say the least, the final solution was going back to an older version, 2.5.1.  Currently 2.5.5 is the newest release, I tried 2.5.4, same problem, then saw a note in a post about the same issue that 2.5.1 didn’t seem to have the same issue.

Uninstalled 2.5.4 -> installed 2.5.1, and like magic no lockups on the library you’re testing.

Jump into Test-Driven Development

It’s taken me a while to get used to a new paradigm in development, which is commonly referred to as Test-Driven.

The main idea is to create a test for code that isn’t written yet, watch it fail, then continue coding until it works.

In Visual Studio you just need create a new test project (you can also create a Unit Test project).

Then in code create a TestClass and TestMethod’s by adding the appropriate attributes as seen below:

The code in this example came from Jonathan B’s C# group meeting lecture on Evolving your code, here’s his website:

http://www.theabsentmindedcoder.com/

Then F5 (run) and you’ll see whether your Assert statements pass.

Constant testing of new functions and classes helps weed out logical errors that can show up down the road in actual program testing or even worse, after deployment.

Wonders of WCF, Interfaces on both sides need the same name…

For some reason, in the articles and books I’ve skimmed through on WCF, I somehow missed the point that the interface files on both the client and the server have to have the same interface name declared.

Usually for most instances thus far I’ve used svcutil.exe to generate the proxy class files, and of course this did that for me (created the inteface for the client with the same interface name).  But I spent a good time Sunday night (always prepping to demo something at the last minute) trying to figure out why my new WCF creations within a system I’m designing were not communicating.

In this instance I was using the very cool netMSMQbinding transport protocol.  MSMQ can be used pretty easily without WCF but I decided to give it a shot since WCF simplifies a lot of the underlying details for you (and it’s cool that instead of having to serialize say a string/message, you can communicate through MSMQ in classic WCF format…..function calls).

Instead of auto generation the proxy classes I simply wrote them, in this fashion, as most WCF programmers I’ve ready say they manually write the proxy classes themselves instead of relying on svcutil.exe

The server side/receiving side of the messages/calls over MSMQ binding:

So yeah, when writing your own interface proxy files make sure the interface has the same name on both sides.

Embracing Lambda Expressions

I’ve put off using a lot (or really most of the features) in C# 3. Lambdas being one of them.

I originally started programming in .NET 2.0 and C# 2. Although the way I originally learned how to use delegates and invoke was from C# 1.

Dan Vanderbloom’s blog has the best example of this transition.

Here was my progression and the way I inovked a delegate to post back to a control on another thread.

First, we declare the delegate, then in a method you need to create an instance of the delegate, and invoke it:

You test if this.invokeRequired(), which will be yes if you’re on a different thread than what the control you’re invoking is on.

If this is the case you’ll go back into the function through the delegate method who’s target is the same method (a shortcut really, most have this outside the target method).

Not really all that complicated, but I had to make a target function and delegate for each type of input parameter.

Now with Lambdas, it’s this simple (to do the same as above):

You do need this function inside the same namespace of your class (not required within the class though).

with this function you can now use this lambda expression:

pretty Rad.

Dynamic Connection String to WCF Host

Another issue I came across was needing a way to dynamically connect to a WCF host without using the app.config file (which in all examples I see, they put the connection string in the app.config).

In code you can specify the endpoint address like so, with the “localhost:8008″ being the tcp address you want:

InstanceContext instanceContext = new InstanceContext(this);
client = new Service1Client(instanceContext);

client.Endpoint.Address = new EndpointAddress(“net.tcp://localhost:8008/Service1″);

First post

Something I’ve come across using WCF.

A co-worker said he was getting exceptions when a network connection was dropped, and his proxy client state would drop (thus throwing an exception).

My solution that I’ve been using when trying to invoke any WCF client method is to do the following, thus preventing an exception from occuring:

if (client != null && client.State == CommunicationState.Opened)
{
    client.Method();
}
else
    this.ConnectToWCFHost();

If it’s null, try reconnecting and instantiating the client instance.  You might want to count the number of attempts to connect and then notify the system (through an event viewer for instance) that the connection cannot be established.