none
WPF client and WCf service

    Question

  • Dear all,

     

    I have devleopped a WCF service whcih collect data from SQL server database.

    Does a Windows WPF client application is capable to consume my webservice ?

     

    thnaks for help

    regards

    serge 

     

    Tuesday, October 16, 2007 8:44 AM

Answers

  •  

     Serge Calderara wrote:

    Do WPF Ui works different that WinForm UI in thread base?

     

    Yes, WPF actually enforces its single-threaded UI model.  That is, WPF will actually throw an exception if you attempt to access a UI element from a thread other than the UI thread.

     

    WinForms, on the other hand, would only issue a warning when running a debug build under the debugger.  A release build would allow the cross-thread access to occur at runtime.  Although that more permissive environment might seem like a good thing, it led to a whole class of bugs that turned out to be extremely hard to debug (as race conditions typically are).

     

    WPF adopts the stance that its better to prevent the problem entirely than to have to chase it down a year later when just the right race conditions exist on some customer's machine half way around the world.

    Tuesday, October 16, 2007 5:13 PM

All replies

  • Hope the following URL may help you

    http://www.codeproject.com/WCF/WCFWPFChat.asp
    Tuesday, October 16, 2007 8:52 AM
  • Hi,

     

     It's quite easy to integrate both a WCF service and a WPF user interface in the same application. The simplest way to achieve this would be to create an instance of System.ServiceModel.ServiceHost which would host your service, and start this instance from your WPF window's Load event.

    The only thing to be aware of is that the methods calls made from your web service will be made from a different thread than the UI one, so be careful and use Dispatcher if your web method calls change something in your UI.

     

    Luc

     

    Tuesday, October 16, 2007 9:01 AM
  • If its a fulltrust WPF app, then yes, the apps can communicate fine.  Just keep in mind the single-threaded UI model for WPF.  You must be careful that the thread handling the WCF communication correctly posts updates back to the UI thread using its Dispatcher.

     

    If its a partial trust WPF app (e.g., a typical xbap), then you will need to wait for the .NET 3.5 version of WCF and your service must support basic HTTP binding.  You cannot use most other WCF features in partial trust (duplex comm, hosting svcs, other ws protocols, non-HTTP transports).

     

    Tuesday, October 16, 2007 9:06 AM
  • Thanks all for your reply.

    Small correction. Why i mean by Web servcie is in fact WCf service access by http protocol or tcp.

    Actually my WCF service will be host either in a Windows service or WAS. I do not know yet which one is the best.

     

    So I guest that as long as my servcie is runing either from Win Services or WAS, I can have a library under my WPF project that will handle the call to the proxy right in a similar way as I am doing it from a WinFor app ?

     

    Now one thing I did not catch clearly is that I am made a test with a normal WinFor client app which call my WCF service and retrun to the client app a dataset bind to a Datagridview. Everything works fine.

     

    The WinFor UI is not single thread also ? if yes what it is capable then to return the result of the WCF service without using .Invoke ?

     

    Do WPF Ui works different that WinForm UI in thread base?

     

    thnaks for clarification

    Serge

     

     

    Tuesday, October 16, 2007 11:46 AM
  • Hi again,

     

     WPF applications are also single threads, like WinForms. If you know how to change thread with WinForms, you'll have no problem with System.Windows.Threading.Dispatcher.Invoke Smile

     

    Luc

    Tuesday, October 16, 2007 12:11 PM
  •  

     Serge Calderara wrote:

    Do WPF Ui works different that WinForm UI in thread base?

     

    Yes, WPF actually enforces its single-threaded UI model.  That is, WPF will actually throw an exception if you attempt to access a UI element from a thread other than the UI thread.

     

    WinForms, on the other hand, would only issue a warning when running a debug build under the debugger.  A release build would allow the cross-thread access to occur at runtime.  Although that more permissive environment might seem like a good thing, it led to a whole class of bugs that turned out to be extremely hard to debug (as race conditions typically are).

     

    WPF adopts the stance that its better to prevent the problem entirely than to have to chase it down a year later when just the right race conditions exist on some customer's machine half way around the world.

    Tuesday, October 16, 2007 5:13 PM