.NET

Dogfood II is Done!

James Bender — Mon, 16 Nov 2009 15:46:15 GMT

Thanks to all who came to my talk on F# at the Dogfood conference last week. I had a great time presenting it and hope all who attended enjoyed it as well. The slide deck and demo are attached. If anybody has any questions about it, please feel free to contact me.

This was my first Dogfood conference, and it was unlike any other event I’ve been to. I was able to meet a lot of people who don’t normally come to developer events or user group meetings.

On a related note, The Sophic Group will be holding an F# boot camp on December 14-15 at OCLC in Dublin OH. The cost is $1900 and includes two days of instruction, all class materials and a half-day of on-site (meaning your office) continuing F# education and assessment. If this sounds interesting, please contact me for details.

Next stop, PDC in Los Angeles. See you there!

Getting Started with WCF Slides and Code Sample from CINNUG

James Bender — Thu, 03 Sep 2009 12:17:50 GMT

Better late than never…

Seriously, sorry to everyone who’s been waiting for these.

I had a great time speaking in Cincinnati last week and meet a lot of great people. I hope to see you all again soon.

Exceptions Happen, Part 1

James Bender — Tue, 11 Aug 2009 19:11:20 GMT

You might thing you’re special, but your not. And sooner or later it’s gonna happen to you too. Your WCF Service is going to encounter a *gasp* Exception. Do you know what to do when it does happen?

Scott Hanselman wrote a terriffic blog post on exceptions. It’s a great place to start and if you haven’t read it you should. I wrote a post last year about working with the WCF Fault Contract. But there’s more than one way to skin this cat. What I’m going to be focusing on in this series of posts are the ways you can deal with exceptions in WCF and how to communicate what’s happened to your client.

In the first installment we’re going to look at how exceptions get received by a WCF client and how the WCF channel reacts to exceptions. Let’s start with what happens if you just throw a normal .NET exception. For this example we’ll be looking at a mock up of a service to return prices for stocks based on a ticker symbol.

The service contact:

   1:      [ServiceContract]

   2:      public interface IMyWcfService

   3:      {

   4:          [OperationContract]

   5:          decimal GetStockPrice(string symbol);

   6:      }

And the implementation:

   1:      public class MyWcfService : IMyWcfService

   2:      {

   3:          public decimal GetStockPrice(string symbol)

   4:          {

   5:              switch (symbol)

   6:              {

   7:                  case "MSFT":

   8:                      return (decimal) 1.41;

   9:                  case "IBM":

  10:                      return (decimal).89;

  11:                  case "JAVA":

  12:                      return (decimal).10;

  13:                  default:

  14:                      throw new ArgumentOutOfRangeException("symbol", "bad symbol");

  15:              }

  16:          }

  17:      }

Since this is a contrived demo, we only handle three symbols and return a static value. This does however provide us with an opportunity to see how .NET exceptions work in WCF. If we receive a symbol that is not in our list, we are throwing an ArgumentOtOfRangeException. If we were using this as just a .NET object we wouldn’t have a problem; either our code would catch the exception and do something with it, or it would bubble up to the user.

Our client is a winform application. The important part is the call to our service (via a proxy of course):

   1:  public partial class Form1 : Form

   2:  {

   3:      private readonly MyWcfServiceClient _proxy;

4:

   5:      public Form1()

   6:      {

   7:          InitializeComponent();

   8:          btnCallService.Click += CallService;

   9:          _proxy = new MyWcfServiceClient();

  10:      }

11:

  12:      public void CallService(object sender, EventArgs e)

  13:      {

  14:          lblResult.Text = _proxy.GetStockPrice(txtSymbol.Text).ToString();

  15:      }

  16:  }

So all we’re doing is grabbing a value (the ticker symbol) from a text box and passing it as an argument to the service. The result is used to set the value of a label control. When we run this and feed one of the three symbols that our service uses, the expected happens: a value is returned and set to the text of the label. When we provide an unsupported symbol, we get an error:

The exception text should look familiar to anyone who has worked with ASP.NET…

System.ServiceModel.FaultException: The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the <serviceDebug> configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework 3.0 SDK documentation and inspect the server trace logs.

Like ASP.NET, WCF will not return detailed exception information to clients as a security measure. Like ASP.NET we have the ability to change the configuration to return more detailed exception information. One line nine below, we have set the includeExceptionDetailInFaults value to “True”:

   1:  <?xml version="1.0" encoding="utf-8" ?>

   2:  <configuration>

   3:    <system.serviceModel>

   4:  ...

   5:      <behaviors>

   6:        <serviceBehaviors>

   7:          <behavior name="Service1Behavior">

   8:            <serviceMetadata httpGetEnabled="True"/>

   9:            <serviceDebug includeExceptionDetailInFaults="True" />

  10:          </behavior>

  11:        </serviceBehaviors>

  12:      </behaviors>

  13:    </system.serviceModel>

  14:  </configuration>

This results in the details of the error message being passed back to us:

Like ASP.NET, this can be OK for development, but is not a good idea for production.

