I'm developing a .NET 2.0 client application that needs to connect to a WCF service. I add a web reference to a basicHttpBinding WCF service that we've developed and VS creates the proxy class and the config paraphenalia which is fine. The problem is that I only want to use a small fraction of the methods that the WCF service implements and not carry around the extra implementations that the client app doesn't need.
I was thinking of creating a different basicHttpBinding endpoint and put the methods there. Is there a way for only one endpoint of a WCF service to be referenced by a .NET 2.0 project?
Regards,
Frank
When you add a web reference to a service, you always get all the service methods. It's the service (implementation) that defines the scope of what ends up in the WSDL.
The only option to limit the scope of the method your client generates would be to create a second WCF service on the backend, which only implements those few methods that you want in your client - just having a second endpoint won't really help.
Related
I'm only using a .net framework with it and I can add a pure c# project that contains the service reference - but I can't create a Service Client with this approach, it tells me it cannot find an endpoint with the proper values
(Contract, Endpoint name, both are identical to the endpoint I copied over to my web.config.)
Is there a specific procedure in which you can add a service reference when it comes to ASP .NET Core? or is it just like regular .NET Framework?
Thanks in advance.
There are multiple ways to access wcf service, If you have control over wcf service implementation side. you can change your service to restful wcf service. if you don't have access to that use seviceutil.exe to get proxy class and config file.
1. first copy code from proxy class.
2. second add class reference to your ASP.NET code behind.
Check how to use serviceutil.exe on google.
Also go to http://www.wcftutorial.net/ for more details.
I've this WCF service hosted in a Sharepoint 2010 web application. The WCF has been created using the following factory:
Factory="Microsoft.SharePoint.Client.Services.MultipleBaseAddressWebServiceHostFactory, Microsoft.SharePoint.Client.ServerRuntime, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
As you can see this is creating a REST-type service. Because we needed to consume it client-side via jQuery.
Now we also need to access it from a .NET project (WinForms). I've tried adding the Service Reference in VS but it doesn't find anything. I guess that's because it's not a SOAP service right?
So how can I consume it in C# .NET project without breaking the existing jQuery support?
Yes, Add Service Reference does not work for WCF REST services. You have a couple of options here:
Add another endpoint to your service, a SOAP-based one, so that you'll be able to use Add Service Reference on your client. I don't know exactly what the MultipleBaseAddressWebServiceHostFactory does, but you could look how it creates its endpoint(s) and recreate that in another factory - and then add the additional SOAP endpoint
Another alternative is to share the interface definition (the service contract plus any existing data contracts) between the service implementation and the .NET client. Having that interface you can use the WebChannelFactory<T> to create a proxy to the REST service (like you'd have one for a SOAP service).
I have two instances of VS2010 running on same machine.One VS instance has a WCF service with basicHttpBinding.
Now as i have read in books, for calling this WCF service with basicHttpBinding, i have to Add a Web reference to it rather than Service Reference.
I ran the project containing the WCF service and from other VS instance try to add a Web reference, this is the URL which i gacve(I got it from WCFClientHost )
http://localhost:8732/Design_Time_Addresses/WcfServiceLibraryBasicHttpBinding/Service1/mex
But i get Http 400 error everytime i try to add the WCF service.
Please let know what i am doing wrong.
You should keep two things apart:
Add Service Reference adds a service interface based on the .NET 3.0 and up WCF runtime. It supports all WCF bindings - including basicHttpBinding
Add Web Reference is the old-style, .NET 1.x/2.x method of adding a reference to an ASMX web service ("ASP.NET web service"). This technology is outdated, and has been fully replaced by WCF as of .NET 3.0. ASMX only ever supported what is more or less equivalent to basicHttpBinding.
The ASMX technology is outdated, and you should only ever use this if you really can't make WCF work (but in my 3 years of writing and consuming a plethora of web services, I have never seen such a case) - avoid this unless you absolutely can't make WCF work - for whatever weird reason that might be...
The link you gave to the CodeProject article has a entirely plain wrong statement that you need to use Add Web Reference for basicHttpBinding - that is just plain NOT TRUE.
Probably missing something very basic. I created a WCF 4.0 Rest Service. It works no problems when I'm hitting the url from a browser and I'm getting back what I want.
But now I want to use that service from a client mvc application (it will also be used by other non .net platforms which is why it's a rest service in the first place).
Problem is how do I get a service reference to it so I can start to use it in my c# code? With the new minimal WCF .net 4 config approach and no interface for the service contract, I don't know how to specify a mex endpoint. Ultimately I don't want a mex endpoint in production, just during development. I would love to be able to specify that all my services (around 10 in one application) have endpoints with one tiny piece of config that vs2010 .config transformations just rips out when I publish.
Stop. REST service doesn't use metadata. Metadata (Mex endpoint) are only for SOAP services because WSDL 1.1 (the only version supported by WCF) is able to describe only SOAP service. WADL or WSDL 2.0 is able to describe REST service but non of them is currently supported by WCF.
REST service is consumed by using WebRequest directly or by building ChannelFactory on top of shared contracts. Both methods are described here. Other method is to use HttpClient from REST Starter kit (former API). The problem with Starter kit is that it has never reached RTM (it was replaced by WCF 4). Instead of metadata endpoint WCF 4 REST service offers help page where all operation are described. When using WCF 4 REST template the help page should be already turned on - just add /help sufix to address of your service. Here is another article about building REST clients.
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