Monday, May 24, 2010

One of the issues with WCF is that is heavily depends on declarative configuration. In case of the SSL protocol, a basic ASP.NET WebService supports it “out-of-the-box” if the web server supports it. But a WCF service configured for noSSL calls will not accept SSL calls without an extra configuration. This article describes the issue and the ability to configure the service programmatically to lower the risk of misconfiguration.

Static configuration of WCF endpoints

Let’s start from a basic configuration of a service configured for noSSL calls:

As you can see I have a single endpoint with security mode set to None which corresponds to noSSL mode. With such static configuration the SSL is not a problem. You just define an extra endpoint with proper settings (mode set to Transport):

It means that everytime you expose your service under different address, you have to reconfigure it in web.config.

But having two endpoints with different bindings stops your service from working with the Visual Studio Integrated Web Server since it does not support the SSL protocol (you’ll get the exception from the integrated webserver saying that SSL is not supported).

The simplest solution for both issues is to have a two sets of configuration files. One used with the development environment would have a single endpoint for noSSL calls. The other one used in a production environment. However, having few or few dozens of services means that there’s a risk of the misconfiguration, revealed only in the runtime.

Creating endpoints dynamically

The other option however would be to create endpoints dynamically depending on the environment. This way no static configuration is required and the service would expose a single noSSL endpoint when working with the Integrated WebServer and two endpoints (SSL/noSSL) when deployed onto the IIS.

I have found few articles on the dynamic configuration of self-hosted WCF services, however it has been much harder to find a way to do it with the IIS.

To have your service configured dynamically, you start with the *.svc file to change the way the IIS initializes your service:

Wednesday, May 12, 2010

There is an obvious difference between System.Windows.Forms.Timer and System.Timers[System.Threading].Timer – the former is handled with Win32’s WM_TIMER message and thus it needs a message loop which usually means you need a Windows application.

But there’s also a much less obvious difference – and this difference is the reason to write this entry.

Suppose you set your Windows.Forms timer to 50 miliseconds and then a single Tick lasts a little bit longer:

What happens then? You see, a WM_TIMER message is constrained by the system so that is never occurs too often. It means that the message queue will not be flooded with extra messages and you are safe. In the above scenario, the RichTextBox would be updated once for a second, even if the timer is set to launch every 50 miliseconds.

But the case is completely different with the two latter timers! The operating system launches a new thread with every tick so that you are not safe from having multiple ticks running in the same time.

staticvoid Main( string[] args )

{

System.Threading.Timer t = new Timer( timer_callback, null, 0, 50 );

while ( true ) { }

}

staticvoid timer_callback( object state )

{

Console.WriteLine( DateTime.Now.ToString() );

Thread.Sleep( 1000 );

}

Run the above code snippet to see that the console is actually flooded with messages arriving independently much ofter than you’d expect. This time it’s important then to manually handle the flooding:

staticvoid Main( string[] args )

{

System.Threading.Timer t = new Timer( timer_callback, null, 0, 50 );

while ( true ) { }

}

staticbool worksNow;

staticvoid timer_callback( object state )

{

// exit if in the middle of action

if ( worksNow ) return;

try

{

// disable temporarily

worksNow = true;

Console.WriteLine( DateTime.Now.ToString() );

Thread.Sleep( 1000 );

}

finally

{

// make sure that the handler is always reenables

worksNow = false;

}

}

There’s still a small issue with such approach. This time, when the timer interval is only a fraction smaller than the time of the action, every second tick of the timer will exit because of the value true of the guarding worksNow variable but then there will be a long period of inactivity before next timer’s tick. You’d rather like the timer to resume the work immediately after the handler completes.

About

I am a software architect and an academic lecturer. I've been awarded Microsoft MVP in C# Architecture between 2005 and 2010. Got a PhD in computer science in 2008.
Currently I work mostly with C# and Javascript and love both languages. I consider myself a design/architecture patterns evangelist.
In 2003 I wrote first Polish book on C#/Windows programming, "Windows oczami programisty" (Windows through the eyes of a programmer) (the book is out of print)