Let’s make a few changes to our client application:

   1:  public void CallService(object sender, EventArgs e)

   2:  {

   3:      try

   4:      {

   5:          lblResult.Text = _proxy.GetStockPrice(txtSymbol.Text).ToString();

   6:      }

   7:      catch

   8:      {

   9:          MessageBox.Show("Service call failed");

  10:      }

  11:  }

By catching the exception we can let the user know that something happened and handle it gracefully. Running the application and use the symbol “ORCL” causes the exception, which is handled:

So, we can just re-submit a supported symbol right…?

Uh-oh.

Turns out that when a WCF service throws a normal .NET exception, it faults the channel. Any subsequent calls to the channel results in a CommunicationObjectFaultedExcption being thrown immediately. The channel cannot be salvaged; your only option is to throw it out and recreate it. The proxy implements an interface called ICommunicatioObject that has a Faulted event that we can subscribe to.A few more changes to our client…:

   1:  private MyWcfServiceClient _proxy;

2:

   3:  public Form1()

   4:  {

   5:      InitializeComponent();

   6:      btnCallService.Click += CallService;

   7:      _proxy = new MyWcfServiceClient();

   8:      ((ICommunicationObject)_proxy).Faulted += RecreateProxy;

   9:  }

10:

  11:  void RecreateProxy(object sender, EventArgs e)

  12:  {

  13:      _proxy = new MyWcfServiceClient();

  14:  }

… and now our client is able to recreate the proxy if a communication fault occurs.

This way of dealing with exceptions in WCF works well if you are a client of a service that you may not control or have the metadata needed to create a fault contract for. Otherwise, using the FaultException class and/or WCF fault contracts are a better way to go. I’ll be covering them more in detail in the next couple posts.

Code on!

Indy Code Camp Recap

James Bender — Sun, 17 May 2009 02:57:59 GMT

Thanks to everyone who attended my talk on custom WCF behaviors at the Indy Code Camp. I hope you all found the topic interesting and the content useful.

You can get the slides and code samples here:

For those who might be interested, I’ll be presenting an Intro to WCF talk at Cincinnati .NET Users Group in the future. More information will be posted here in the future.

If I Do A Good Job, Can We Go To Dietsch Brothers for Ice Cream After The Meeting?

James Bender — Sun, 26 Apr 2009 23:28:20 GMT

This Tuesday, April 28th, I’ll be speaking at the Findlay Area .NET User Group.

I’ll be presenting “How I Learned To Love Dependency Injection,” which if my .NET Kicks stats are to be believed, is turning out to be quite the popular talk. The meeting is at the Marathon Oil building in downtown Findlay.

I spoke at this group a couple of years ago and had a GREAT time. I’m excited to be going back!

How I Learned to Love Dependency Injection: The Slides

James Bender — Sun, 19 Apr 2009 18:46:27 GMT

Thanks to everyone who attended the Central Ohio Day of .NET yesterday and made it such a success. A special thanks to all the organizers as well.

I had a great time seeing some old friends a making some new ones. I hope to see you all at events down the road.

I hope those who attended my session on DI enjoyed it and found it useful. As promised, I'm posting my slides.

Right now I'm using a borrowed laptop, so I don't have access to the sample code, but I'll be putting that up as soon as possible.

See you all at the next event!

The one where I talk about the MSMQ Binding

James Bender — Sat, 04 Apr 2009 04:22:58 GMT

One of the most over-looked bindings available in WCF is the Microsoft Message Queue (MSMQ) binding. The virtues of HTTP and TCP are well documented. REST is the cool, “new” way to access services. MSMQ seems relegated to interfacing WCF with older “legacy” systems.

This shouldn’t be the case. The MSMQ binding provides a rich set of features and functionality that make it an excellent choice for building many types of applications.

MSMQ from 1,000 ft.

MSMQ is a first-in, first-out message queue that have been available in Windows Server since NT 4. The concept is pretty simple: a sender sends a message to the queue, and a receive pulls it off when it’s ready.

The big benefit of MSMQ is that it allows messages to be passed between computers across networks in a secure, reliable manner. Since the queue is not an actual component of either application, the receiver does not need to be running when the message is sent (it will sit in the queue and wait to be picked up) nor does the receiver have to be on-line when the message is processed. Individual messages and queues allow one-way delivery of messages, but a second queue can be added to allow for duplexing.

Messages can sit in the queue either until a receiver grabs them or until they expire. Messages that expire are placed in a special “dead letters” queue.

Windows Vista introduced an upgrade to MSMQ called the “poison queue.” If a receiver attempts to process a message but can’t due to error, and it’s retry count is reached, it is placed into the poison queue. Previous to Vista the developer had to create a mechanism to identify these messages and “handle” them or risk attempting to process the same message over and over again until human intervention stopped it.

Queues can be transactional, meaning that if any part of a message fails, the entire message is rolled back. If the retry count has not been reached the receiver will attempt to process the message again until the count is reached and the message is moved to the poison queue.

The rest of this post assumes you have MSMQ installed on your computer and have a private transactional queue called HelloMSMQ. Instructions on how to add MSMQ and create a private queue can be found here.

Using the MSMQ Binding

