'System.ComponentModel.PropertyChangedEventHandler' cannot derive from special class 'System.MulticastDelegate'

Question

I'm developing a wcf service as recommended here. It solved my initial problem of namespace conflicts when developing the original .NET 2.0 web service, but I've come up to another problem.

The object that I'm trying to pass to the wcf service is used in the client to aggregate a bunch of information from the user and some of its fields are databound to ui controls (hence implementing PropertyChangedEventHandler). When I try to compile the proxy generated by svcutil in my client project, I get the error that titles this question.

Pulling all of the data out of this object and putting into into a class for sending (and then reconstructing the original type) would seem redundant - not to mention take a ridiculously long time.

Is there a workaround?

Answer 1

Can I check? Are you passing a delegate to a web service? That won't work... it* cannot be serialized. At best, ADO.NET Data Services (.NET 3.5SP1) can do something similar by translating an Expression into a query-string... but that is as close as you'll get. Other than that, you'll have to build a request object that encapsulates your intent with regular properties.

This applies to any of web-service, wcf service, tcp, etc.

*=a delegate is essentially a type-safe method handle (with an optional target (instance) reference); it can be expressed, for example, as xml

---

(edit)

From the comments - it might simply be that you haven't attributed your data-contracts; this means it has to infer the contract (and it often gets it wrong). For example:

[DataContract]
class Foo : IWhateverInterfaces {
    [DataMember]
    public string Bar {get;set;}

    [DataMember]
    public int Baz {get;set;}

    public float NotPartOfTheContract {get;set;}

    public event EventHandler AlsoNotPartOfTheContract;
}

When using [DataContract], only members marked [DataMember] are serialized - so the event should be ignored. This used to be the only way of doing WCF data-contracts, but MS tweaked it to infer contracts from fields... a mistake IMO, as it causes the problem you've just had...