Rick Rainey

Setup Identity and Access Tools for Visual Studio 2012

2012-09-26T21:05:51Z

There are a couple of options for installing the tools that are mentioned here.

Here are the steps to installing Identity and Access Tools from the Extension Manager in Visual Studio:

Start Visual Studio 2012.

From the menu select TOOLS | Extensions and Updates. . .

Click the Online extensions node in the tree view on the left.

Search for “identity” in the search field in the upper right

Click the Download button to download and install the package.

After the install, you will be prompted to restart Visual Studio.

After restarting Visual Studio, you should now see the Identity and Access. . . option if you right-click on your project.

Which WCF Binding Is Best?

2012-05-20T16:47:00Z

[Updated - 10/3/2012: An astute reader pointed out that the sample below will produce some inconsistent results based on the order of the bindings being compared. This is because of things like JIT compilation, internal caching, etc. As a quick fix, I added two lines of code to the CompareBindings method to "warm up" the binding elements that will be compared. ]

Which binding is best? That’s a question I hear and see a lot. When it’s asked of me, the answer is always – “it depends”. It’s impossible to know from that simple question which binding is going to “best” meet your application requirements. Quickly after I start probing for more information, the question narrows down to which binding is fastest? Again, the answer to that question is going to be (you guessed it) – “it depends”.

There are 4 transport schemes that WCF supports: http, net.tcp, net.pipe, and net.msmq.

If your application requires queuing, then you only have the option of using the bindings that support queuing. In other words, there’s nothing to compare. If your application will be called from other applications/services on the same machine, then you should be using the NetNamedPipeBinding for cross-process calls on the same machine. So, again, there’s really nothing to compare.

So, when comparing bindings, the transport scheme pretty much shakes out to a comparison between http and net.tcp. These are the two left that will be used when crossing machine boundaries (actually going out on the NIC). There are several bindings and endless binding configurations that potentially can use one of these two schemes. For example, does your application require security? If so, then you have several decisions to make, such as do you want to use transport or message security? What kind of credentials are you going to prompt your client for? Is Federation/SSO a requirement? Just to name a few. What about your message payload size? Is it large/small? Do you have transactional requirements for message exchanges? Are there interoperability constraints you need to account for? Will your service require sessions? And so on…. So, you can begin to see why the answer to such a question is always “it depends”. Instead, a thoughtful discussion about the application requirements is necessary to offer up sound advice on the subject. When you do compare bindings, you need to make sure you’re comparing bindings equally – that is, all the bindings meet the requirements for your application. As an example, it’s not a fair comparison to compare NetTcpBinding and BasicHttpBinding with their default values. These bindings offer different features by default.

Still, people just want to know, if “conditions xyz” exist, which binding is going to be fastest? For that, I have a little sample application I put together to help you answer that question yourself. Knowing that bindings are simply a collection of binding elements to support various features, you can start to construct bindings and binding configurations to compare against each other with little effort. Below is a brief description of the primary methods in this sample application and how you may want to customize it for your needs.

TestBinding

This method hosts the service (TestService), instantiates a client proxy, and calls the ProcessData method using the binding and data provided. It returns a StopWatch to the caller so the elapsed time can be observed. In this method, I have the StopWatch starting just before creating the client proxy and opening the channel. I stop it after closing the client proxy. You may want to make your test more granular and put the start and stop immediately before and after the call to ProcessData (if you don’t want the elapsed time to include creating the channel).

CompareBindings

This method invokes the TestBinding method for an array of bindings you provide. It will generate some random data for the test using the size you specify. For each test, it will output the binding’s elements and the results from the StopWatch returned from TestBinding. Other than changing the format of the output or writing more binding configuration data to the console, you probably won’t change this.

Main

This is where I create some bindings, add them to an array of bindings, and call the CompareBindings method. This is where you will do most of your experimenting. Create the bindings with the elements you want/need. Add them to the binding array and call CompareBindings.

Sample Output

This is an example of the output with the application running on my single machine. In my test, there is no network latency since everything is local. You may want to separate your tests out into a separate client and service application so you can include network latency in your test. Also, this output is not comparing equal bindings so don’t read too much into my output. I just put together a few bindings so you could see how to construct the bindings to meet your needs.

Hopefully this helps identify which bindings are going to be best for your application and also shine some light on why it’s not a quick-and-simple answer.

You can download the full application code from here.

Using a Server Certificate to Protect Web.Config

2012-02-28T01:42:47Z

Using ASP.NET’s protected configuration feature is recommended when your Web.Config file contains sensitive information. The .NET Framework gives you two protected configuration providers, DpapiProtectedConfigurationProvider and RsaProtectedConfigurationProvider. Depending on your application requirements, you can use either of these to get the job done.

You can also create your own protected configuration provider and there is a sample here that shows an implementation using the TripleDESCryptoServiceProvider for encrypting and decryption. Implementing your own protected configuration provider is simply a matter of writing a class that derives from ProtectedConfigurationProvider. In this blog post, I’m going to show a another custom provider option using a server certificate for the encryption and decryption.

Implement the Provider

Using Visual Studio 2010, create a new Class Library project and inherit your class from ProtectedConfigurationProvider. The ProtectedConfigurationProvider class is located in the System.Configuration assembly. So, you will need to add a .NET Reference to System.Configuration and also add a using statement to the top of your class for the System.Configuration namespace.

This provider will perform encryption and decryption using the keys from an X509 Certificate. The X509Certificate2 class is located in the System.Security assembly. So, you will need to add a .NET Reference to System.Security and also add a using statement for the System.Security.Cryptography.X509Certificates namespace. Next, add a private X509Certificate2 member to the class that will be used as a reference to the server certificate.

This provider will be installed in the GAC so it is easily accessible by ASP.NET and the aspnet_regiis.exe tool on the server. Therefore, add a strong name key file to the project. Later on, you will need the public key token from the signed assembly. To make it easy to get this, add the following post-build event to the project properties:

"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\sn.exe" -T "$(TargetPath)"

Note: The path to sn.exe may differ on your machine.

There are 3 methods you must override to implement the provider: Initialize, Encrypt, and Decrypt. The shell of your class should look like this.

The implementation for Initialize is shown below. This code is pretty straight forward. The key thing to note is that this provider expects CertSubjectDistinguishedName to be defined in the <configProtectedData> section of the config. More on how that get’s defined later.

The implementation for Encrypt and Decrypt is shown here.

That’s all there is to it. When you build the project, your provider will be signed and the post-build step from above will display your public key token in the Output window. You will need this later.

Deploy the Provider

This provider needs to be installed in the GAC on the target IIS server. You probably won’t have gacutil.exe available on the target server to install this into the GAC. So, adding a Visual Studio Installer Setup Project to your solution will simplify this process for you.

In your Setup Project, add the Global Assembly Cache Folder to the File System Target and specify the output from the protected configuration provider project.

Build the setup project and copy the Setup.exe and X509ProtectedConfigProviderSetup.msi file to your target IIS server. For the purposes of this post, I’m deploying to IIS 7.5 / Windows Server 2008 R2.

On the target server, run the Setup.exe to install the provider. Choose Everyone when prompted by the installer to make the provider available for Everyone or Just me. The provider assembly will be installed in C:\Windows\Microsoft.NET\assembly\GAC_MSIL.

Create the Server Certificate

I’m using a self-signed certificate from IIS 7.5. This certificate will function as both the SSL certificate for my site as well as provide support for my custom provider to encrypt and decrypt sections of the web.config. Instructions on how to create a self-signed certificate using IIS Manager can be found here.

