Service changes all the time, and sometimes, you have to move on an depreciate obsolete method/properties.

It would be great if we can generate/post-process the proxy so that we mark obsoleted proxy method/properties with the obsolete attribute. That can make the depreciation process easier.

When using diagnostic tracing all messages appear as XML in traces even if they are transmitted / receieved in non XML format, e.g. JSON. I believe being able to log the actual bytes sent and received from the diagnostic traces and programmatically from a logging extensibility point would be a good improvement.

We use WCF 4.0 / WIF 3.5 WSTrust1.3. This works great with .NET clients. It is is a beast to get working with Java. The perception is that .NET WCF services are not interoperable with Java. Java samples /HOWTOS would go along way to squash this idea.

I am not sure if this has already been enabled (as far as I know it has not). The active federation bindings - WS-Trust do not show up in the Svc Config tool. These can be complicated to setup and it would be easier with config tool options for this.

To reduce the data that is received by the client it would be great that DataServiceContext supports the json format as described by the OData protocol description: http://www.odata.org/developers/protocols/json-format

We don't have a tool to support the new ETW feature of WCF yet. This tool should be super useful for developers and IT pros.

It would be nice in clustered scenarios if the WCF config could be stored in a common location (Database, MEX web service, shared file) and then initiated from the host via a constructor. Right now it's very difficult to actually dynamically change the configuration without either subclassing the objects and hacking the dynamic config in or having to write your own parser for the config when there are obviously classes that do this already in the current system.

For security (or other) reasons - a service may expose multiple endpoints with different contracts. These different contracts may share the same data contract types.

Currently, ASR/svcutil insist on generating types on different namespaces, make it impossible for one to get an object from one endpoint and pass it to the another

This is simple a hassle with the tools, WCF supports that when you copy the contract types manually.

When I'm writing REST services I don't want to have ASP.NET around. I'd like to use a single service-oriented framework (WCF) to create both REST and SOAP services. The advantages of using a single service-oriented framework outweigh funky/shiny things of ASP.NET web api which I will never use. ASP.NET web api has moved away from service orientation concepts (unfortunately), but WCF should still be capable of supporting REST services.

Current XML validation doesn't follow the Xml Schema standard and it's not possible to validate incoming messages against a schema. .Net framework really needs a proper Xml schema validator which can validate xml messages and also compare two schema versions to check breaking changes.

I know this is possible in web api, but this would enable WCF to become a very decent framework for REST services - for those people who do REST services with WCF (for many good reasons) .

When defining next OperationContract for a non generic ServiceContract

[OperationContract]
[ServiceKnownType(typeof(int))]
[ServiceKnownType(typeof(bool))]
[ServiceKnownType(typeof(string))]
void CreateAlarm<T>(string Client, string id, T exptValue);

.NET should generate and expose 3 overloaded methods.
The implementation however should only be done once.

Provide ability to apply fault contracts on service level instead of single operation level. This way we won't have to repeat fault contracts on each contract operation.

Implement standard based binary encoding for xml to enable much smaller wire size.