Pedram Rezaei's Ramblings : WCF

WebChannelFactory inside a WCF Service

pedramr — Sat, 19 Jul 2008 16:32:00 GMT

When using a WebChannelFactory inside a WCF service that already has an OperationContext, you may need to create a new context before being able to successfully callout using a channel created by the WebChannelFactory. (Notice the line in bold)

public class RelationService : IRelationService

{

public Relation[] GetRelations()

{

var factory = new WebChannelFactory<ICustomerService>(

new Uri("http://localhost/customerservice/customers.svc"));

var proxy = factory.CreateChannel();

using ((IDisposable)proxy)

using (new OperationContextScope((IContextChannel)proxy))

{

var customers = proxy.GetCustomers();

return customers.Select(c => new Relation(c.Name, c.Age)).ToArray();

}

In the above example, GetRelations() is a RESTful service operation calling into another RESTful service located at the Uri shown above.

Without using the new context, you may get an exception similar to the following:

ProtocolException: The remote server returned an unexpected response: (405) Method Not Allowed.

When investigating further, you may notice that WCF could be using an incorrect HTTP verb for communicating with the service that exposes the GetCustomers() operation.

As it happens, here is how ICustomerService service contract looks like:

[ServiceContract]

public interface ICustomerService

{

[OperationContract]

[WebGet(

UriTemplate = "/customers",

ResponseFormat = WebMessageFormat.Xml,

BodyStyle = WebMessageBodyStyle.Bare

)]

List<Customer> GetCustomers();

}

As you can see it is expecting the GET verb. Without creating a new context, WCF ends up using the POST verb which will eventually cause the above exception.

How to consume REST services with WCF

pedramr — Mon, 21 Apr 2008 19:55:00 GMT

As you are probably aware by now, Windows Communication Foundation (WCF) 3.5 introduced a new binding called WebHttpBinding to create and to consume REST based services. If you are new to the WCF Web Programming model then see here for more details.

There have been many articles and blogs on how to host a RESTful service. However there doesn’t seem to be much written work on how to consume these services so I thought to write a few lines on this topic.

The new WebHttpBinding is used to configure endpoints that are exposed through HTTP requests instead of SOAP messages. So you can simply call into a service by using a URI. The URI usually includes segments that are converted into parameters for the service operation.

So the client of a service of this type requires 2 abilities: (1) Send an HTTP request, (2) Parse the response. The default response message format supported out of the box with the WebHttpBinding is “Plain old XML” (POX). It also supports JSON and raw binary data using the WebMessageEncodingBindingElement.

One way of consuming these services is by manually creating a HTTP request. The following example is consuming the ListInteresting operation from Flickr:

WebRequest request = WebRequest.Create("http://api.flickr.com/services/rest/?method=flickr.interestingness.getList&api_key=*&extras=");

WebResponse ws = request.GetResponse();

XmlSerializer s = new XmlSerializer(typeof(PhotoCollection));

PhotoCollection photos = (PhotoCollection)s.Deserialize(ws.GetResponseStream());

The idea is simple:

- Do the HTTP request and include all the parameters as part of the URI

- Get the response that is in XML format

- Either parse it or deserialize it into an object

The above code works but it is not elegant: We are not using the unified programming model offered by WCF and the URL is hacked together using string concatenation. The response is also manually deserialized into an object. With WCF and the WebHttpBinding we can automate most of this.

The first step is to define our service contract:

[ServiceContract]

[XmlSerializerFormat]

public interface IFlickrApi

{

[OperationContract]

[WebGet(

BodyStyle = WebMessageBodyStyle.Bare,

ResponseFormat = WebMessageFormat.Xml,

UriTemplate = "?method=flickr.interestingness.getList&api_key={apiKey}&extras={extras}")]

PhotoCollection ListInteresting(string apiKey, string extras);

}

As you can see, I am specifically instructing WCF to use the XML Serializer Formatter for this. The next step is to set the client endpoint. I decided to do this inside the config file:

<system.serviceModel>

<endpoint address="http://api.flickr.com/services/rest"

binding="webHttpBinding"

behaviorConfiguration="flickr"

contract="FlickrApp.IFlickrApi"

name="FlickrREST" />

</client>

</behavior>

</endpointBehaviors>

</behaviors>

In order to be able to use the XML Serializer Formatter, I need XML Serializable types:

[XmlRoot("photos")]

public class PhotoCollection

{

[XmlAttribute("page")]

public int Page { get; set; }

...

[XmlElement("photo")]

public Photo[] Photos { get; set; }

}

public class Photo

{

[XmlAttribute("id")]

public string Id { get; set; }

[XmlAttribute("title")]

public string Title { get; set; }

...

}

The final step is to create an instance of the client proxy:

ChannelFactory<IFlickrApi> factory =

new ChannelFactory<IFlickrApi>("FlickrREST");

var proxy = factory.CreateChannel();

var response = proxy.ListInteresting("xxxx", "yyyy");

((IDisposable)proxy).Dispose();

If you don’t like using ChannelFactory directly then you can create your proxy by deriving from ClientBase<>:

public partial class FlickrClient :

ClientBase<IFlickrApi>, IFlickrApi

{

public FlickrClient()

{

}

public FlickrClient(string endpointConfigurationName) :

base(endpointConfigurationName)

{

}

public FlickrClient(

string endpointConfigurationName,

string remoteAddress) :

base(endpointConfigurationName, remoteAddress)

{

}

public FlickrClient(string endpointConfigurationName,

EndpointAddress remoteAddress) :

base(endpointConfigurationName, remoteAddress)

{

}

public FlickrClient(Binding binding,

EndpointAddress remoteAddress) :

base(binding, remoteAddress)

{

}

public PhotoCollection ListInteresting(string apiKey, string extras)

{

return base.Channel.ListInteresting(extras);

}

Now the client code will look similar to the following:

FlickrClient proxy = new FlickrClient();

var response = proxy.ListInteresting("xxxxxx","yyyyyy");

((IDisposable)proxy).Dispose();

Hope the above helps.

WCF error handling and some best practices

pedramr — Sat, 26 Jan 2008 02:25:00 GMT

I put together the following brief description of WCF Error Handling and some possible best practices for a customer. You may also find it useful:

There are 4 sets of errors that clients can expect:

Invalid configuration: when bindings, behaviors or any other configs are in conflict with some other settings.

Communication errors: These are the usual errors caused as the result of network communication issues such as incorrect or unreachable addresses and the unavailability of a network connection. You may receive a CommunicationException as a result this.

Service faults: By default all service side exceptions are sent to the client as FaultException.

Proxy or channel state errors: These types of errors are raised when the channel or the proxy is not in a correct state to allow for communications. For example the proxy could be in the Faulted state and attempting to use that proxy will throw an exception.

Why Faults instead of Exceptions?

As you are aware, WCF mainly deals with SOAP Faults instead of Exception. Here is a blog entry I wrote highlighting some the reasons on why we use faults instead of exception.

In short, a SOAP Fault provides an adequate mapping between service exceptions and their equivalent on the client.

Should you throw a CLR exception or should you prefer a FaultException or its derivative FaultException<T>?

As mentioned above, all service side exceptions (non FaultException derived ones) are automatically converted to a FaultException. A FaultException in itself however does not provide much information regarding the problem. It is also not possible to distinguish between different types of exceptions at the client-end as all exceptions are automatically converted to a generic FaultException. Here is an example of a case that a simple System.Exception was thrown but the client received a FaultException with no more information:

An exception of type 'FaultException' was caught...

Message: The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the <serviceDebug> configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework 3.0 SDK documentation and inspect the server trace logs.

If a FaultException was used, some more information regarding the exception could have been sent to the client in a form of a FaultReason. In instances where an unhandled non-FaultException is thrown, one of the following may happen based on the instance management settings of your service:

For per-call services:

The service instance is disposed and the proxy throws a FaultException on the client side. All exceptions of this type will fault the channel so that the same proxy can no longer be uses. In fact, attempting to reuse or even dispose the proxy may throw the following:

An exception of type 'CommunicationObjectFaultedException' was caught...

Message: The communication object, System.ServiceModel.Channels.ServiceChannel, cannot be used for communication because it is in the Faulted state.

For sessionful services:

The session is terminated, the service instance is disposed and the channel will be in the faulted state, thus the proxy cannot be reused.

For singleton services:

The channel is faulted and the same proxy cannot be used. However the singleton instance will live on.

In all cases mentioned above, the channel moves to the Faulted state. This is however not the case when a FaultException or a FaultException<T> is used. Therefore it is strongly recommended to throw a FaultException or one of its derivatives.

FaultException or FaultException<T>?

A FaultException in itself does not allow the service to provide detailed information regarding the exception to the client. In fact an instance of a FaultReason is as much information as you can send to the client. A FaultReason allows for localised versions of a message to be sent to the client.

Also, using a FaultException, it would be hard to distinguish between different exceptions at the client-end. In scenarios that you need to distinguish between exceptions and/or provide more information regarding the error, you can use a FaultException<T>. The constructor for this class takes an instance of T. T needs to be a DataContract or at least a serializable type. The instance of T will provide more information regarding the Fault.

At this point it is worth mentioning that all FaultException<T> instances are automatically converted to the simpler FaultException type if no FaultContract matching the type T is defined for the operation in question. Therefore when using a FaultException<T>, it is advisable to use a FaultContract. Of course it is possible to have multiple FaultContracts defined for an operation.

Do you need a FaultContract?

The answer is NO but read on. When throwing a FaultException or one of its derivatives, if no FaultContracts are specified, they are all converted to a simple FaultException. Use FaultContracts however when you are using FaultException<T> and you need the detailed information provided by the instance of T or you need to be able to distinguish between different exception types.

BTW, FaultContracts are published as part of the metadata for the service. Therefore T will have a representation at the client-end. In an unlikely scenario that the representation of T on the client has been modified manually and no longer matched T on the service, an instance of FaultException is thrown by the client.

How about one-way operations?

It is not possible to specify a FaultContract for one-way operations.

For debugging and diagnostics only:

It is possible to enable exception details to be sent to the client. This can be done using the IncludeExceptionDetailInFaults property of the service behaviour. However the use of this option is only recommended for debugging or problem diagnosis scenarios.

An example of handling errors at the client:

try

{

proxy.SomeOperation();

}

catch (FaultException<MyFaultInfo> ex)

{

// only if a fault contract was specified

}

catch (FaultException ex)

{

// any other faults

}

catch (CommunicationException ex)

{

// any communication errors?

}

An interesting and useful WCF extensibility point for error handling:

WCF is a very extensible framework. You can explicitly control the behaviour of your application when an exception is thrown.

You can

- Decide to send a fault to the client or not,

- Replace an exception with a fault,

- Replace a fault with another fault,

- Perform logging,

- Perform other custom activities

In order to utilise this extensibility feature, you need to implement the IErrorHandler interface. You will then need to install your custom error handler by adding it to the ErrorHandlers property of the channel dispatchers for your service. It is possible to have more than one error handler and they are called in the order they are added to this collection.

IErrorHandler introduces two very interesting methods:

public interface IErrorHandler

{

bool HandleError(Exception error);

void ProvideFault(Exception error,

MessageVersion version, ref Message fault);

}

Implement ProvideFault to control the fault message that is sent to the client. This method is called regardless of the type of the exception thrown by an operation in your service. If no operation is performed here, WCF assumes its default behaviour and continues as if there were no custom error handlers in place.

Using the ProvideFault method, it is possible to provide a new fault. Here is an example:

public void ProvideFault(Exception error,

MessageVersion version, ref Message fault)

{

FaultException newEx = new FaultException();

MessageFault msgFault = newEx.CreateMessageFault();

fault = Message.CreateMessage(version, msgFault, newEx.Action);

}

One area that you could perhaps use this approach is when you want to create a central place for converting exceptions to faults before they are sent to the client (ensuring that the instance is not disposed and the channel is not moved to the Faulted state).

The IErrorHandler.HandleError method on the other hand is usually used to implement error-related behaviours such as error logging, system notifications, shutting down the application, and so on. This would be my recommended place to add logging capabilities.

Correction: IErrorHandler.HandleError can be called at multiple places inside the service, and depending on where the error is thrown, the HandleError method may or may not be called by the same thread as the operation. In other words, WCF does not make any guarantees on which thread the HandleError call may be processed.

Use of Exception Shielding and the Exception Handling Application Block:

One other recommended approach for dealing with service based exceptions is through the use of Exception Handling Application Block as part of the Enterprise application Library. In his blog, Guy Burstein describes how you can use EHAB with WCF.

Which option should you use?

It all depends on your requirements. Application blocks aim to incorporate commonly used best practices and provide a common approach for exception handling throughout your application. On the other hand, custom error handlers and fault contracts can also be very useful. For instance custom error handlers provide an excellent opportunity to automatically promote all exceptions to FaultExceptions and also to add logging capabilities to your application.

From Exceptions to Faults

pedramr — Sat, 12 Jan 2008 20:47:00 GMT

A question that I often get asked during workshops on WCF is “Why does WCF use Faults instead of .NET Exceptions?”

Exceptions expose a set of limitations and possible security risks:

- They are platform/technology specific: .NET exceptions may have no meaning on other platforms

- Exceptions can cause tight-coupling between clients and service.

o Clients need to understand exactly what exceptions can be thrown by each operation

- Flowing exceptions to clients may expose service implementation details

- Flowing exceptions to clients may expose private and personal information

- Exceptions and exception hierarchies are not easily represented using metadata

Therefore a map between exceptions on the service and their equivalent on the client is required. This is achieved using SOAP Faults.
It is worth mentioning that exceptions that reach WCF clients are represented as FaultException.

$0.02

WCF, WPF and Visual Studio 2008 in action – Student Canvas Sample

pedramr — Wed, 28 Nov 2007 01:27:00 GMT

As part of my job as an Application Development Consultant (ADC) at Microsoft, I usually deliver talks on new technologies for different audiences. I am giving a talk on WCF next week and decided to put together a user friendly demo showing some of the capabilities of WCF.

In this demo, both the service and the client applications are WPF WinApps. Most of the WPF work was done with the help of the new WPF designer in Visual Studio 2008 and some of the more challenging designs were done suing Expression Blend 2 September Preview.

The user interface of the application is based on the Animation Studio sample which is shipped with Microsoft Expression Blend.

Here is a brief description of the Student Canvas sample:

Students at the Contoso College are each given a drawing canvas at the start of their art session. Each student’s drawing can be viewed in real-time by the Art teacher.

The teacher’s canvas (dashboard) hosts a WCF service for receiving detailed information regarding the works of students. Each student, when online, registers with the service and sends drawing information automatically for each pen stroke. If the teacher is unavailable, messages are queued inside an MSMQ queue and are received by the teacher as soon as he becomes online (you do not need MSMQ installed to be able to run this sample).

Student Canvas

Teacher’s View

Here is a list of some of the concepts used in this sample:

WCF

- One-way data contracts

- WS HTTP Binding (ws2007HttpBinding)

- MSMQ Binding (netMsmqBinding)

- Extensible data contracts (implementation of IExtensibleDataObject)

- Required data members

- Affinity to a synchronization context (ServiceBehavior. UseSynchronizationContext)

- Per-call instance context mode

WPF

- Binding to an object data provider

- Different layout techniques

You can download the code from here.

By default the client and the service talk over WS HTTP binding. If you want to switch to netMsmqBinding follow the following simple steps:

- Make sure MSMQ is installed on your machine

- Modify TeacherDrawingService’s app.config file and set CreateQueue to “True”:
<add key="CreateQueue" value="True"/>

- Modify StudentDrawingCanvas’s app.config file and change ActiveEndpoint :
<add key="ActiveEndpoint" value="TeacherWsEndpoint"/>

P.S. As you can see I am graphically challenged!

WCF Authentication: Custom Username and Password Validator

pedramr — Fri, 05 Oct 2007 19:27:00 GMT

There are a number of authentication techniques supported by WCF. For instance Windows Authentication, X509 Certificates, Issued Tokens, and Username and Password are all mechanisms that can be used for authentication.

These client credential types are configured as part of the binding configuration for an endpoint. For example the config section below customises the netTcpBinding to use an X509 certificate:

</security>

</binding>

</netTcpBinding>

If you change the Client Credential Type to “UserName”, you can then pass username and passwords to the service and authenticate the client based on these credentials.

Sending unencrypted username and password over any communication framework is usually not advisable. Therefore, when you opt in for the UserName client credential type, WCF insists that your service must also reference a service certificate that contains a private key. The public key in this certificate is used to protect the confidentiality of the username and password sent to the service. The private key is then used by the service to obtain those encrypted credentials.

If a server certificate is not specified, at service start-up time, you will receive the following exception: “The service certificate is not provided. Specify a service certificate in ServiceCredentials.”

By default, when a user name and password is used for authentication, WCF uses Windows to validate the username and password. Having said that, WCF is one of the world’s most extensible communication frameworks and it should not surprise you if I say that you can take control of the username and password validation:

This first step is to create a “validator” by inheriting from the UserNamePasswordValidator class and override the Validate method (Add a reference to System.IdentityModel.dll first):

public class CustomUserNameValidator : UserNamePasswordValidator

{

public override void

Validate(string userName, string password)

{

// perform the validation logic

}

The next step is to configure the service to use this custom validator. As this is the local behavior of the service, you will need to specify the custom validator as part of your service behavior configuration:

<userNameAuthentication

userNamePasswordValidationMode="Custom"

customUserNamePasswordValidatorType=

"MyAssembly.CustomUserNameValidator, MyAssembly"/>

<serviceCertificate

findValue="localhost"

x509FindType="FindBySubjectName"

storeLocation="CurrentUser"

storeName="My" />

</serviceCredentials>

</behavior>

As you can see, there are two elements defined as part of the serviceCredentials section. The userNameAuthentication element specifies that a custom validator is used and the serviceCertificate element provides a reference to the X509 certificate used by the service to ensure the integrity of the client credentials. See here for information on how to create a temporary certificate for use during development.

Do not forget to set service’s behaviourConfiguration property to the name of the service behavior defined above:

Both client and service endpoints need to enable Username and Password authentication mode on their bindings:

</security>

</binding>

</netTcpBinding>

Our service is now fully configured. The final step is to provide the username and password to the client proxy which can then be encrypted and sent to the service. If you are using the ChannelFactory directly to create a proxy then use the code below to set the username and password programmatically:

ChannelFactory<ISimpleService> factory =

new ChannelFactory<ISimpleService>(endpointConfigurationName);

factory.Credentials.UserName.UserName = "Pedram";

factory.Credentials.UserName.Password = "Password01";

However, if SvcUtil or Visual Studio has generated a proxy for you, use the code below to set the username and password:

proxy.ClientCredentials.UserName.UserName = "Pedram";

proxy.ClientCredentials.UserName.Password = "Password01";

Please note that there is no way to set the username and password in config.

Depending on the type of service certificate, you may need to specify a DNS identity for your client endpoints. This is used when the client authenticates the service to ensure that it is talking to the expected service and not any other hoax service intercepting your calls to the genuine service. The exception below is an indication of this:

“Identity check failed for outgoing message. The expected DNS identity of the remote endpoint was 'X' but the remote endpoint provided DNS claim 'Y'. If this is a legitimate remote endpoint, you can fix the problem by explicitly specifying DNS identity 'Y' as the Identity property of EndpointAddress when creating channel proxy.”

You can modify the client endpoint to include an identity element such as the one below (see here for more information on service identity):

</identity>

You are now ready to test the service.

You can also download a sample application which tries this technique over netTcp and wsHttp bindings from here (built using Visual Sudio 2008 beta 2 and is compatible with .NET Framework 3.0). Follow the steps below before running the sample application:

- Create a certificate

- Modify the serviveCertificate elements defined in both client and service App.config files to reference your new certificate (you may decide to change the FindType as well)

- Specify a correct DNS identity value for the client endpoints

Let me know what you thought of this article...

References:

- Selecting a WCF Credential type

- Bypassing certificate validation

- Common WCF Security Scenarios

- Transport Security with Basic Authentication

- Service Identity and Authentication

- How To Use the ASP.NET Membership Provider

Customising WCF Proxy Generation in Visual Studio 2008

pedramr — Fri, 10 Aug 2007 12:03:00 GMT

I was asked today how easy it is to hook into the WCF client proxy generation process in Visual Studio 2008. The answer is “It is very easy”.

Visual Studio has this great extensibility point that allows third-parties to create “Custom Tools” for specific files. One of the properties that is accessible to you for files within a Visual Studio project is called “Custom Tool”. The value for this property implicitly maps to a class in an assembly registered with Visual Studio that performs custom code generation for that file. For instance if you have an XSD file, you can create a custom tool which allows you to generate .NET code for that XSD.

Client proxy generation also uses the same technique. When you add a new service reference to your project a hidden XML file (usually named Reference.svcmap and is known as ‘map’) is created under the service reference. In order to be able to see this file you need to select “Show All Files” in the Solution Explorer:

The content of this map file is very interesting. In fact, this is the input file which is passed to the code generation tool. Here is an example of this file:

<GenerateAsynchronousMethods>false</GenerateAsynchronousMethods>

<ImportXmlTypes>false</ImportXmlTypes>

<GenerateInternalTypes>false</GenerateInternalTypes>

<GenerateMessageContracts>false</GenerateMessageContracts>

</ClientOptions>

</MetadataSources>

</Metadata>

</Extensions>

</ReferenceGroup>

This file has some very interesting properties such as “GenerateAsynchronousMethods” which dictate to the code generator whether or not to generate asynchronous proxy methods on top of the usual synchronous methods. By changing this property you get the APM (asynchronous Programming Model) enabled for the generated proxy. This option is very similar to /async switch of the svcutil tool.

A custom tool is nothing more than a .NET class which implements the following 2 interfaces:

Microsoft.VisualStudio.Shell.Interop.IVsSingleFileGenerator
Microsoft.VisualStudio.OLE.Interop.IObjectWithSite

The IVsSingleFileGenerator interface has 2 methods which are very significant to the generation process:

1- DefaultExtensions(...): This method is called by Visual Studio and returns the extension of the file which is generated by the tool.

2- Generate(...): This method is given the content of the original file and is expected to generate the content of the output file. In the case of the “WCF Proxy Generator” the input file is the map and the output is the proxy code.

If you want to understand more about writing your own custom code generators then see this article http://blogs.conchango.com/pauloreichert/archive/2005/05/21/1459.aspx.

The custom tool for WCF proxy generation is called “WCF Proxy Generator”. The actual class that generates the proxy code is a.NET class with the public access modifier. This class is defined in Microsoft.VisualStudio.Editors.dll that can be found in the GAC. Let’s have a closer look at this class:

namespace Microsoft.VisualStudio.Editors.WCF

{

[Guid("69cf4e9e-c755-408a-b407-117cc3acabeb")]

public class WCFProxyGenerator :
                IVsSingleFileGenerator,
                IObjectWithSite,
                System.IServiceProvider

  {
    protected virtual void
        CallCodeGeneratorExtensions(CodeCompileUnit compileUnit)
    { ... }

As you can see this class implements both IVsSingleFileGenerator and IObjectWithSite interfaces. Inside its Generate method it creates a code tree which represents the code for the proxy file. The code tree is represented using CodeDom. Just before converting the CodeDom representation of the code tree into .NET code and returning that to the IDE it calls the virtual CallCodeGeneratorExtensions method passing a copy of the tree (represented by an instance of the CodeCompileUnit). Within that method the generator has the opportunity to modify the CodeDom used for generating the final proxy.

As mentioned, this is a protected virtual method therefore it is possible to inherit from this class and override this method. The overridden method is then called instead of the original method specified in WCFProxyGenerator. You can now modify the generated code using the argument which was passed to the method:

[GuidAttribute("69cf4e9e-c755-408a-b407-117cc3acabec")]

public class CustomWCFProxyGenerator : WCFProxyGenerator

{

static readonly CodeStatement s_assignmentStatement = ...;

protected override void CallCodeGeneratorExtensions(CodeCompileUnit compileUnit)

{

base.CallCodeGeneratorExtensions(compileUnit);

// find all classes that inherit from ClientBase (all proxies)

var proxies = FindAllProxyClasses(compileUnit);

// add impersonation code to their constructors

foreach (CodeTypeDeclaration proxy in proxies)

{

AddImpersonationCodeToConstructors(proxy);

}

protected virtual CodeTypeDeclarationCollection

FindAllProxyClasses(CodeCompileUnit compileUnit)

{

CodeTypeDeclarationCollection result = new CodeTypeDeclarationCollection();

// search for all the proxy class (the ones that inherits from ClientBase)

...

return result;

}

protected virtual void

AddImpersonationCodeToConstructors(CodeTypeDeclaration type)

{

foreach (CodeTypeMember member in type.Members)

{

CodeConstructor ctor = member as CodeConstructor;

if (ctor != null)

{

// we got a constructor

// add some comment to this constructor

ctor.Statements.Add(

new CodeCommentStatement(

"Added by custom WCF proxy generator"));

// add the impersonation code here

ctor.Statements.Add(s_assignmentStatement);

}

The CustomWCFProxyGenerator class inherits from the WCFProxyGenerator and overrides the CallCodeGeneratorExtensions. Within this method it finds all classes inside the CodeDom representation of the proxy that inherit from ClientBase<> (All proxies inherit from ClientBase<>). It then identifies their constructors and adds a comment statement and an assignment statement to those constructors. The following code listing highlights the added sections to the constructors of the generated proxy:

[System.Diagnostics.DebuggerStepThroughAttribute()]

[System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServiceModel", "3.0.0.0")]

public partial class Service1Client :

ClientBase<Client.ServiceReference.IService1>,

IService1

{

public Service1Client() {

// Added by custom WCF proxy generator

this.ChannelFactory.Credentials.Windows.AllowedImpersonationLevel =

System.Security.Principal.TokenImpersonationLevel.Delegation;

}

public Service1Client(string endpointConfigurationName) :

base(endpointConfigurationName) {

// Added by custom WCF proxy generator

this.ChannelFactory.Credentials.Windows.AllowedImpersonationLevel =

System.Security.Principal.TokenImpersonationLevel.Delegation;

}

So far I have shown you how to hook into the proxy generation process. In order to be able to use this custom generator you need to sign the custom code generator’s assembly, install it into GAC and register it with Visual Studio. The registration process is simple and is done using System Registry. You have probably noticed that the CustomWCFProxyGenerator class has a Guid attribute. This attribute has to be unique and is used for registration process with Visual Studio:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\9.0\CLSID\{69cf4e9e-c755-408a-b407-117cc3acabec}]
@="CustomWcfProxyGenerator.CustomWCFProxyGenerator"
"InprocServer32"="C:\\WINDOWS\\system32\\mscoree.dll"
"Class"="CustomWcfProxyGenerator.CustomWCFProxyGenerator"
"Assembly"="CustomWcfProxyGenerator, Version=1.0.0.0, Culture=neutral, PublicKeyToken=a47c4f0a05463cf9"
"ThreadingModel"="Both"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\9.0\Generators\{164B10B9-B200-11D0-8C61-00A0C91E29D5}\CustomWcfProxyGenerator]
@="Custom WCF Proxy Generator"
"CLSID"="{69cf4e9e-c755-408a-b407-117cc3acabec}"
"GeneratesDesignTimeSource"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\9.0\Generators\{E6FDF8B0-F3D1-11D4-8576-0002A516ECE8}\CustomWcfProxyGenerator]
@="Custom WCF Proxy Generator"
"CLSID"="{69cf4e9e-c755-408a-b407-117cc3acabec}"
"GeneratesDesignTimeSource"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\9.0\Generators\{FAE04EC1-301F-11d3-BF4B-00C04F79EFBC}\CustomWcfProxyGenerator]
@="Custom WCF Proxy Generator"
"CLSID"="{69cf4e9e-c755-408a-b407-117cc3acabec}"
"GeneratesDesignTimeSource"=dword:00000001

You can download the code for the custom proxy generator from here (This is written for Visual Studio 2008 Beta 2 – Orcas Beta 2).

How to use the sample:

- Compile the CustomWcfProxyGenerator project (Found under the Generator folder)

- Install the output into GAC

- Run the registry.reg file in order to register the custom control with Visual Studio 2008 Beta 2

- Close Visual Studio

- Open the WCFProxyTest project

- Select “Show All Files”

- Find References.svcmap file, right click and select “Run Custom Tool”

- Optionaly you can change the Custom Tool from “CustomWcfProxyGenerator” back to the original version “WCF Proxy Generator” and run the custom tool again. You will notice that a slightly different proxy file (“reference.cs”) is created.

Download sample code

WCF Tools

pedramr — Fri, 29 Dec 2006 15:00:00 GMT

WCF provides a number of tools that make it easier to create, deploy, and administer WCF applications.

Tool Name	Description
COM+ Service Model Configuration Tool (ComSvcConfig.exe)	This is a utility used to configure service model integration for COM+ applications. Using this tool you can expose an interface within your COM+ component as a WCF web service. Read more here
Configuration Editor (SvcConfigEditor.exe)	An excellent tool which allows you to create and modify configuration settings for WCF services using a graphical user interface.
ServiceModel Metadata Utility (svcutil.exe)	Generates service model code from metadata, and metadata from service model code. This tool is most often used to generate client-side proxies to WCF services. Client-side proxies expose the service to the client application.
ServiceModel Registration Tool (ServiceModelReg.exe)	Manages the registration of the WCF ServiceModel with IIS on a single computer. It can be used to register, unregister, and re-register WCF. This tool is similar to aspnet_regiis.exe utility used for configuring ASP .NET with IIS. Read more here
Service Trace Tool (SvcTraceViewer.exe)	Service Trace Viewer helps you analyze activity tracing (*.svclog) diagnostic traces that are generated by WCF listeners. Service Trace Viewer provides a way to easily merge, view, and filter trace messages so that you can diagnose, repair, and verify WCF service issues. WCF itself logs internal events to the Windows Event Log.
WS-AtomicTransaction Configuration Utility (wsatConfig.exe)	This utility is used to configure WS-AtomicTransaction network support. This utility can only configure the settings for a local machine. Use the MMC snap-in to configure both local and remote machines. Read more here