here is my question: Is there any tool to generate one service client proxy when the service is Rest/Json? the service is WCF, and one of the clients is WPF and i need this in order to create the tests with similar code than I test the classic Soap WCF services.
If not What is the best way to achieve this?
Thanks in advance
No, there isn't simply because there is no metadata with RESTful protocols such as you get the WSDL from SOAP.
If the service is WCF, you can use the svcutil.exe util to create a client even if you're using JSON or REST as the binding.
This thread has information on it:
Client configuration to consume WCF JSON web service
Related
I would like to know if any of you knows how to consume wcf services from MVC 4 web API.
I know it might sound crazy but I have to have them both in the same solution, that's why I need to know if anyone here can provide me with some tutorial or some more detailed explanation.
Thanks in advance.
generate your proxy class using your wcf service contract
call the proxy class from your web api to access the wcf service.
or make use of Castle Windsor WCF facility and let it create the client on the fly for you.
http://docs.castleproject.org/Default.aspx?Page=WCF-Integration-Facility&NS=Windsor&AspxAutoDetectCookieSupport=1
We have a problem in integrating a wcf service in a web service firewall.
Because the wsdl of the service does not contain the operations for ws-trust (requestsecuritytoken, ..).
How can I force WCF to include all details in its wsdl?
Or do I have to construct the wsdl myself?
Details:
Binding: WSFederationHttpBinding
MessageVersion: Soap12
Maybe it's because WCF produces multiple files by default and that is not always supported by things other than WCF clients.
Try this blog post about making WCF producing single wsdl. Maybe it will help.
I want to create a create a WCF Service which is invoked on the button click of MS Access Form.
You CAN consume WCF services through MS Access, but not via standard WCF mechanisms. You'll need to consume the service via GET requests, POST requests, or SOAP requests.
One way to accomplish this for SOAP requests on the Access side is using the SOAP toolkit:
http://msdn.microsoft.com/en-us/library/aa140260%28office.10%29.aspx
Another way that would work for GET, POST or SOAP requests is using XMLHTTP (if you go the SOAP route, you'll need to make your own SOAP envelope in the XML):
http://www.codemaker.co.uk/it/tips/ado_conn.htm (search for XMLHTTP)
On the WCF side you have a couple of choices:
Host a WebHttpBinding service. This gives you options to expose GET and POST endpoints for your services. See http://www.windowsitpro.com/article/net-framework2/exposing-classic-http-endpoints-with-wcf-in-net-3-5.aspx.
Host a BasicHttpBinding service that exposes a SOAP endpoint (this is the default WCF endpoint if you create a new service in Visual Studio). If you go this route, you probably want to set it to use legacy XML serialization and WSDL for compatibility if you go with option 1 on the access end (see http://msdn.microsoft.com/en-us/library/system.servicemodel.xmlserializerformatattribute.aspx).
One other thing to note: If you create a BasicHttpBinding WCF Service with XmlSerializerFormatAttribute, you are basically getting (from a data exchange standpoint) the same thing as if you were to write a legacy asmx service.
You cannot consume a WCF directly with MS Access.
If you own the WCF service, you would have to change it to a web service using HTTP bindings.
If you don't own it, you will have to write your own web service that is basically a wrapper around the WCF.
Then you can consume it as a web service in MS Access.
I have a WCF RESTful service using the WebHttpBinding and I want to know if I can use this in Silverlight 3 without any modifications?
You can make HTTP requests from a Silverlight client, so therefore yes you can access a WCF Restful service using WebHttpBinding.
What part of making an HTTP request do you not know how to do?
I need to upgrade our web services to use WCF instead of ASMX. If the signatures of the web services stays the same, will existing clients that already call the ASMX service have to change anything on their end? Is there anyway to still use WCF but not force them to change anything?
Option 1 :
Using the current ASMX's WSDL, generate the client using svcutil.exe
Grab the generated interface and create a WCF service based on this interface
Output : One new WCF endpoint configured with basicHttpBinding. Clients need to update the URL at which they're sending the messages.
Option 2 :
Refactor your ASMX code. Move all the logic into a separate DLL.
Create a WCF service and use the logic in the refactored DLL.
Output : 2 endpoints, one for ASMX and another one for WCF
If you use the BasicHttpBinding for your new WCF service, and implement the same methods with the same message structure, existing callers should be able to call into this new WCF service without any change on their part.
There's also an AspNetCompatibilityRequirements attribute in order to get around some potential compatibility issue - see the MSDN documentation on it.
Marc