Since my custom provider will be using the keys from the certificate, the IIS worker process (w3wp.exe) will need read access to the certificate. In IIS 7.5, the default identity for the DefaultAppPool is ApplicationPoolIdentity, which we’ll give read access to. Information on this identity can be found here. To grant read access to the certificate, follow these steps.

Open Microsoft Management Console (mmc.exe).
Select File > Add/Remove Snap-in and add the Certificates snap-in for the Computer Account.
Expand the Personal > Certificates folder, where the self-signed certificate is located.
Right-click on your certificate and select All Tasks > Manage Private Keys.
Click the Add button and add IIS AppPool\DefaultAppPool to the object name field.
Click the Check Names button and it should resolve to DefaultAppPool.
In the Permissions section, give DefaultAppPool Read permissions only.

Encrypting the Web.Config

A common scenario for encrypting sections of a web.config are when there are connection strings in the file. Suppose I have a web application with a connection string in the web.config such as this that I want to encrypt using my custom protected configuration provider.

Add the <configProtectedData> element to the web.config so that it references the fully qualified name of the custom provider assembly, as shown below. Notice that here is where we add the CertSubjectDistinguishedName setting that our custom provider looks for.

With this information in the web.config, deploy the application to the target IIS server.

On the target IIS server:

Open a command prompt.
Change directory to C:\Windows\Microsoft.NET\Framework64\v4.0.30319.
Type the following command to encrypt the <connectionStrings> section of the web.config.

aspnet_regiis –pe “connectionStrings” –app “/MyWebApp” –prov “X509Provider”

Note: The –app parameter will be the name of your web application.

If you go look at the web.config, you will see that the <connectionStrings> section has been encrypted using the custom provider.

The last thing to do is test it to make sure that ASP.NET can decrypt the contents as needed to return page requests (see below). The certificate error is because I’m using a self-signed certificate in my sample. But, as you can see, ASP.NET is able to successfully use the custom provider to decrypt the connection string to retrieve data from the database.

Monitoring Client-Outbound WCF Calls

2012-01-27T23:27:00Z

Recently a colleague asked me if I knew of a way to monitor outbound WCF calls for an application. He just wanted to be able to see the number of outbound calls an application was making. Performance Monitor normally provides the answer to these kinds of questions. Unfortunately, the performance counters for WCF are primarily server side (incoming) counters. No problem – just add a custom performance counter. Well, that is great if you have the luxury of being able to modify the application to populate the new counter. Unfortunately, this luxury didn’t exist either. So, what can we do?

While working on another issue, I stumbled onto this little event, 218 – ClientOperationCompleted, that is one of the WCF events emitted in Analytic Tracing with ETW. With this I am able to see outbound calls, and even filter the calls down to a particular service contract, process, or even destination address. Here is the solution I came up with.

Open the Windows Event Viewer.

Expand out Applications and Services Logs > Microsoft > Windows.

Right-click on Application Server-Applications and select View > Show Analytic and Debug Logs.

Right-click on Analytics under the Application Server-Applications folder and select Enable Log.

Right-click on Analytics again and this time select Filter Current Log…

In the Filter Current Log dialog, enter 218 for the Event ID and click OK.

While this filters the events to those with ID 218, it still may not deliver what you want. For example, after turning this on and executing a couple of WCF calls from my client, I noticed there were over 100 events (from other applications running on my machine). I really only wanted to see the events from my client application I’m interested in. If you drill into one of the events you can see the EventData available to query on. For example, Action, ContractName, Destination, AppDomain are ones I found useful.

Having this information, it’s possible to write a query to provide exactly what I want.

Right-click on Analytics again and select Filter Current Log…

In the Filter Current Log dialog, click on the XML tab.

Click on the Edit query manually checkbox so you can edit the query directly.

Replace the query with your custom query. Here are a couple of examples to get started.

If you want to filter on outbound calls for a particular contract name…

<Select Path="Microsoft-Windows-Application Server-Applications/Analytic">*[System[(EventID=218)]] and *[EventData[(Data[@Name="ContractName"]="YourServiceContractName")]]</Select>

</Query>

</QueryList>

If you want to filter on outbound calls for a particular process…

<Select Path="Microsoft-Windows-Application Server-Applications/Analytic">*[System[(EventID=218)]] and *[EventData[(Data[@Name="AppDomain"]="yourprocess.exe")]]</Select>

</Query>

</QueryList>

You get the idea. You can adjust the query to meet your specific needs.

Why scriptLocation may not work when pointing to a proxy script file in your application config file.

2011-03-25T18:38:06Z

Consider this scenario: You have a .NET application that issues HttpWebRequests to a remote server. You deploy this application to an environment that requires proxy servers be configured using a proxy script file (WPAD / PAC). The solution is pretty simple. In your app.config, you can add this configuration:

<system.net>

</defaultProxy>

</system.net>

This, of course, assumes your script file is named wpad.dat and is hosted on your IIS server. Adjust this value as appropriate for your environment.

Arriving at this simple configuration recently proved to be a very challenging issue for me. When I first tried this, my configuration looked like this:

<system.net>

<proxy usesystemdefault="False" scriptLocation="http://<IIS Server or IP Address>/wpad.dat" bypassonlocal="True" />

</defaultProxy>

</system.net>

Notice, the only difference is the additional assignment of the bypassonlocal attribute. Which, at least in my experience, is a pretty common thing to do. But, in this case, it didn’t work! Why? If you like debugging, read on….

I captured a netmon trace and what I found was that my application was trying to establish a direct TCP connection to the target URL rather than establishing a connection with the proxy server that my proxy script would return. For example,

In a working scenario, you would expect to see something like this in a netmon trace. Here, we establish a TCP connection with the proxy server, then issue an HTTP CONNECT on that connection, requesting a connection to the target URL, and finally setup SSL for secure transport.

Going back to my failing scenario, I attached a debugger to my client and saw this exception – validating what I saw in the netmon trace.

So, why is this happening? I decided to look at the actual instance of the WebProxy that gets created when you configure .NET to use a proxy server and found a suspicious value for a ScriptEngine member.

Yes, there should be a value there. The ScriptEngine is what compiles and runs my proxy script identified in the scriptLocation property above. If there is not a ScriptEngine, then there can be no proxy. If there is no proxy, then we try to connect directly to the target url, which is exactly what we see in the netmon trace above. This is why we were not successful when trying to use the proxy script. So, now the question becomes, why is the ScriptEngine null?

If you think about it for a while, it starts to make some sense. A proxy script has a single function that has to be implemented called FindProxyUrl. This function takes two parameters, one of which is the target url, <host>, that you ultimately want to connect to. The implementation details for this function can obviously vary from one environment to the next. But, whether or not to connect directly to the target url or go through one of the proxy servers that the script is programmed to return is ultimately a decision made in the script. So, it is somewhat contradicting if you tell .NET to use a proxy script through the scriptLocation property and also set the bypassonlocal property.

After some collaboration with one of our Networking Escalation Engineers, it was pointed out to me that .NET will delete the ScriptEngine if it gets an instruction to set the bypassonlocal property. This happens whether you set bypassonlocal to true or false. Just the act of setting bypassonlocal results in the WebProxy deleting the ScriptEngine.

So, as I showed above, don’t use bypassonlocal if you are also specifying the scriptLocation.

If you want to learn more about how proxy scripts actually work, there is a nice article here. It is dated, but still a very good read.

