# Tuesday, January 17, 2012

To celebrate DevelopMentor’s move to offices at 120 Moorgate in London, myself and Andy Clymer are presenting an evening of C# 5 Async. The next version of the C# language has built-in support for async processing. We’ll show you how it improves over the previous models and how it works under the covers.

This event is on Monday the 6th February from 5-7 and is free to attend, just register with the DevelopMentor office on 01242 525 108 or email salesuk@develop.com

Tuesday, January 17, 2012 8:18:38 AM (GMT Standard Time, UTC+00:00)  #    Disclaimer  |   | 
# Wednesday, September 28, 2011

Thanks to everyone for attending my sessions on the Reactive Framework and Garbage Collection at Basta 2011, you can download the demos here:

Reactive Framework

Garbage Collection

Wednesday, September 28, 2011 11:46:31 PM (GMT Daylight Time, UTC+01:00)  #    Disclaimer  |   | 
# Wednesday, June 15, 2011

Just a heads up that when self hosting the new WCF Web API. By default if you try to add the Web API references via Nuget you will get a failure (E_FAIL returned from a COM component).

This is due to the likely project types (Console, Windows Service, WPF) defaulting to the client profile rather than the full framework. If you change the project to the full framework the Nuget packages install correctly

Yet again bitten by the Client Profile

Wednesday, June 15, 2011 10:21:33 AM (GMT Daylight Time, UTC+01:00)  #    Disclaimer  |   | 
# Friday, February 04, 2011

I have just found myself answering essentially the same question 4 times on the MSDN WCF Forum about how instances, threading and throttling interact in WCF. So to save myself some typing I will walk through the relationships here and then I can reference this post in questions.

WCF has 3 built in instancing models: PerCall, PerSession and Single. They are set on the InstanceContextMode on the ServiceBehavior attribute on the service implementation. They relate to how many instances of the service implementation class get used when requests come in, and work as follows:

  • Single – one instance of the implementation class is used for all requests
  • PerCall – every request gets its own instance of the implementation class
  • PerSession – this is the slightly odd one as it means every session gets its own instance. In practical terms it means that for Session supporting bindings: NetTcpBinding, WSHttpBinding, NetNamedPipeBinding, etc, every proxy gets an instance of the service. For bindings that do not support session: BasicHttpBinding, WebHttpBinding, we get the same effect as PerCall. To add to the confusion, this setting is the default

By default WCF assumes you do not understand multithreading. Therefore, it only allows one thread at a time into an instance of the service implementation class unless you tell it otherwise. You can control this behavior using the ConcurrencyMode on the ServiceBehavior; it has 3 values:

  • Single – this is the default and only one thread can get into an instance at a time
  • Multiple – any thread can enter an instance at any time
  • Reentrant – only makes a difference in duplex services but means that an inbound request can be received from the component you are currently making a request to (sounds a bit vague but in duplex the role of service and client are somewhat arbitrary)

Now these two concepts are different but have some level of interaction.

If you set InstanceContextMode to Single and ConcurrencyMode to Single then your service will process exactly one request at a time. If you set InstanceContextMode to Single and ConcurrencyMode to Multiple then your service processes many requests but you are responsible for ensuring your code is threadsafe.

If you set InstanceContextMode to PerCall then ConcurrencyMode Single and Multiple behave the same as each request gets its own instance

For PerSession ConcurrencyMode Multiple is only required if you want to support a client sending multiple requests through the same proxy from multiple threads concurrently

Unless you turn on ASP.NET Compatibility, WCF calls are processed on IO threads in the system threadpool. There is no thread affinity so any of these threads could process a request. The number of threads being used will grow until the throughput of the service matches the number of concurrent requests (assuming the server machine has the resources to match the number of concurrent requests). Although the number of IO threads is capped at 1000 by default, if you hit this many then unless you are running on some big iron hardware you probably have problems in your architecture.

Throttling is there to ensure your service is not swamped in terms of resources. There are three throttles in place:

  • MaxConcurrentCalls – the number of concurrent calls that can be made – under .NET 4 defaults to 16 x number of cores
  • MaxConcurrentSessions – the number of concurrent sessions that can be in in flight – under .NET 4 defaults to 100 x number of cores
  • MaxConcurrentObjects – the number of service implementation objects that are in use – defaults to the sum of MaxConcurrentCalls + MaxConcurrentSessions

In reality, depending on whether you are using sessions or not, the session or call throttle will affect your service the most. The object one will only affect your service if you set it lower than the others or you do something unsual and handle the mapping of requests to objects yourself using a custom IInstanceContextProvider

