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).

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.

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.

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.

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.

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.

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.

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:

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.   

Downloads

Zermatt Developer Identity Framework

Articles / publications / white papers

Microsoft Code Name "Zermatt" white paper for developers

Digital Identity for .NET Applications: A Technology Overview

The Architecture Journal #16: Identity and Access

Videos

MSDN WebCast: Overview of Developer Identity Framework (Zermatt), 9/26/08

Vittorio Bertocci and Caleb Baker: Understanding CardSpace and the Complexities of Identity

Demystified Series: Active Directory Federation Services (AD FS) Part 1

Demystified Series: Active Directory Federation Services (AD FS) Part 2

Books

Understanding Windows CardSpace: An Introduction to the Concepts and Challenges of Digital Identities

Blogs

Kim Cameron's Identity Blog

• Laws of Identity

Vittorio Bertocci

Don Schmidt

Mike Jones

Wiki

Identity Metasystem

Test Drive It!

Microsoft Identity Lab

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.

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:

1. Tooling Updates, where I describe features specific to tools.  For example, the IDE, WCF Test Client, etc.
2. 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)

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.

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.

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.

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.