Optimizing Intermediary Services for throughput

2010-03-22T22:52:54Z

I recently had the privilege of working with a couple of engineers (Naveed Zaheer and Manoj Kumar) in an internal lab setting to see how much throughput we could achieve through the Managed Services Engine (MSE) and a downstream WCF service hosted in IIS.

This post highlights some configuration settings that were applied during our work to achieve the results we were looking for. The findings here are specific to the environment we were testing in, which was a controlled lab setting. Any use of these settings should be tested in your own environment prior to placing them in a production environment.

While these findings were specific to testing that was done for MSE, the findings here could be beneficial to anyone who has a service intermediary in their environment.

Environment

The figure below illustrates at a high level the environment we were testing in. The users were simulated using 2 Visual Studio 2008 Test Agents simulating 100 users. The MSE Server and IIS Target WCF Server were both dual-proc machines. The target WCF Service was a singleton service and the method we were calling simply would sleep for 100 milliseconds and return.

MSE, for those not familiar with it, is a service intermediary that sits between a WCF service and its clients. This intermediary piece virtualizes service endpoints for the clients to consume and brokers the calls to the physical WCF service. For more information please refer to these resources.

Service Virtualization – Executive Summary

MSDN Magazine: Service Virtualization With The Managed Services Engine

An Introduction to Service Virtualization on the Microsoft .NET Platform

A CTP of the solution is available here. This solution is also deliverable through Microsoft Consulting Services.

Problem

Initial tests revealed that we could process ~ 55 requests/second. This baseline number was concerning considering the user load of 100 users and the short duration (100 milliseconds) of the method being called. Simple and conservative math would tell you that even if it took a full second per call, we should be able to handle 100 requests / second.

Resolution

Adjustment on the target WCF Service machine

The first thing we noticed was very limited throughput on the backend target WCF service server. There was WCF service throttling in place but increasing the settings didn’t improve the situation. To simplify our testing, we eliminated the MSE server and went directly to the WCF Service hosted in IIS and still observed limited throughput. To resolve this, we added the following configuration to the aspnet.config file.

<system.web>
<applicationPool maxConcurrentRequestsPerCPU="5000" maxConcurrentThreadsPerCPU="0" requestQueueLimit="5000" />
</system.web>

As a result, we saw the throughput on the target IIS Server increase to more than 4x what our baseline throughput was, achieving ~240 requests/second. Support for these settings in the aspnet.config file was added in .NET Framework 3.5 SP1. The values we used for these settings are the default values for .NET Framework 4.0. Further information on these settings are documented here and here.

The location of the aspnet.config file can be found here:

32-bit: %WinDir%\Microsoft.NET\Framework\v2.0.50727\aspnet.config
64-bit: %WinDir%\Microsoft.NET\Framework64\v2.0.50727\aspnet.config

Adjustment on the MSE machine

Satisfied that we opened up the throughput to the target WCF service hosted in IIS, we re-introduced the MSE Server in the test cases and immediately saw end-to-end throughput go back down to close what our original baseline numbers were. A dump of the MSE process further revealed that there were several threads doing this:

Child-SP RetAddr Call Site
000000004b1cb2a0 000007fef80ce018 System_ni!System.Net.AutoWebProxyScriptEngine.EnterLock
000000004b1cb2f0 000007fef80cc526 System_ni!System.Net.AutoWebProxyScriptEngine.GetProxies
000000004b1cb390 000007fef81228e7 System_ni!System.Net.WebProxy.GetProxiesAuto
000000004b1cb3f0 000007fef81226a4 System_ni!System.Net.ProxyScriptChain.GetNextProxy
000000004b1cb440 000007fef7c15342 System_ni!System.Net.ProxyChain+ProxyEnumerator.MoveNext
000000004b1cb4a0 000007fef7c1516d System_ni!System.Net.ServicePointManager.FindServicePoint
… stack truncated for brevity

The HTTP bindings in WCF, such as basicHttpBinding and wsHttpBinding, use the system wide proxy settings by default. This was obviously restricting throughput in our scenario since so many threads were doing the same thing – which was, trying to acquire a proxy. Checking the LAN settings revealed that the “Automatically detect settings” option was checked (see below). Since our servers were all local, we unchecked this setting and re-ran the test and found that our throughput was back to ~ 240 requests/second. After making this change, the overhead that MSE added to the full end-to-end call was almost negligible.

Removing the “Automatically detect settings” option system-wide is probably not the best solution. There are other ways to achieve the same results. One is to create a binding configuration and set the UseDefaultWebProxy to false (see below). This setting is true by default. We tested this approach and got the same results as turning off the “Automatically detect settings” system wide setting. Therefore, our preference is to use this approach so as not to disrupt other applications that may be dependent on the system wide setting.

There are other properties in the binding configuration that can be used to improve performance when a proxy is involved, such as the ProxyAddress and BypassProxyOnLocal. These settings were not tested in our case. However, if you have a proxy to consider and you want your connections to local services to not use the proxy, then setting these properties should result in similar performance improvements.

Since resources, such as CPU, were still relatively low (less than 50% utilization) on our MSE and target servers, we wanted to see how much more we could handle. So, we increased the user load to 125 and saw no increase in overall throughput. We increased it to 150 and again, saw no gain. This pattern continued for up to 200 users. Basically, we were seeing the same ~240 requests/second but this time, we had twice the number of users (200). Why? What is unique about 100 users in this scenario was the coincidence that 100 was the number of outbound connections our MSE server was configured for (see below). As you can see, we essentially exhausted all available connections through this service point.

To resolve this, we increased the connection limit in our configuration to 200 as shown here.

After doing this and re-running the test, we observed an overall throughput of ~ 430 requests / second with CPU leveling at about 65%.

An important note here is that we did not see 2x the number of requests/second by doubling the user load. At 100 users, we were handling ~ 240 requests/second. At 200 users, we observed ~430 requests/second (a factor of ~1.8). We also saw the MSE’s overall CPU utilization increase. It is natural to see this trend however and the ratio will go lower with each increase. When making adjustments like this you should carefully measure your application to make sure you’re achieving the optimal throughput. Blindly increasing these values could have adverse effects if you’re not careful. More information about connection management can be found here.

The last optimization suggestion that was noted was to consider using the server version of the CLR GC. By default, the workstation version is used which is appropriate for single proc (sometimes up to dual proc) machines. Since the MSE was running on a multi-proc machine, some performance gains “could be realized” by switching to the server version. We didn’t test this. Nor did we see any concerns with memory pressure or CPU usage. This was just an observation.

Installing Windows Performance Toolkit (WPT)

2009-12-28T06:23:53Z

So, you want to install the Windows Performance Toolkit? This is located in the Windows SDK which you can download here. If you’re like me, you may not want to blindly install the entire SDK. The installer options that provide the WPT installers are the ‘Win32 Development Tools’ and/or ‘.NET Development Tools’ option under ‘Developer Tools’ (see below).

After you have completed the installation of the SDK, then you should find your WPT installers in <WindowsSdkDir>\Bin (see below). Simply install the one that matches your platform.

Self hosting an ADO.NET data service

2009-09-01T01:23:34Z

All the samples I’ve seen for ADO.NET Data Services show hosting the service in IIS. This is a natural choice, especially considering the rich hosting environment IIS provides and the tooling support provided by Visual Studio. However, it is not the only option for hosting ADO.NET Data Services. These services are just WCF services and therefore are capable of being hosted in any environment just like any other WCF service. In this post, I will show how you can host an ADO.NET Data Service in a Windows Service.