You can control the throttle values using the serviceThrottling service behavior which you set in the config file or in code

Friday, February 04, 2011 9:50:40 PM (GMT Standard Time, UTC+00:00)  #    Disclaimer  |   | 
# Tuesday, June 08, 2010


I’m speaking at Software Architect 2010 in October. I’m going to be delivering two sessions on Windows Workflow Foundation 4.0: the first explains the basic architecture and looks at using workflow as a Visual Scripting environment to empower business users. The second looks at building big systems with workflow concentrating on the WCF integration features.

In addition to that I’ll be delivering two all-day workshops with Andy Clymer: Building Applications the .NET 4.0 Way and Moving to the Parallel Mindset with .NET 4.0. The first of these will take a number of new features of .NET 4.0 and show how they can be combined to create compelling applications. The second will look at the Parallel Framework Extensions (PFx) introduced in .NET 4.0 examining both the rich functionality of the library, how it can be best leveraged avoiding common parallel pitfalls and finally looking at patterns that aid parallelisation of your code

.NET | PFx | RSK | WCF | WF | WF4
Tuesday, June 08, 2010 10:52:40 AM (GMT Daylight Time, UTC+01:00)  #    Disclaimer  |   | 
# Monday, June 07, 2010

I’ve been working with the Unity IoC container from Microsoft Patterns and Practices recently. Its mostly straightforward as IoC containers go but one thing had me puzzled for a while as its not really documented or blogged as far as I can see; so I decided to blog it so hopefully others looking will stumble across this article

Lets start off with a simple example: I have two interfaces: IService and IRepository that live in the Interfaces class library

   1: public interface IService
   2: {
   3:     void DoWork();
   4: }
   1: public interface IRepository
   2: {
   3:     string GetStuff();
   4: }
I also have two implementations in the Services class library: MyRepository 
   1: public class MyRepository : IRepository
   2: {
   3:     public string GetStuff()
   4:     {
   5:         return "TADA!!";
   6:     }
   7: }

and MyService

   1: public class MyService : IService
   2: {
   3:     private IRepository repository;
   5:     public MyService(IRepository repository)
   6:     {
   7:         this.repository = repository;
   8:     }
   9:     public void DoWork()
  10:     {
  11:         Console.WriteLine(repository.GetStuff());
  12:     }
  13: }

Notice that MyService needs an IRepository to do its work. Now the idea here is I’m going to wire this together via dependency injection and the Unity IoC container. So I have my application

   1: class Program
   2: {
   3:     static void Main(string[] args)
   4:     {
   5:         UnityContainer container = new UnityContainer();
   6:         UnityConfigurationSection section = (UnityConfigurationSection)ConfigurationManager.GetSection("unity");
   7:         section.Configure(container);
   9:         IService svc = container.Resolve<IService>();
  11:         svc.DoWork();
  12:     }
  13: }

Notice as we’re using IoC that there are no hard coded dependencies – everything is wired up via the container. However, there must be some information about how the interfaces map to concrete types and this is in the config file

   1: <configuration>
   2:   <configSections>
   3:     <section name="unity" type="Microsoft.Practices.Unity.Configuration.UnityConfigurationSection,Microsoft.Practices.Unity.Configuration"/>
   4:   </configSections>
   6:   <unity>
   7:     <typeAliases>
   8:       <!-- Lifetime Managers -->
   9:       <typeAlias alias="singleton" type="Microsoft.Practices.Unity.ContainerControlledLifetimeManager"/>
  11:       <!-- Interfaces -->
  12:       <typeAlias alias="IService" type="Interfaces.IService,Interfaces"/>
  13:       <typeAlias alias="IRepository" type="Interfaces.IRepository,Interfaces"/>
  15:       <!-- Implementations -->
  16:       <typeAlias alias="service" type="Services.MyService, Services"/>
  17:       <typeAlias alias="repository" type="Services.MyRepository, Services"/>
  19:     </typeAliases>
  20:     <containers>
  21:       <container>
  22:         <types>
  23:           <type type="IService" mapTo="service">
  24:             <lifetime type="singleton"/>
  25:           </type>
  26:           <type type="IRepository" mapTo="repository">
  27:             <lifetime type="singleton"/>
  28:           </type>
  29:         </types>
  30:       </container>
  31:     </containers>
  32:   </unity>
  33: </configuration>