OK, so now that we’ve got our private transactional queue created, the next steps are to create a message sender and message receiver. Using the netMSMQBinding binding will make this simple.

Note: There are two MSMQ bindings: the netMSMQBinding, which we will use, and the MSMQIntegratedBinding. The integrated binding is designed for using MSMQ to send/receive messages from legacy mainframe systems with MSMQ. For working with WCF to WCF communication use the “net” binding. Of course, you can expose multiple endpoints on your server, and making one endpoint “integrated” and the other “net” is an option if you need to proved services to both types of clients.

Since MSMQ by nature allows communication one way through a queue, you will need to make sure your service operation supports one-way calls. This is easily done by setting the IsOneWay property of the OperationContract to true:

[ServiceContract]

public interface IMyService

{

[OperationContract(IsOneWay=true)]

void SayHello(string name);

}

The next step is to create your endpoint. Here is the configuration for the endpoint that this services is exposed on:

Like all endpoints, this one includes the “ABC’s” of address, binding and contract. Contract here is pretty much what you would expect. The address points to a queue residing on a server somewhere, in this case the local machine. This address specifically points to the private “HelloMsmq” queue on our local machine. The binding is the netMSMQBinding. The binding configuration specifies that we aren’t going to worry about security for messages in this queue:

SVCUTIL creates a proxy that works just like any other WCF proxy; the address points at the same private queue and it uses the netMSMQBinding. From that point on you use it like you would any other WCF service

Where Would You Use This?

The inherit abilities of this binding provides a lot of benefits that can be used in many common situations. Since the service does not have to be online while clients send messages, the binding works very well in batch processing situations; clients can add messages to the queue all day, with the service being turned on at night to process the messages in a batch.

If you have a portion of your workforce that travels or needs to work disconnected at periods of time, MSMQ provides a way for them to work offline, with the queues syncing when the client reconnects to the network.

MSMQ is also an inherently reliable binding. Since messages are stored in a queue they can be “re-played” by the service if any sort of connectivity issues exist. If the message can be written to the queue it’s guaranteed that it will be delivered, at some point, to the service.

I hope this has piqued your interest in a very unappreciated and underused binding. MSMQ provides a robust and easy to use method to deliver messages to your service in a variety of enterprise scenarios. Most posts on how to utilize this binding will be coming soon…

Code on!

Speaking Tomorrow at MOCSDG !

James Bender — Wed, 01 Apr 2009 19:01:19 GMT

So, you’ve probably heard about Microsoft Azure by now, and how awesome it is. But there’s more to developing for Microsoft's Cloud Provider than web and worker roles.

I will be presenting a lap around Microsoft .NET Services, which provides some great infrastructure features that can make your Azure application development easier.

What? You’re not into the whole “cloud thing?”

Well then your in luck! Because with .NET Services you can still take advantage of these great features without having to build an “Azure application!”

What now? Oh, you’re not a “.NET developer?”

That’s cool, because .NET Services has SDK’s for Java AND Ruby! And they are available RIGHT NOW!

OK, since you have no more excuses, I’ll see you all at the Microsoft office at 6:00 tomorrow night!

And now, a little something for the .NET newbies…..

James Bender — Tue, 31 Mar 2009 13:37:30 GMT

Do you live within a car ride of Grand Rapids?

Have you always wanted to learn about .NET but didn’t know how or where to start?

Does the idea of learning some really cool stuff that you can use to shock and amaze your friends sound cool?

Well then have I got good news for you!

My buddy Chris Woodruff has organized the West Michigan .NET University, which takes place this Saturday in Grand Rapids. You’ll get the chance to learn .NET from some really smart people like Carey Payette , Jim Holmes, Phil Japikse, Rick Kierner and David Giard. I’ll also be there co-presenting a .NET Bootcamp with Len Smith and presenting a session on Web Services and WCF.

Registration is open, see you all there!

Are YOU going to the Microsoft Developer Conference?

James Bender — Tue, 13 Jan 2009 16:44:55 GMT

And if not, why not?

The MDC (Microsoft Developer Conference) makes a stop in scenic Detroit, MI next Thursday, January 22nd. If you missed the PDC, or even if you didn’t this is a great event and a terrific opportunity to see what’s next in the .NET development stack.

In addition to getting your very own copy of the Windows 7 Beta (assuming your one of the last three people who haven’t already gotten the torrent) you’ll be able to see presentations on Azure, Silverlight, F#, ASP.NET with JQuery and SQL Data services by some great speakers like Brian, Jennifer, Jay, Jeff and Jason, other Jeff, Carey, Chris and yet another Jeff.

Damn, that’s a lot of Jeff’s.

And at $99 bucks, that’s only $33/Jeff!

But wait, there’s more!

Alan will be there running ~~Open Spaces~~ Community Courtyard, where you’ll be able submit your own topics and talk with some way-smart people.

There will also be a Women Build workshop, which despite the name is open to both women and men. Admittedly I don’t know too much about that except that Lego’s are involved, Based on that I’m guessing it’s pretty cool!

So if you haven’t, go register now and I hope to see you all there!