Home/ Questions/Q 376251
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-12T14:34:52+00:00

My team owns both the WCF service and the Silverlight 3.0 application that will

  • 0

My team owns both the WCF service and the Silverlight 3.0 application that will be consuming it.

We do not want to use svcutil to generate proxies as it adds complexity to the development process. We’ve been down that road before and we’re not doing it again.

I’ve successfully used the ChannelFactory on a WinForms app and I’d like to use it again on this project. The difficulty seems to be that Silverlight expects Begin… and End… methods on the WCF service itself. I can understand that Silverlight might want to make the call asynchronously on a worker thread, but why does my service contract have to change to support this?

I feel like I’m missing something important here, but it’s not obvious to me what it is.

Is it really necessary to change the service contract of a WCF service just so it can be consumed by a Silverlight app?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Well, you need the ‘Begin’ and ‘End’ methods on the interface so you have something to call.

    That said, the sync v async is a ‘local’ thing, you can have the server have sync contracts (for the implementation) and the clients have the equivalent async contracts (for Silverlight). This means two different interfaces (or two copies of the same interface that just differ in AsyncPattern=true, if you think of it that way). But basically it’s the same “contract” just projected into two different CLR interfaces to provide two different programming models for supply/consumption.

    (Does that ‘help’?)

    (See e.g.

    http://blogs.msdn.com/mjm/archive/2005/05/04/414793.aspx

    which starts with two CLR interfaces that describe the exact same contract, but offer two different programming models for that contract.)

    • 0