Now all of this works fine and is simple Unity stuff. We use constructor injection to get the repository implementation into the service constructor. However, I’ve decided the service needs a timeout that I will generally configure in the config file. However to make Unit Testing simple I’ll add another constructor to MyService so I can pass a specific timeout

   1: public class MyService : IService
   2: {
   3:     private IRepository repository;
   4:     TimeSpan timeout;
   6:     public MyService(IRepository repository, TimeSpan timeout)
   7:     {
   8:         this.timeout = timeout;
   9:     }
  11:     public MyService(IRepository repository)
  12:     {
  13:         this.repository = repository;
  14:         timeout = GetTimeoutFromConfig();
  15:     }
  17:     private TimeSpan GetTimeoutFromConfig()
  18:     {
  19:         return default(TimeSpan);
  20:     }
  22:     public void DoWork()
  23:     {
  24:         Console.WriteLine(repository.GetStuff());
  25:     }
  26: }

Now I try to run the application and I get a pretty ugly error

Unhandled Exception: Microsoft.Practices.Unity.ResolutionFailedException: Resolution of the dependency failed,
type = "Interfaces.IService", name = "(none)".
Exception occurred while: while resolving.
Exception is: InvalidOperationException - The type Int32 cannot be constructed.
You must configure the container to supply this value.

Now that’s weird – I have no types that take an Int32! This is caused by Unity’s default behavior where it will try to resolve on the constructor with the most parameters (on the basis that this one will have the most dependencies that can be injected). It tried to resolve the TimeSpan and so looks at the TimeSpan and tries to resolve its constructor which can take an Int32. I actually want to tell it to use a different constructor and I can do this in two ways: annotate the constructor I want to use with the [InjectionConstructor] attribute

   1: [InjectionConstructor]
   2: public MyService(IRepository repository)
   3: {
   4:     this.repository = repository;
   5:     timeout = GetTimeoutFromConfig();
   6: }

But personally I don’t like this. It forces the services assembly to take a dependency on Unity and the service has knowledge about how its being constructed. What I really want to do is specify this in config. This isn’t very well documented from what I can see but what you do it specify the constructor and how to resolve the parameters against the type mapping in the config – i.e.

   1: <type type="IService" mapTo="service">
   2:   <lifetime type="singleton"/>
   3:   <constructor>
   4:     <param name="repository">
   5:       <dependency/>
   6:     </param>
   7:   </constructor>
   8: </type>

As well as specifying dependencies you can also give explicit values by using <value/> instead of <dependency/>. This model I think is a lot cleaner than the attribute approach.
Monday, June 07, 2010 11:14:26 PM (GMT Daylight Time, UTC+01:00)  #    Disclaimer  |   | 
.NET | Dublin | WCF | WF
Monday, June 07, 2010 10:05:40 PM (GMT Daylight Time, UTC+01:00)  #    Disclaimer  |   | 

The Visual Studio 2010 Power Tools have just been released. There’s all sorts of goodness in here: new flexible tab handling in the VS shell (vertical tab groups, tabs grouped by project, dropping of rarely used tabs, etc); a new searchable Add Reference dialog; new editor enhancements to make navigation easier and much more

I’ve been playing with it for the last couple of hours and its very neat. Of course I don’t use Resharper or CodeRush (I use too many machines I don’t control to become dependent on them) so some of these features may be available in those tools. But for me the power tools are a welcome addition to the IDE

Monday, June 07, 2010 8:26:40 PM (GMT Daylight Time, UTC+01:00)  #    Disclaimer  |   | 
# Tuesday, March 30, 2010

Rock Solid Knowledge on iTunes is live! We’ve taken the feed to our free screencasts and they are now available through iTunes via the following link


Now you can watch them on the move

.NET | EF4 | PFx | RSK | SilverLight | WCF | WF | WF4
Tuesday, March 30, 2010 9:13:22 PM (GMT Daylight Time, UTC+01:00)  #    Disclaimer  |   | 
# Wednesday, March 17, 2010

Thanks to everyone who attended my sessions at DevWeek 2010. I’ve now uploaded the demos which you can find at the following locations

A Day of .NET 4.0 Demos

Windows Workflow Foundation 4.0 Demos

Creating WCF Services using WF4 Demos

I’ll be around for the rest of the conference so drop by for a chat at our developer clinic in the exhibition area

.NET | EF4 | RSK | WCF | WF | WF4
Wednesday, March 17, 2010 8:13:59 AM (GMT Standard Time, UTC+00:00)  #    Disclaimer  |   |