First, create the Windows Service project just like you normally would and add the service and process installers. If you’re not sure how to do this, follow the steps explained here. I named my Windows Service project ADOServiceHost.

In Solution Explorer, right-click the Windows Service project and select Add -> New Item. Add an ADO.NET Entity Data Model and follow the steps to generate the model from an existing database. I have the AdventureWorksLT database for SQL Server 2005 installed on my machine and I’m using that as the source for my model, which I named AWDataModel. You should now be able to explore the Entity Data Model by viewing the .edmx file that was created (see below).

In Solution Explorer, right-click the References folder in your Windows Service project and select Add Reference. Add references to the System.Data.Services.dll and the System.ServiceModel.Web.dll assemblies.

In Solution Explorer, right-click the Windows Service project and select Add –> New Item. Add a C# Class which will be the class that is your data service. I named mine AWDataService.cs. To make this an ADO.NET Data Service that exposes the Entity Data Model above, you have to derive from DataService<T> and you need to provide a static InitializeService method to specify things like entity access rules (see below).

The last piece of code needed is the code to host the AWDataService defined above. In your Windows Service project, open the code for the service that the Windows Service template created by right-clicking on Service1.cs and selecting View Code (see below).

At the top of this file you will need to add a using clause to bring in the System.Data.Services namespace. Then, you can new up an instance of DataServiceHost and open it in the OnStart method. Similarly, close the host in the OnStop method (see below).

Build the solution.

Open a Visual Studio.NET Command Prompt and navigate to the output folder for the Windows Service project. Using InstallUtil.exe, install the Windows Service (see below).

Next, start the service. You can do this from the service control panel services applet or from the command prompt. The name of your service will be the "Display Name” you assigned it when you added the service installer above. I named mine “AW .NET Data Service”. To start from a command prompt, just use the net start command (see below).

Now that the service is running, you should be able to start interacting with the resources from your model using your browser (see below).

ASP.NET Web Services to WCF services: Answering the question - Why?

2009-07-15T20:31:00Z

Windows Communication Foundation (WCF) is the platform for building distributed applications. Developers are usually eager to adopt the latest of any technology because, well, it’s the latest. There’s an element of coolness associated with building systems using the latest and greatest technology. Management, on the other hand, often takes a different look at technology to understand what the “value” is that a technology will bring to the bottom line.

So, in this post, I’m going to shine a light on why you would migrate to WCF from past technologies, such as ASP.NET Web Services.

Productivity

Developer productivity is something that translates directly to the bottom line and WCF nails this one on the head, especially with the Visual Studio 2008 release and even more with SP1 for Visual Studio 2008. Thanks to the WCF Service Host and WCF Test Client, you can literally have a service running and tested in seconds (I can do it in about 10 seconds). Of course, you have to make the service your own and add your business logic, but the tooling for WCF will give you a working service right out the box that is secure, interoperable, and provides better performance (see Performance below). You can create an ASP.NET Web Service and test it in the browser in about the same amount of time, but your ASP.NET Web Service won’t come close to matching the features you get right away from a WCF Service. I’ll cover many of these features in the sections to follow.

Security

In WCF, all the bindings (except basicHttpBinding) are secure by default. This means that messages are encrypted, signed, and transmitted between authenticated parties, to thwart message tampering and information disclosure threats. Secure message transfer is obtained through either transport security, message security, or combination of both. Auditing of security events such as authentication and authorization is built in and can be leveraged by simply applying an auditing behavior to your service. There is a wealth of security guidance and best practices for WCF that can be found here and here. In today’s hostile online world, more and more businesses are realizing the significant costs that can be incurred by insecure systems. Since WCF provides security by default it helps mitigate security risks and the associated costs.

Interoperability

Providing an implementation of the WS-* specifications was one of the key drivers for WCF since it’s first release in .NET Framework 3.0. In .NET Framework 3.5, this story got even better providing first class support for REST, Syndication, AJAX and providing data serialization to support things like JSON, POX, RSS, ATOM. With all of these options, WCF enables you to expand the reach of your service, opening the door to potential new business opportunities.

Performance

WCF offers better performance, about 25% – 50% faster than ASP.NET Web Services.

Features

WCF offers more hosting options unlike ASP.NET Web Services that require you host in IIS. WCF services can be hosted in IIS, IIS7/WAS on Windows Server 2008, Windows Services, WinForms or WPF (good choice if your service is part of a peer-to-peer application). Basically, any managed process can be a host for WCF Services.

WCF offers more transports than just HTTP. Out of the box you get bindings support for HTTP, TCP, Named Pipes and MSMQ.

Extensible Architecture

If for some reason WCF doesn’t offer something you need, then you can extend the architecture. For example, if you need support for a protocol that’s not already provided, then you can create your own and just add it. This UDP sample is an example.

The release of .NET Framework 3.5 (looking at it through a WCF lens) is validation of the extensibility of WCF. For example, in this release, programming WCF services for the web was the primary focus, allowing us to expose services through non-SOAP endpoints. Here we saw the introduction of things like the WebGetAttribute, WebInvokeAttribute and the WebHttpBehavior that are simply implementations of IOperationBehavior and IEndpointBehavior. These interfaces are basically extensibility points that have existed since WCF’s initial release in .NET Framework 3.0.

So, if for some reason you need to add new functionality that WCF doesn’t already provide, then you can rest assured that your ability to extend WCF to meet your needs is a real and supported path.

Integration

Leverage the investments made in previous technologies. Management never likes to hear that you have to re-write everything before you can start to realize the benefits of a newer technology. WCF offers a great integration story with respect to ASP.NET Web Services. It also offers tools and support for integration with existing COM+ applications and MSMQ applications.

More Effective Troubleshooting

Should you need to troubleshoot a WCF service, then you have a wealth of features and tools you can take advantage of. Message logging, tracing, performance counters, and WMI Support are available through simple configuration file changes and the Service Trace Viewer makes it very easy to interpret message logs and trace logs. In most cases, you can effectively troubleshoot issues without having to resort to more heavy-handed approaches that typically require debugging tools be installed into production environments.

Return On Investment (ROI)

The decision to adopt a new technology has to offer the business a return on the investment – otherwise, why do it. Hopefully by now, you’ve realized that the investment is relatively small with respect to WCF because it does so much for you. Management often wants to know that the decision to adopt a technology is one that will be backed by the vendor providing it. WCF is that technology moving forward. Technologies that preceded WCF (.NET Remoting, ASP.NET Web Services, Messaging, COM+) will continue to be supported. However, the investment being made moving forward will be in WCF.

WCF Instancing, Concurrency, and Throttling – Part 3

2009-06-26T22:06:00Z

In part 1 and 2, I talked about instancing and concurrency. In this post, the 3^rd and final post on this subject, I’m going to show an example of how you can use throttling to achieve optimal throughput for a service. But first…

What is throttling?

Throttling is a way for you to limit (“throttle”) the throughput of your service so that resources (memory, CPU, network, etc.) are kept at healthy levels. How you throttle a service will depend largely on the resources a particular machine has. For example, a service deployed to a machine with 1 processor, 2G RAM, and Fast Ethernet would be throttled less aggressively if deployed to a machine with 4 processors, 16G RAM, and Gigabit Ethernet.

How is throttling achieved?

In WCF, throttling is achieved by applying the ServiceThrottlingBehavior to the service. This service behavior provides 3 knobs (MaxConcurrentCalls, MaxConcurrentInstances, MaxConcurrentSessions) that can be dialed up/down. I’m going to assume you are already familiar with these. If not, then please review these links before proceeding.

