svcutil with /r does not work for MessageContract

Hi,
I was trying to generate WCF proxy (Client) using svcutil.exe from Visual Studio 2008. I also need to use the /r parameter of the svcutil.exe so the generated proxy code will not include the objetcs from my other internal assemblies.
The command I use is something like:
svcutil.exe /async http://localhost:8080/MyService /r:"C:\My.dll" /tcv:Version35 /out:MyClient.cs

I saw that if my .NET MessageContract objects on My.dll still exists on my generated proxy, so I have to change these objects to DataContract objects and then the generated proxy was correct.

You also need to remember that if your internal objects (on My.dll) contain objects form other internal assembly, You have to include this dll also in your svcutil command. So you new command will look like:
svcutil.exe /async http://localhost:8080/MyService /r:"C:\My.dll" /r:"C:\MyOtherObjects.dll" /tcv:Version35 /out:MyClient.cs

Your,
Rotem

Increasing WCF Client Applications Performance

Some times your WCF client object are created on the Middle-Tier of the application.
This scenario leads for creating many WCF client objects quickly and, as a result, experience increased initialization requirements.

There are two main approaches to increasing the performance of middle-tier applications when calling services:
1. Cache the WCF client object and reuse it for subsequent calls where possible.
2. Create a ChannelFactory object and then use that object to create new WCF client channel objects for each call.

Issues to consider when using these approaches include:

- If the service is maintaining a client-specific state by using a session, then you cannot reuse the middle-tier WCF client with multiple-client tier requests because the service's state is tied to that of the middle-tier client.

- If the service must perform authentication on a per-client basis, you must create a new client for each incoming request on the middle tier instead of reusing the middle-tier WCF client (or WCF client channel object) because the client credentials of the middle tier cannot be modified after the WCF client (or ChannelFactory) has been created.

- While channels and clients created by the channels are thread-safe, they might not support writing more than one message to the wire concurrently. If you are sending large messages, particularly if streaming, the send operation might block waiting for another send to complete. This causes two sorts of problems: a lack of concurrency and the possibility of deadlock if the flow of control returns to the service reusing the channel (that is, the shared client calls a service whose code path results in a callback to the shared client). This is true regardless of the type of WCF client you reuse.

- You must handle faulted channels regardless of whether you share the channel. When channels are reused, however, a faulting channel can take down more than one pending request or send.

Link to MS article:
Middle-Tier Client Applications

Best Practices: How to Dispose WCF clients

Use of the using statement (Using in Visual Basic) is not recommended for Dispose WCF clients. This is because the end of the using statement can cause exceptions that can mask other exceptions you may need to know about.

using (CalculatorClient client = new CalculatorClient())
{
...
} // <-- this line might throw
Console.WriteLine("Hope this code wasn't important, because it might not happen.");

The correct way to do it is:
try
{
...
client.Close();
}
catch (CommunicationException e)
{
...
client.Abort();
}
catch (TimeoutException e)
{
...
client.Abort();
}
catch (Exception e)
{
...
client.Abort();
throw;
}