Maximum client concurrent HTTP connections to a web service

While performing some load testing on a web service (using Specflow), we've stumbled on a two concurrent connections limitation. Apparently, the limitation is in the HTTP/1.1 .NET client implementation, as described in here. Our solution was to set the ServicePointManager.DefaultConnectionLimit property  to the number of concurrent requests we want to test, just before creating the channel.

Debugging a WCF service issue

A common scenario is your web service failing, but no application errors occur (assuming that you are catching all exceptions and logging them, that is). This is what I usually try:

• Turn on ASP.NET tracing (this is particularly important if you are setting aspNetCompatibilityEnabled to "true")
• Turn on WCF logging (don't forget to turn it off!)
• Take a look at Windows Event Viewer

Where in the world is WCF Test Client?

I keep myself making that question on a new VS install.

It's tipically here:

C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\WcfTestClient.exe

Although it will change according to your Visual Studio version (i.e. "10.0") and CPU architecture (i.e. "x86").

Forcing a Culture in the business logic

Not exactly a new topic, but a reminder. In my opinion, it's a good practise for your application business logic not to assume that it will be run in a particular Windows configuration, namely a specific culture. An "innocent" ToString() or Parse() method call in a double or DateTime struct is all that takes to break your code. Last week that happened at the office, some of our unit tests were only failing on some development machines. It turned out that some of team members have Windows configured to use GB English regional settings, while others have been using PT Portuguese settings. One approach to fix this is to force a culture in all calls of these methods (US English, for instance), but I think that is boring and easy to overlook. I prefer to force the culture for all calls, something like:

Thread.CurrentThread.CurrentCulture = 

   new CultureInfo("en-US");

 Here's how I have been doing it, depending on the component type.

WCF Service

Usually, I would put the code line in the Application_Start() method of the Global.asax class, since it would apply to every service in the project. However, the last time I've did it, we were using Castle Windsor for dependency injection, and this doesn't seem to work, as the container instantiates the service object in another thread. Solution: put the line in the service constructor.

Since we are also using ThreadPool for some of the tasks, I also had to add the line to the callback method.

Yes, I could also have used the <globalization> tag in the web.config, but that would imply activating ASP.NET compatibility in WCF, which I didn't want to (no problem on doing so, but I just wanted to avoid unnecessary entropy).

Console Application / Windows Service

Usually, I would just put the line in the Program class Main method, but since we are using TopShelf to abstract some of the Windows service boilerplate code, I had to put it elsewhere. Basically, in the WhenStarted() callback.

NUnit Test

Unit tests are basically class libraries, so there is no central point method. The best I came up with was putting the code in the StartUp method, for every unit test class. Since I'm being lazy, in reality I've only added it in every test class that was failing because of culture settings.

EF POCO objects and WCF

We have recently started to use Entity Framework using a Code First approach, including POCO classes. However, when we tried to use POCO object classes as parameters of web service calls, we got the following exception:

System.ServiceModel.CommunicationException: There was an error while trying to serialize parameter http://tempuri.org/:foo. The InnerException message was 'Type 'System.Data.Entity.DynamicProxies.FooClass_F952F109218D94AD325682E75C75F0EFF0D59311269F52F267E249FB9D8F7196' with data contract name 'FooClass_F952F109218D94AD325682E75C75F0EFF0D59311269F52F267E249FB9D8F7196:http://schemas.datacontract.org/2004/07/System.Data.Entity.DynamicProxies' is not expected. Consider using a DataContractResolver or add any types not known statically to the list of known types - for example, by using the KnownTypeAttribute attribute or by adding them to the list of known types passed to DataContractSerializer.'.  Please see InnerException for more details.

What's happening? Well, it happens that a runtime, POCO objects are not really POCO, but proxies that wrap the original POCO objects. WCF knows the POCO type, but not the subtype of the proxy class. How to fix it? There are several approaches, we just opted by a simple workaround: all our classes that need to be passed as parameters for a web service calls now implement ICloneable interface and are cloned just before the call.

Perhaps a more elegant approach would be using a specific class for the parameter of the WCF service and implement a mapper between the two types, but if you need a quick workaround the clone approach does the trick.