For this topic of discussion, I’m going to use the same service I described in part 2, which simulated some long-running work by sleeping for 5 seconds. The service is PerCall/Multiple Concurrency and hosted in a console application with one endpoint using WsHttpBinding default settings. I’m also going to be using the load testing tools that are part of the Visual Studio Test Edition to see how my throttling adjustments impact the throughput of the service. My test harness is going to simulate 100 concurrent users using a constant load pattern for a period of 1 minute. Each simulated user will instantiate a proxy to the service and then proceed to call the service repeatedly using that proxy. In other words, I’m not incurring the overhead of recreating the client proxy and re-negotiating the security context for each and every call. I’m only incurring this overhead once for each of the 100 users.

Load Test 1

Throttle Settings

None. For this first test, I’m just going to see what results I get without applying any throttling behaviors.

Conclusion

Right away there are a few things that catch my eye.

1. Total Tests were only 106. Considering that I had 100 users, that’s not a very impressive number (about 1 test per user).

2. The average test time for the 60 second run was 32.4 seconds. Again, since my service should only take about 5 seconds to return a result, this too is unacceptable.

3. The average test time grew as the test progressed. At 55 seconds into the test, we measured 51.9 seconds as the average!

4. Finally, the processor wasn’t working very hard at all (less than 20% for most of the test).

If you don’t apply any throttling behavior to your service, then you essentially get WCF’s default throttling settings, which are

Considering these numbers, the results above begin to make some sense. First, look at the MaxConcurrentSessions setting. It defaults to 10. However, our test harness is simulating 100 concurrent users. Since our binding is a binding with session, we’re limited to just 10 concurrent users. Since each test takes about 5 seconds to run, a single user can only perform about 12 calls over a 60 second period. Multiply 12 (calls a user can make per 60 second period) by 10 (MaxConcurrentSessions) and you get 120 tests total. Now, you have to remember that WsHttpBinding is a secure binding so there is the initial overhead of establishing the security context. Plus, there is additional overhead beyond the 5 seconds we sleep during the service call. So, the number of calls a single user can make in a 60 second period is actually a little less than 12. As we see on this first run, it was about 10.6 calls over a 60 second period. So, our 106 Total Tests is the result of our 10 concurrent users running about 10.6 tests during the 60 second period.

So, for the next run, we need to increase the MaxConcurrentSessions.

Load Test 2

Throttle Settings

Conclusion

Some improvement.

1. Total tests increased from 106 to 164.

2. Average test time improved from 32.4 seconds to 26.9 seconds. Still, for a service call that should take just over 5 seconds, this is unacceptable. Our goal is to get this number as close as possible to 5 seconds.

3. The average test time is still growing.

4. The processor is still not working very hard. Interestingly though, our processor did level out nicely on this run as compared to the last run. This mainly has to do with the fact that the overhead of establishing the security context for all users was incurred at the beginning of the test, which is why you see the first recording of processor time being higher (about 75%) in this run.

What these results show is that we’re being limited by the number of concurrent calls (16) our service allows. Yes, we’re allowing 100 users at a time through the channel layer. However, only 16 users are getting their calls serviced because we’re limited to 16 concurrent calls. MaxConcurrentInstances does not apply in this case because for PerCall services, WCF will take the lower of MaxConcurrentCalls and MaxConcurrentInstances and use that number for both. So, doing the math of 16 users making approximately 10.x calls per 60 second period, our result of 164 total tests makes sense.

Since memory and processor are extremely low, I’ll bump these settings up to 100 each and rerun the test.

Load Test 3

Throttle Settings

Conclusion

Much better performance on this run.

1. Total tests increased from 164 to 571.

2. Average test time improved from 26.9 seconds to 9.92 seconds.

3. The average test time is now trending downward. In fact, the last recording at the 1 minute mark showed an average test time of 5.29 seconds.

4. The processor is doing much more. However, it stays well below 50% for most of the test.

I’m much more pleased with these results. We’re getting a lot more throughput with these settings. You have to look more at the numbers near the end of the test to realize this because of the overhead we’re experiencing of 100 users all hitting the service at exactly the same time. However, once things get going the indicators start to level off nicely. Or do they? Looking at the processor it looks like it is growing. I suspect it is because of the short duration of the test though. So, I reran the test again for a period of 2 minutes just to verify that it didn’t continue to grow. Here’s the results of that test run.

Suspicion verified - I’m satisfied with that! Not only does the processor level off nicely at about 50%, but as you should expect, my Average Test Time improved from 9.92 seconds to 6.77 seconds.

Final Thoughts

The purpose here was simply to show how you can influence the throughput of your service by making some simple throttling adjustments. Every service will be different though and the use cases for each application load test will be unique. So, don’t assume these settings would work the same for your service. Also, my test scenario was very basic – constant load and repeated synchronous calls from the client. It might be more realistic to have a step up pattern whereby the number of users increased gradually up to 100. It might also be more likely to have some think times in between each call to the service. I also ran all this on one machine which is not typically representative of a production environment. The point is, when you are trying to determine your throughput, you need to consider a specific use case and then configure your test settings accordingly.

The last thing I want to mention is that my test harness did not simulate a multi-threaded client. Yet, my service is capable of multiple concurrency. If I were to change the test to simulate a multi-threaded client where the client makes 2 concurrent calls on different threads, what throttling settings would you need to adjust? The answer is MaxConcurrentCalls and MaxConcurrentInstances. You would need to increase these to 200 to allow all 100 users to make 2 concurrent calls. Of course, you would also want to test this to see if you get the results you expect and that your processor load stays healthy. If not, you can “throttle” these back a bit until you reach the numbers you want.

WCF Instancing, Concurrency, and Throttling – Part 2

2009-06-17T17:19:46Z

From a developers perspective, code is either thread-safe or it is not. WCF will assume your service is not thread-safe unless you tell it otherwise by applying the ConcurrencyMode behavior. Your options for concurrency are Single (default), Multiple, and Reentrant. Depending on your implementation details for achieving thread-safety, you can really open up the throughput of your service by setting the ConcurrencyMode to Multiple or Reentrant.

The options for concurrency are, for the most part, self explanatory. So, please follow the links above if this is a concept new to you. In this post, I’m going to discuss a couple of specific scenarios; Reentrant Services and PerCall/Multi-Threaded Services

Reentrant Services

Making your service reentrant constrains the runtime to allow only one thread of execution on your service at any point in time (that is, it is still single-threaded). However, if your service operation makes an outbound WCF call then the lock on the instance context will be released, allowing another message to be dispatched to your service while the outbound call occurs. When the outbound call completes (returns back to your service), its thread will block until it can re-acquire the lock on the instance context.

The conditions for which reentrant concurrency applies are

1. your service is single-threaded, and

2. your service makes calls to other WCF services downstream OR your service calls back to the client through a callback contract.

If either of these conditions don’t apply to your service, then you would not gain anything by making your service reentrant.

PerCall / Multi-Threaded Services (over a binding with session)

For PerCall services, every message results in a new instance of your service, so generally there is not a concurrency issue unless you are accessing a shared resource between instances. However, there is a scenario where setting ConcurrencyMode to Multiple on a PerCall service can increase throughput to your service if the following conditions apply:

1. The client is multi-threaded and is making calls to your service from multiple threads using the same proxy.

2. The binding between the client and the service is a binding that has session (for example, netTcpBinding, wsHttpBinding w/Reliable Session, netNamedPipeBinding, etc.).

