Brief History

WCF in Mono was originally developed as part of the "olive" module in svn, which is primarily a collection of early experimental development of .NET compatibility stack. Nowadays WCF is part of the core Mono. The WCF stack has been merged to mcs module and is no longer developed in olive.

WCF development was started in 2005 and has been suspended and resumed various times. These are the four major efforts over the years:

• Initial development by the time of Mono Summit 2006 in Boston. (Presentation (http://www.go-mono.com/meeting06/infocard-indigo.pdf))
• Google Sumemr of Code development for P2P binding development by Marcos Cobena Morian. Seealso: Mono Olive: Introducing Windows Communication Foundation notebook (http://www.youcannoteatbits.org/Files/Documents/Mono%20Olive%20Notebook%20-%2018-09-07.pdf)
• Development led by Mainsoft team. See Noam Lampert's blog (http://noamlampert.blogspot.com/search/label/Mono)
• Current phase, originally started as part of Moonlight 2.0 effort in 2009.

Recent tasks

• Bugfixes
  • Fix multiple channel acceptor (an issue in ASP.NET integration) and enable throttling. done.reopened; non-ASP.NET channels still fail.
  • Fix TCP binary protocol handling (MC-NMF). Seealso bug #567672.
  • Fix breakage on multiple endpoint configuration. Seealso bug #573795.
  • Examine verifier related issue. Seealso bug #571907. done.

• SL3 catchups
  • Fault contract and(done) better fault handling.
  • make basic authentication work at service side. done, except for ASP.NET password (not doable so far).
  • Fill InternalVisibleTo gap.

• New features
  • Implement "Add Service References" to MonoDevelop.
  • Diagnostics support, and service trace viewer if possible.
  • Implement System.ServiceModel.Discovery.dll. (low priority)

• Improvements
  • WSDL export and import improvements.done (to somewhat practical extent).
  • mex and policy support. (low priority)
  • Symmetric/AsymmetricSecurityBindingElement fixes, which involves xmldsig fixes, towards WS-Security support.
  • config support enhancements.
  • 4.0 default configuration support.
  • Net peer channel improvements. (niche)

Development Plans

It's getting old, and my hacking is rather based on the items listed above. I also have a tentative list of work items for 2010, .NET 4 and new stack here

WCF is huge, so I have split them into a couple of "profiles" that we will support. The development plan is based on the profiles. Actually only a few of them are done.

Profiles

Core profile

Silverlight2 runtime compatibility level.
deliverables: get WCF-dependent silverlight apps working.
status: done

Basic profile

Core stack + Silverlight2 SDK equivalents + corresponding server side stuff + net.tcp and P2P channels.
deliverables: get Duplex client ChatApplication (http://www.codeproject.com/KB/WCF/WCFWPFChat.aspx) working.
status: achieved, need to stabilize and add features.

Simple extension profile

3.0 IdentityModel and 3.5 REST stack. Actually 3.5 stack is already done in some major parts.
deliverables: get devdefined OAuth (http://code.google.com/p/devdefined-tools/wiki/OAuth) working. it involves non-OSS Microsoft.ServiceModel.Web.dll, so we need other component for the milestone.

Minimum WS-Security stack

System.ServiceModel.Security* stack as long as the simplest cardspace client needs.
deliverables: get one infocard client example working.

Extended WS-Security stack

up to complete the full security stack.
deliverables: (TBD)

Full 3.0 stack

every 3.0 things except unsupported stack.
deliverables: (TBD)

Components with no plan to support

• ComIntegration.

• WorkflowServices. we don't have WF.

• RIA Services. Basically there are Silverlight SDK assemblies that are to be embedded in the app, so we don't have to bother much.

This one also has no plan yet, but might change:

• Data stack: support for ADO.NET Data Services. We don't have entities, which is the primary target for this area.

Decoration factors

They do not consist of the profiles above, but might be implemented independently and randomly.

• configuration support: Silverlight does not support configuration stack. Neither do I love them. Some efforts are achieved for ASP.NET integration use.

• Silverlight PollingDuplex binding element.

• New WCF 4.0 stack: routing, discovery, announcements, default configurations (default endpoints, standard endpoints etc.), REST help page. Each of them are relatively small and we welcome contribution. For 4.0 stack, seealso this MSDN article (http://msdn.microsoft.com/en-us/library/ee354381.aspx).

• One-way binding and things that depends on it; reliable messaging and composite duplex. channel pool.

• Service description (WSDL) support. It matters only when you expose WSDL at run-time, or import WSDL into contract. Basic contract generation works through our svcutil, but not further to support complex ones.

• Support for Silverlight client is also done as part of WCF side.

• MSMQ stack: Msmq bindings and MsmqIntegration.

• Federation (I'm not sure what it is supposed to do.)

• many other additional BindingElements such as transaction, reliability.

API completion targets

Since it looks easier to fill everything in some assemblies except for System.ServiceModel, I might want to work on filling API including almost-in-no-use stuff, so that I can ignore some assemblies in later stages.

(For example I am mostly done with System.Xml namespace in System.Runtime.Serialization.dll. MTOM support is done just for that.)

Status

I marked some areas that especially welcome contributions as "contribute:" lines.

regarding the profiles

Silverlight runtime compatibility stack should be feature complete.

Now I am brushing up "Basic" profile things.

every core assemblies but System.ServiceModel.dll

• Only a few minor things in System.Xml namespace are left unimplemented.
• in System.Runtime.Serialization namespace, NetDataContractSerializer is not implemented. (contribute: NetDataContractSerializer.)
• System.Runtime.Serialization.Configuration: Nothing is implemented. (contribute: everything)
• System.IdentityModel.Claims: Should be mostly implemented, except for Windows-only stuff.
• System.IdentityModel.Policy: Implemented but not known to work. (contribute: write tests and/or find its usage somewhere.)
• System.IdentityModel.Selectors: Some token authenticators and providers are implemented.
• System.IdentityModel.Tokens: The basic framework should be usable for SecurityBindingElement.
• SAML implementation is incomplete, and not implemented as SecurityToken.
• System.IdentityModel.Selectors.dll: On Win32 it should work. The actual implementation is in Mono.IdentityModel.Selectors.dll which P/Invokes cardspaceapi.dll. On Linux and/or Mac, the entire UI must be implemented. (contribute: write card manager UI (in any form; Gtk#, WinForms or even CUI). It could be done as part of mono-tools (especially if it depends on Gtk#) or mcs/tools. There is Mono.IdentityModel.Selectors.dll that holds implementation for win32.)
• System.ServiceModel.Web.dll: only minor parts remain. (contribute: Support for WebContentFormat.Raw. Support for ArraySegment.)

non-core / new assemblies

4.0 System.ServiceModel.Routing.dll

Mostly implemented.

4.0 System.ServiceModel.Discovery.dll

Not implemented.

System.Data.Services.dll

It is not really implemented, but stubbed by Eric Maupin for NHibernate build. We don't have required Entity Framework stack.

contribute: everything. Might be better to start from Entity Framework.

System.ServiceModel.dll

Binding Elements

Bindings should be regarded as explained here too, as they are almost mere collection of binding elements.

Message encodings

All message encoding binding elements are implemented, except for some details. For example, ArraySegment support is not implemented. Message buffering is not always considered.

Transports

HTTP, TCP streaming and duplex are implemented. HTTPS is not, in some parts. NetPeer is in general implemented, but lacks some details. Named pipe code is written, but not really working yet. For others, it depends.

Everything else

are explained at corresponding sections (for example, no point of explaining TransactionFlowBoindingElement beyond Transaction section).

Communication objects

Client side would work better since they are actually used heavily in Moonlight.

Session support depends on transports (as .NET WCF does), and since only TCP duplex channel is implemented so far, some other requirements may not be filled. (In Moonlight 2.0 compatibility layer, there is no binding element that supports sessions.)

Core of IChannelFactory, IChannelListener and ChannelBase

Every basic parts should work: CommunicationObject, ChannelBase, ChannelManagerBase, ChannelFactoryBase, ChannelListenerBase, etc.

The same applies to service side at ServiceHost: ServiceHost(Base), ChannelDispatcher(Base), EndpointDispatcher and DispatchRuntime.

Though note that not *all* of the members are ready to work.

(All those derived types of channel factories and listeners depend on each layer.)

Service and contract description, and proxies

ContractDescription

All description types should be working, including typed messages.

Not all behaviors are supported.

WSDL support

It is almost left incomplete since the development early stage. Though WSDL consumption has been improved through Moonlight proxy effort.

IContextChannel (ChannelFactory and ClientBase)

Basic functionality in client factory should work, including duplex ones: ClientBase<T>, DuplexClientBase<T>, ChannelFactory<T>, DuplexChannelFactory<T>.

Security stack

Incomplete work. WS-Trust authenticator hash was not clear at the development a few years ago (This might have changed by Windows Open Protocols).

Not supported

• transactions
• composite duplex and one way binding
• reliable messaging (depends on one-way binding element)
• federation
• privacy notice (WSDL support is incomplete anyways)
• SSL stream
• logging

Old Milestones and status (for reference)

For older status of WCF, see WCFStatusOld.