One of the key things in any application is to have an exception handler that logs any unhandled exception so that the application can be debugged in the future. In many applications I see this done by wrapping every external method in a try / catch block. While this works it has several drawbacks. First of all it is a pain to type the same code over and over again. It is easy to forget to add the try / catch / log block one one method. The biggest pain is if you need to change the way...

Sometimes on a WCF project you will get the error: Failed to generate code for the service reference 'YourReferenceName'.  Cannot import wsdl:portType  Detail: An exception was thrown while running a WSDL import extension: This is usually caused by a contract mismatch. For us it is when the assembly that contains our data contracts on the server and client are different. First thing to check is the output window but if nothing is there I have found using svcutil.exe from a visual studio command prompt to generate the proxy on the command line gives me the info...

I think WCF is a pretty sweet technology stack. It makes things work with each other quite easily..... until you use it for more than the default it was setup to handle. This usually results in some strange and hard to diagnose error messages. The #1 tip I have so far is to use the SvcConfigEditor.exe file that comes with the Windows SDK to edit your configuration files as it allows you to edit the configuration in a simple and visual fashion and makes it much harder to make errors in your config...

One thing that bugged me with WCF was when you auto generated your proxy client (using add/update service reference), that collections were turned into arrays. Granted it is trivial to convert them back to a collection if need be it is still a pain. Randomly I discovered that if you right click on the service reference and selecting "Configure Service Reference" (who knew!) that you can change this behaviour for both collections and dictionaries to be several different types:     Another nice item was to be able to change the access levels for generated classes and being able to add async operations only...

In my previous post WCF And Large Messages. I mentioned there was a better way to send large data. As I have been getting a lot of traffic on this topic here is the improved methodology: One of the really sweet features of WCF is to allow the streaming of messages between client and server. By default messages are buffered and once completely built they are sent. While this works great for small messages once you start sending large amounts of data (in my case a 50-70Mb file) it really pays off. For my case sending data as a large message...

****Just a forewarning that this is an interim step I took to move large messages. In my next post I will talk about streaming data via WCF which works a lot better for the scenario described here***** For one of my projects we are moving a large file to our service via WCF. By default WCF only allows small messages and arrays to be processed but in my case I am moving a 50-70Mb byte array around. There are a few things you will need to do to get large messages to move around. The first thing you will probably notice...