If these conditions apply and all you do is set your InstanceContextMode to PerCall, leaving the ConcurrencyMode to its default value (Single), then your multi-threaded client will not get the expected performance benefit of making concurrent calls to your service because there is a lock on the session in the channel layer. To illustrate, consider the following service code. This service just simply returns back some data from the service side to the client. One piece of data to notice is the MsgReceivedTimeStamp, which will indicate when the service instance actually receives the message.

Next, assume we have a client application that caches a proxy to be used by multiple threads. If this client were to call the service simultaneously on 3 different threads using a BackgroundWorker, then the total response time would be about 15 seconds (5 seconds for each call). Output from such an application might look like this.

Clearly, this is not the behavior a client-side developer would expect. The results here are not any different than if we were to make 3 calls to the service sequentially. What we would like to see is all 3 threads dispatched at the same time such that the total response time is about 5 seconds (not 15 seconds). To achieve this, we can set the ConcurrencyMode to Multiple as shown here.

Running the client against the new service will yield the results we’re looking for. That is, all 3 calls were dispatched to the service at roughly the same time and we still have a unique InstanceContext (or service instance) for each message as shown here.

Writing thread-safe code and applying the correct ConcurrencyMode can result in significantly improved throughput for your service. In the next post, I’ll talk about how and why you can throttle your service.

WCF Instancing, Concurrency, and Throttling – Part 1

2009-06-16T00:30:12Z

Building distributed systems using WCF has so many advantages. One of the things I hear consistently from customers is that it allows them to focus their development efforts on writing business logic code and less on having to write “plumbing” code. Still, writing effective services requires that we think about things like service level agreements (SLA) and from a developer’s perspective this often raises questions like…

Under what circumstances should instances of the service be created?

How long should a particular instance exist?

What level of concurrency (single-threaded or multi-threaded) needs to be supported?

What are the scalability requirements for the service?

Does the service need to manage state between calls?

Building services that address these questions are only part of the solution. Informing WCF how our service should be hosted to leverage these implementation details is another. For example, if we’ve built our service such that the operations are multi-threaded, then we will want WCF to host our service differently than if it were a single-threaded service. WCF provides behaviors that we can apply declaratively in our code to customize how our service is hosted. These are InstanceContextMode and ConcurrencyMode and both are applied via the ServiceBehaviorAttribute.

InstanceContextMode determines when an instance of your service is created and for how long it will exist. Your choices are PerCall, PerSession, or Single. A common question I hear often is: “Why would you ever want to use PerCall instancing and incur the overhead of creating a service for every message?” For which I usually reply: “What overhead?”. True, a new instance of your service class is recreated for every message. However, that equates to just creating an instance of a class. Unless your service class has some expensive initialization code in the constructor (for example, querying a database or building large object graphs in memory), the PerCall instancing model is very efficient. The overhead of building up the Channel layer (for example, listening on endpoints) and Service Model layer (for example, applying behaviors to customize the runtime) occurs one time for each ServiceHost instance. The following diagram illustrates this idea.

So, when would you choose one instancing mode over another? That depends on the requirements for your service. However, here are some (not all) common things to consider.

PerCall

You may consider this instancing mode in these circumstances.

- If your service is stateless

- If your service has light-weight initialization code (or none at all).

- If your service is single threaded.

PerSession (default)

You may consider this instancing mode in these circumstances.

- If your service needs to maintain some state between calls from the same client.

- If your service has light-weight initialization code (or none at all). Even though you are only getting a new instance for each client proxy, you still want to be careful about having expensive initialization code in a constructor.

By default, WCF will use PerSession provided the client and service are communicating over a binding that supports session. Otherwise, the service will behave as a PerCall service. Which raises the question: How can a developer place a constraint on the service such that the service’s endpoints support sessions? The answer is in the ServiceContractAttribute.SessionMode property that can be applied to your service contract. Using this property you can “require” sessions for your service. If any endpoints configured for your service don’t support session then the service will fail to start. This is your way, as a developer, to place a constraint on the administrator, to configure your service with endpoints that support your requirements (sessions in this case). Be advised that there are 4 different types of sessions in WCF and setting this property requires only that the binding support one of these types of session. It does not let you define the type of session you require.

Single

You may consider this instancing mode in these circumstances.

- If your service needs to maintain some state between clients.

- Your service has expensive initialization code. That is, initializing for every client (PerSession) or every call (PerCall) would be too costly.

- You don’t anticipate needing to scale out your service.

If your service will be deployed in a server farm, then be sure to review the WCF Load Balancing guidance for scenarios that may apply to your service.

In the next posting, I will say a few things about Concurrency.

Making asynchronous service calls from a WinForm client

2009-03-18T19:35:00Z

It’s well known that long blocking calls in the main user interface (UI) thread of a WinForm client application should be avoided. As users, we certainly get annoyed when the application stops responding. Yet, even today, we see this over-and-over again in so many applications. When making a call to a service the amount of time the call takes to complete can be unpredictable. Even if your service responds immediately, you have the potential for network latency, authentication hand-shaking, etc. to extend the time for a complete end-to-end call. Calling services in an asynchronous fashion solves this problem. In this post I’m going to show an easy way to make an asynchronous call to a service and how to use some user interface (UI) best practices for handling the result of such a call.

I’m going to start with just an out-of-the-box WCF service using the WCF Service Library template and make one small change (sleep for 5 seconds) in the GetData method to simulate a long running call.

Next, I’ll create a very basic WinForm client project. The UI for this client will allow me to select data to send to the GetData method and will show the results in the ListBox control. There are two buttons that I will use to invoke the service; one for a synchronous call and another for an asynchronous call.

I also added a NotifyIcon control to my form which you don’t see. This is what I’m going to use to notify the user that the call has completed. It will display a notification in the Windows taskbar (much like the way Windows Update notifies you when updates are available for Windows).

Since I’m using the NotifyIcon, I’ll go ahead and add an icon as a resource to the WinForm client project. You can do this easily by double-clicking the Resources node in Solution Explorer.

This will open the Resource Designer where you can select to add a new icon from the toolbar.

The icon designer will appear and you can design your icon(s) as I’ve done here.

Once that is complete, simply set the Icon property in your NotifyIcon to the icon you created. You may also want to set the Balloon Tip Title like I’ve done here or you can set it at runtime later if you prefer.

When I add my service reference I’ll be using an “Advanced” option to generate asynchronous methods to call to the service. This feature is available if you click on the Advanced… button in the Add Service Reference dialog.

When you do this, you will be given the opportunity to have SvcUtil generate asynchronous operations for you as part of the client proxy. IMO, this option should be checked anyway and not tucked away behind an “Advanced” button, but that’s just me…

I’ll start by adding the code for the synchronous call to the service behind the “Call Service Synchronously” button.

When you run the client and press the button you will eventually (after about 5 seconds) see the results displayed in the ListBox control. If during this time you try to move the form or interact with other controls on the form you won’t be able to because the client UI will be blocked while the call completes.

A solution to this annoying situation is just to call the service asynchronously as shown here in the code behind the “Call Service Asynchronously” button. The work done by svcutil.exe when generating the proxy makes this a trivial task using the GetDataAsync method to call our service and the GetDataCompleted event handler to retrieve the results.

All that remains now is to use the NotifyIcon control to notify the user when the call has completed. If we didn’t encounter an error then I’m going to make the balloon tip icon an “information” icon and show the result in the text. I’ll also add it to the ListBox control on our main form. Otherwise, I’ll show an “error” icon and the error message returned.

