Category: .wcf

The using statement in C#, seems to be quite useful especially to a developer as theoretically, you not have to do anything to release any memory you might have used and the CLR automatically frees up this memory for you.

However, over time, I have had so many issues with it and subtle problems (in certain situations) I am starting to avoid it now.

The two best examples that I can think of are database connection pools and WCF connections. You might think that a “using” statement would close the connection and free up the resources when the scope finishes – but it does not. If you are thinking that a “Close()” is called for you automatically, you might be surprised to know that it is not.

For example if you are using a connection pool, over time you will get timeout errors (which are quite difficult to track down if you got some intelligent tool creating your DALs for you). This of course is because the connections are not closed and overtime you end up exhausting your pool. To avoid this you should explicitly call a “close()” method.

Similar story with WCF. If you find that after a few calls (or over some longer period of time), if you start seeing some degradation in performance and your response times taking a long time, then you need to explicitly close the connection as the using statement will not do it for you.

Also, if you are testing your WCF service on XP/Vista you might hit the built-in limit that limits the number of concurrent connections that XP/Vista allow.

Lastly, if you are using WCF, if possible then upgrade to .NET 3.5 as there are a lot of benefits which can get out of the box.

It took a while for me to get around to this but the P2P Code to go along with my MSDN Article "P2P Programming with WCF and .NET v3.5". I don't know why this code was not available on MSDN in the first place.

Any ways, the can be downloaded from here (456.2 KB).

Someone recently asked about how to load test WCF – apart from the usual things like LoadRunner, VSTS Test Load Agent, etc a couple of other interesting options came up. One is WCF Load Test and the other JMeter. WCF Load Test generates a unit test taking in data from a a trace file along with the relevant WCF proxy or interface.

I must admit, JMeter would not have been one of the things that would have come to mind to me in this context, but technically there is nothing stopping from you using it as you can stress and load test any http request.

When you install SP1 for .NET 3.0 by default that changes the throttling settings you might be use to. You could get into a situation where a number of calls are processed and then they stop with the client eventually timing out. To get around this you either explicitly close your connection (which is a good practice in most cases) or change the serviceThrottling setting in your WCF config.

WCF's configuration is somewhat complex and the first time you start using it can been daunting. Below is an image of the schema published by Microsoft. You can print this out on a A3 or something and use it has a handy reference.

In case you were wondering why your Indigo / WCF Jan CTP code does not work with the Feb CTP, then you can find a list of all the breaking changes published by MS. It is interesting to note that Microsoft is changing the namespace so late in the game, but I would rather they get it right now and make breaking changes as opposed to when Indigo ships.

Contract inheritance (via CLR interface inheritance) is pretty cool allowing you to support versioning and contract aggregation in WCF, the catch though is if you have a Duplex interface then the callback interface must follow the same hierarchy. So if your primary interface say is IMyInterface which inheritances from ISomeInterfaceOne and ISomeInterfaceTwo, then the callback interface also needs to have the same chain or you will get an InvalidContractException. Here is an example from MSDN:

[ServiceContract(CallbackContract = IACallback)]
interface IA : IB {}
interface IACallback : IBCallback {}
[ServiceContract(CallbackContract = IBCallback)]
interface IB {}
interface IBCallback {}

If you are writing an Indigo service and you can an error for something like the one shown below, then essentially you change the interface (i.e. your contract) you implemented in Indigo (now WCF), but forgot to change the interface in the web.config.

<endpoint contract=“MY-TYPE-HERE” binding=“wsHttpBinding“/>

<snip>
Could not resolve type IMyService, contract cannot be created. Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.InvalidOperationException: Could not resolve type IMyService, contract cannot be created.

Source Error: An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

Stack Trace:
[InvalidOperationException: Could not resolve type ICalculators, contract cannot be created.]
</snip>

eWeek has an interview with Don Box, where he talks about what is next from Microsoft in terms of the next-gen apps. He talks about what is most interesting in his space, between Indigo, WWF, LINQ, etc. Also what you should think of as an Enterprise Architect when designing your contracts – WSDL-First or Contract-First.

Well you can’t. As you might be aware that the .NET runtime are different between Visual Studio 2005 RTM and WinFX Sept CTP build, and the only way you can get this to work together is fall back on Beta 2 of Visual Studio 2005 – which is the only supported  version as of now. On the other hand in about a week or so from now, a new WinFX build is supposed to be publicly released, which can coexist and keeps each other happy. If you can wait for a week I could recommend the latter.

If you are hosting, your Indigo service in IIS, then you need a .svc file which basically tells IIS what assembly do you want to wire up to handle the request. Seems like on RC1 Beta 1 and another prior build (June CTP – I think, not sure though), there is a bug in the parser. Lets look at the example which in some places does break and in others does not break:

<%@Service language=c# Debug=”true” class=”Indigo2.Math” %>
<%@Assembly Name=”Indigo2″ %>

If you notice the language attribute (on line 1), is it not in quotes and this works ok on RC1. But it does break if you do put in the quotes in some other builds, so if you had the same line as below then someplace’s it will break:

<%@Service language=“c#” Debug=”true” class=”Indigo2.Math” %>

This of course is not a show stopper, but if you are getting weird errors in IIS and are not seeing your service’s MEX, as you were expecting, this could be one of the areas among others you can look out for.

My Beta1 is still downloading, so have not had a chance to try this on that to see if it has been fixed or not; if any one has tried it then let me know; alternatively, when I finish downloading it and try it out, will post my feedback here.

My colleague, Chris Periris has an article where he talks about how to host an indigo servince in various forms. In case you did not know Indigo can be hosted in various surrogate processes (in addition to itself) such as IIS, EXE, NT Service, COM+, etc.

Now that I am not sleeping and read my earlier post (*grin*) about MSMQ (ver. 3.5) and Indigo, I would like to clarify a couple of things. One, you don’t have to have MSMQ 3.5 installed, only if you want to use MSMQ (i.e a queue channel). If you are using tcp, udp, http, etc, then you don’t need this. And two, if you do install MSMQ, then on Windows 2003 Server you need to install the SP1 first. Also, you might want to get the checked build on a dev box as that has debug info.

As I found the hard way, if you require queued channels to work in Indigo, then you need to install MSMQ Ver. 3.5 which is specially required for Indigo. Interestingly, the installer does not install this (for check that even MSMQ is installed), but then by design Indigo can use any kind of channel. This version of MSMQ provides functionalities like per-application dead letter queue and remote transactional read that are used by the “Indigo” queued channel on Windows Server 2003 and Windows XP. You can get the downloads from here. Below are the direct links:

• WindowsServer2003-MSMQ-AMD64 (2584 kb)
• WindowsServer2003-MSMQ-IA64 (3647 kb)
• WindowsServer2003-MSMQ-X86 (1612 kb)
• WindowsXP-MSMQ-X86 (1475 kb)

Also make sure to get the COM+ hotfix and to get any of this working of course, you need the Indigo RC1 Beta – yes it is a release candidate for the beta, not a RC for RTM. Off to catch some zzzzz now.