Finally, I’m going to wire up the click event for the icon itself where I will stop showing the icon in the taskbar and bring focus to the main form. You may want to do the same for the BalloonTipClicked event, or associate a ContextMenu with the control and drive other behaviors from it. The possibilities are abundant for you to explore.

The last thing to do now is test it. I’m going to run my application, invoke the service asynchronously. In doing so, I will still be able to interact with the form, move it around on my desktop, etc. because the main UI thread is not blocked.

When the results are ready, I will get a nice notification in the taskbar like this and the data will be in my ListBox on my main form. After 10 seconds the balloon tip will go away but the icon will stay in the taskbar until I click on it. At which time, the main form will be activated and the notification icon disabled.

XmlSerializer Faults

2008-10-03T19:44:22Z

There's a new WCF feature in the .NET Framework 3.5 SP1 release that I just recently learned about. It has to do with serialization of SOAP faults when using the XmlSerializer for your service rather than the default DataContractSerializer.

Consider this scenario: You have elected to use the XmlSerializer for your service because of some rather complicated schema that the DataContractSerializer doesn't support. You also have some rather complicated schema used to define fault contracts in your service. Prior to SP1, WCF would serialize any faults you returned from your service using the DataContractSerializer rather than the XmlSerializer even though you applied the XmlSerializerFormatAttribute to your service, potentially breaking the serialization between your service and client(s).

In SP1, support for XmlSerializer Faults was added via the SupportFaults property. There is a link to a sample in the XmlSerializer Faults document. Unfortunately, at the time of this writing that sample does not appear to exist - I've searched! So, I'm going to expand on the topic here.

SupportFaults is a boolean property that simply says this:

If true, then WCF will use the XmlSerializer to serialize the fault.
If false, then WCF will use the DataContractSerializer to serialize the fault. This is the default.

As an example, consider the following service definition:

Our service is using the XmlSerializer because of the XmlSerializerFormat attribute that is present.

Our fault contract returns a typed SOAP fault, UnknownStockFault, to the client in the event that an unknown ticker symbol is passed in. In this definition are some XML serialization attributes (XmlAttribute and XmlIgnore) that the XmlSerializer understands.

When your service returns this fault, it will be serialized by the DataContractSerializer (not the XmlSerializr) like this:

When in fact, you were probably expecting this:

Notice that "Symbol" is an attribute of the <UnknownStockFault> element and that the "ErrorCode" is missing.

So, how do you achieve the latter? By using the new SupportFaults property. For example:

"Zermatt" Resources for Developers and Architects

2008-09-25T01:42:00Z

I am captivated by the work going on in the identity space and as a result have created a collection of resources that I particularly like. If you are interested in this space too and want to know where to go for information, consider these resources.

Base addresses and IIS/WAS hosted services

2008-08-23T09:37:54Z

If you have ever hosted a WCF service in IIS/WAS then you know that the .svc file for your service is the base address. For example, if you create a web site project called MyService using the WCF Service template, then your base address for that service will be http://localhost/MyService/Service.svc. That is why there is not a base address specified in the configuration for your service.

It is also why the default service endpoint (wsHttpBinding) you get from Visual Studio's WCF Service template leaves the address property empty. It is simply using the base address as the address for the endpoint.

Of course, any subsequent http endpoints you add will need a unique address relative to the base address in order for them to be reachable.

Now, what happens when you decide to add support for other non-http protocols (tcp for example) to your service hosted in IIS/WAS? Do you need to specify a base address, such as net.tcp://localhost/MyService/Service.svc in order to use relative addresses in any tcp endpoints you add? That is a question I debated with a good friend recently for which I took the position - yes, you would. After all, how else are your relative addresses going to resolve to reachable address if there is not a base address?

Well, it turns out I was wrong. You do not have to add the base address for tcp (or any other protocol for that matter) because IIS/WAS is adding it for you when you enable these protocols for your service. To verify this, I created a new Web Site project using the WCF Service template and added a method to return the BaseAddresses property from ServiceHost.

Then, I used the WCF Test Client to test my service and as expected, I found the http and https base addresses for my service.

Next, I opened IIS Manager and enabled some other non-http protocols.

Without adding any endpoints to my services, I then re-ran the WCF Test Client and to my surprise the base addresses for these other protocols were already there!

If I now add a tcp or pipe endpoint to my service, I can just enter a relative address for the endpoint because IIS/WAS has already provided the base address for these protocols.

Visual Studio 2008 Service Pack 1

2008-08-14T17:42:00Z

Now available here.

My installation took about 2 hours and 15 minutes to download and install. Make sure you set aside some time for updating your development machine.

In this post, I am going to talk about some (not all) of the features I particularly like with regard to Windows Communication Foundation (WCF). Refer to the MSDN documentation for more details about all the changes in this service pack. I've basically split this post into two categories:

Tooling Updates, where I describe features specific to tools. For example, the IDE, WCF Test Client, etc.
API changes, where I describe changes to classes, methods, properties, etc.

Tooling Updates

WCF Project Options

It is no longer necessary to manually edit your project file as described here to prevent the WCF Service Host from starting when you want to debug your service in a custom host application in the same solution. Now, you just pop over to your project settings, click on the WCF Options tab and uncheck the option to start the WCF Service Host.

WCF Test Client

The WCF Test Client has also picked up some very nice new features that I'll describe here.

Can stand up on its own

Previously, to start the WCF Test Client, you would press F5 and the IDE would take care of launching it (and the WCF Service Host) for you. Or, if you wanted to use the client to test against a service outside of your solution, you could do so as long as you passed in the base address (as a command line parameter) of a running service so that the WCF Test Client could get to the metadata.

Now, we can start the WCF Test Client without having to pass in the base address. When the WCF Test Client window opens, go to the File menu and select Add Service... to enter the metadata address for the service(s) you want to test against. There's even a nice list of previous services you have tested that you can access from the Recent Services menu option.

If you want to test multiple services from the same instance of the WCF Test Client, go right ahead. This new UI makes it really easy. You no longer have to open a separate instance of the WCF Test Client for each service.

Another nice addition is the ability to edit the client configuration file. Just right-click the Config File node in the tree view and select Edit with SvcConfigEditor.

From the Service Configuration Editor you can make your modifications as you normally would. When you are finished and you want to test those changes out, right-click on the service node in the tree view and select Refresh Service to test out your new configuration settings. Remember, these are client side configuration settings you're editing, not the service's configuration.

Can support MessageContracts

Yes, you can now test your services that expose [MessageContract]'s. This is not something I do much of but knowing that I don't have to write a test client in these situations is worthy of an applause.

Can support XmlSerializer

The WCF Test Client can now support services that use the XmlSerializer for serializing data.

Support for sessions

Suppose you have a service that requires sessions. Again, in the past you pretty much had to write your own client to test such a service if your service maintained state between calls. Now, the WCF Test Client maintains the same proxy internally when making calls to a service. That is, the first time you invoke the service from your client a proxy is created. The next time you invoke the service, that same proxy instance is used (ie: the same session). So, for example, if I have a service operation (lets just call it AddNumber) that adds a number (how about 2) to running total and I invoke that operation 5 times, I can expect the result to be 10 as shown here.

So, what if I want to create a new session? Very simple - just check the Start a new proxy checkbox and invoke the service. This will create new proxy internally and therefore a new instance of the service with the running total initialized to 0. After the call, the result will be 2 as shown here. To continue using the new session, uncheck the Start a new proxy checkbox.

In light of all these new capabilities, I've promoted the WCF Test Client to my Quick Launch window so I can quickly test a service (or services) without having to load up the IDE.

Publish WCF Service Wizard

There is a new wizard for WCF projects to facilitate publishing of WCF services. You can access this from the Build menu in Visual Studio 2008, or by right-clicking your WCF service library project and selecting Publish. This makes publishing ( to IIS for example ) extremely easy.

If you create a WCF Service Library project initially and later want to then publish that service to IIS, this option will setup the virtual directories in IIS for you and it will also create the .svc file you will need for that hosting environment.

API Changes

Plain Old CLR Objects (POCO)

This is a great new feature that eases the migration from ASP.NET Web Services to WCF. Aaron describes this nicely in DataContracts without attributes (POCO support) in .NET 3.5 SP1 so I won't explain it here. When I first heard of this it smelled non-SOA to me because you don't explicitly define your data. However, I have come to realize the value of this new feature when it comes to migrating existing ASP.NET Web Services to WCF. Otherwise, I prefer the explicitness of using [DataContract]'s to define your data.

System.ServiceModel.Web.UriTemplate

The UriTemplate class took on some changes, many of which are used by other parts of the framework. But, a couple of notables for us WCF folks are described here.

There is a new Defaults property now that enables you to define default values for parameters defined in the template string. This allows us to do things like this in our service cotracts:

If you access the service from your browser and omit the parameter in your URI, then your method will receive this default value.

Compound template segments were also added which allows you to do things like this:

From your browser, you would be able to invoke the operation using a URI like this.

http://localhost/myproducts/product(12)

Preventing the WCF Service Host from launching in Visual Studio 2008

2008-02-15T04:47:00Z

One of the great new features of Visual Studio 2008 is the new tools for WCF developers. No longer is it necessary to code up your own test host and test client applications to test your service. This functionality is provided for you automatically thanks to the WCF Service Host and WCF Test Client. This significantly improves developer productivity with regard to the development of the service. Unfortunately, if you’re going to be hosting your service in a custom host, such as a windows application or console application (probably for debugging purposes since these are generally not practical choices for hosting) then you will run into a little snag if you add that project to the same solution.

The snag you are going to run into is the WCF Service Host running at the same time as your custom host application when you press F5 to run your application. When your custom host application initializes the WCF stack, you will likely see an AddressAlreadyInUseException. This is happening because the WCF Service Host is already listening on the same address.

Unfortunately, there is not a switch in the Visual Studio environment that resolves this problem. So, you have to go to the project file for your service and make a small change, which I’ll describe here.

1. Right-click the WCF service project (not the custom host project) in Solution Explorer and select Open Folder in Windows Explorer.

2. In Windows Explorer, right-click the project file (.csproj) and select Open With | Notepad (if Notepad is not an option you may need to browse to it).

3. In Notepad, look for the <ProjectTypeGuids> element and delete it.

4. In Notepad select File | Save on the menu to save the change and then File | Exit to close Notepad.

5. Go back to your Visual Studio 2008 window. When you activate the window, you will see a dialog prompting you to reload the project file. Click the Reload button to reload the project file.

6. Press F5 to run your custom host application.

Visual C++ 6.0: How do I create symbols files (.pdb) for release builds?

2004-11-06T01:43:00Z

I seem to be getting asked this question alot lately.

In Visual C++ 6.0, symbol files are generated automatically for debug build configurations of your project. For release build configurations, they are not. Does this mean that you cannot generate symbol files for release builds? No, it is just not enabled by default. Here are the steps necessary to generate symbol files for release builds.

Open the Project Settings dialog for your project. Change the 'Settings For' drop down box to your 'Release' build configuration. Note: It is possible that you will have multiple 'Release' build configurations.

Next, click on the 'C/C++' tab and change the 'Debug info:' drop down box to 'Program Database'. For example,

Finally, click on the 'Link' tab and change the 'Category' drop down box to 'General'. Then, click the 'Generate debug info' checkbox.

When you build your project with this configuration you will have symbol files in the output folder.

ATL: What is the difference between the _ATL_DEBUG_REFCOUNT and _ATL_DEBUG_INTERFACES macros?

2004-10-15T01:07:00Z

I have just always used _ATL_DEBUG_INTERFACES and never really considered using _ATL_DEBUG_REFCOUNT. After investigating this further, this is what I found (referring to ATL v7.1):

From Atldef.h:

#ifdef _ATL_DEBUG_REFCOUNT
#ifndef _ATL_DEBUG_INTERFACES
#define _ATL_DEBUG_INTERFACES
#endif
#endif

So, if you use _ATL_DEBUG_REFCOUNT, it is going to automatically define _ATL_DEBUG_INTERFACES for you if you haven't done so already. This is the only reference to _ATL_DEBUG_REFCOUNT in the ATL source. So, to answer the question - there is no difference.

I suspect that prior to ATL v3.0, all the _ATL_DEBUG_INTERFACES that are sprinkled throughout the ATL code were previously _ATL_DEBUG_REFCOUNT references. Then when v3.0 came along, they changed the naming convention and called it _ATL_DEBUG_INTERFACES. So, it looks like _ATL_DEBUG_REFCOUNT is there simply for ‘backward compatibility’ to ATL v2.x.

Rick Rainey

Setup Identity and Access Tools for Visual Studio 2012

Which WCF Binding Is Best?

TestBinding

CompareBindings

Main

Sample Output

Using a Server Certificate to Protect Web.Config

Implement the Provider

Deploy the Provider

Create the Server Certificate

Encrypting the Web.Config

Monitoring Client-Outbound WCF Calls

Why scriptLocation may not work when pointing to a proxy script file in your application config file.

Optimizing Intermediary Services for throughput

Environment

Problem

Resolution

Adjustment on the target WCF Service machine

Adjustment on the MSE machine

Installing Windows Performance Toolkit (WPT)

Self hosting an ADO.NET data service

ASP.NET Web Services to WCF services: Answering the question - Why?

Productivity

Security

Interoperability

Performance

Features

Extensible Architecture

Integration

More Effective Troubleshooting

Return On Investment (ROI)

WCF Instancing, Concurrency, and Throttling – Part 3

Load Test 1

Throttle Settings

Conclusion

Load Test 2

Throttle Settings

Conclusion

Load Test 3

Conclusion

WCF Instancing, Concurrency, and Throttling – Part 2

Reentrant Services

PerCall / Multi-Threaded Services (over a binding with session)

WCF Instancing, Concurrency, and Throttling – Part 1

PerCall

PerSession (default)

Single

Making asynchronous service calls from a WinForm client

XmlSerializer Faults

"Zermatt" Resources for Developers and Architects

Downloads

Articles / publications / white papers

Videos

Books

Blogs

Wiki

Test Drive It!

Base addresses and IIS/WAS hosted services

Visual Studio 2008 Service Pack 1

Tooling Updates

WCF Project Options

WCF Test Client

Can stand up on its own

Can support MessageContracts

Can support XmlSerializer

Support for sessions

Publish WCF Service Wizard

API Changes

Plain Old CLR Objects (POCO)

System.ServiceModel.Web.UriTemplate

Preventing the WCF Service Host from launching in Visual Studio 2008

Visual C++ 6.0: How do I create symbols files (.pdb) for release builds?

ATL: What is the difference between the _ATL_DEBUG_REFCOUNT and _ATL_DEBUG_INTERFACES macros?