I have to connect to the service provided by the third party client. The issue is to do that dynamically. When I generate proxy on a static way with Add web reference everything is OK. With usage of WsdlImporter and CodeDom I get some strange generated classes (for proxy client per instance).
Then I saw in case of Add Service Reference I got the same values as with WsdlImporter. My conclusion WsdlImporter is used by svcutil.exe.
Does someone knows what is here so different ?
Service is using SOAP1.1
They're just two different tools. svcutil.exe actually uses WsdlImporter under the covers (which is why the two outputs are the same). Add Web Reference uses the same classes as the tool wsdl.exe (I don't know which class they use internally, but you can use a tool such as ILSpy or reflector to see what wsdl.exe uses.
"Add Web Reference" is part of the legacy ASMX support, not part of WCF. Don't use it if you have a choice.
The solution of this problem is to use ServiceDescriptionImporter. This importer is working as wsdl.exe .
Additionally, XSD schemes have to be imported (also take care on nested schemas). Great sample for this is on the following :
http://forums.asp.net/post/1740748.aspx
Thank you all, it works now
Related
I'm having very strange issue with my WCF Service Proxy client generated by "svcutil.exe" . My WCF Service works very fine if I don't have a function that returns DataTable. As soon as I add a method that returns a DataTable the client generated by svcutil.exe is behaving very strangely. The Interface is no longer found and client is not able to call the service. But if I add as a Service Reference its working very smoothly. I know its not a good habit to use DataTable as a return type but I need to. I cannot use the Service Reference :-( Any idea why its behaving or what I'm missing!!!
Have a look at the DataTableSurrogate class. It is used by the SyncFramework for serialization and really easy to use.
MSDN DataTableSurrogate
You shouldn't really serialize datasets, instead you should use datamodels and keep anything to do with datasets, tables, readers etc on your backend & in the business layer.
But.. if you want to do so you need to add the following "include" in svcutil, which is causing your issue. (Tells to reuse the types defined in System.Data.dll and not generate them in the proxy)
/r:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Data.dll
I am building a set of WCF services that share common data contracts (or entities if you prefer). These are simple data transfer objects that are decorated with DataContract and DataMember attributes. I am explicitly specifying the name and namespace. In trying to follow the principles of IDesign's recommendation of averaging 12 members per service contract, I am breaking my service project into multiple services.
My data contracts are in a separate assembly that I can provide to our clients if they are using .Net. They can tell their service reference to reuse types in referenced assemblies. However, if they are not using .net and they use 2 services that both use the same entity then they will, I assume, get an ambiguous reference message. I can see this in Visual Studio if I don't reference the data contract dll.
My question is, is there anything I can do in my services, or they can do in a client app to get around having to qualify which proxy the data contract came from?
Nice article that describes how to solve this issue.
Sharing DataContracts between WCF Services
I also tend to keep all my Data Contracts in one assembly which is referenced by multiple services and numerous client apps, which works great but I've never tried consuming the service outside of .NET.
It might be helpful to know what technology they are using to consume the service other than .NET? What is throwing the ambigious reference message?
I happen to have multiple services that share objects on my end. I am not certain why you are having this problem. In my case, I am able to access the objects in this way. . . .
SERVICE1 client = new SERVICE1()
client.CommonLibrary.Address. . .
SERVICE2 client2 = new SERVICE2()
client2.CommonLibrary.Address . . . .
It depends on what tools they are using on the client side. For instance, with Axis2 for Java the wsdl2java tool can share types by using the -u switch.
how can I share proxy objects across multiple Axis2 web service clients?
From my understanding and working with WCF, either one of the data contract used by the client app would not matter as long as the fully qualified name is the same and has the same data members. Internally it just create the object dynamically and reassign those data member property using the public setter.
A better approach I think is to refactor your data contract so that you will put all the common across more than one service into one assembly and refer to them hence you will not have this ambiguious or conflict issues regardless how many services are used by the client app.
We generate our service proxies not through the Visual Studio assistant but by custom batch files calling slsvcutil.exe (as we use Silverlight). There you can specify a namespace mapping using the /n parameter like this:
"C:\Program Files (x86)\Microsoft SDKs\Silverlight\v5.0\tools\slsvcutil.exe "^
http://ServiceUrl/MyService.svc^
**/n:http://youruri.org/CustomerService/DataContracts,CLR.Namespace.CustomerService^**
/n:*,CLR.Namepsace.MyService^
/r:"%ProgramFilesFolder%\Reference Assemblies\Microsoft\Framework\Silverlight\v5.0\System.Windows.dll"^
/ct:System.Collections.ObjectModel.ObservableCollection`1^
/edb^
So all data contracts having the namespace http://youruri.org/CustomerService/DataContracts are generated to the clr namespace CLR.Namespace.CustomerService in the proxy file and so on. Given you have generated this proxy in advance in the same proxy assembly, you can cut this whole namespace out of your second file and everything works fine - we wrote a small tool for the last step. All other contract namespaces will be generated to the CLR.Namepsace.MyService namspace (see the asterisk meaning catch all)
The process is some hazzle to set up because you have to hand craft the batch files, but once this is done it works well.
I understand this is a basic topic but never done this before starting from wsdl.
I am being handed a wsdl file and a bunch of xsd with the types definitions. I don't have a clue if they were created from a WCF service (I guess so because of the split out format) but I do need to create a WCF service that implements the contract.
Question: How do I get the service contract interface?
I know about wsdl.exe and svcutil.exe - but not too familiar with what's what.
I guess after that all that's left is implementing the service contract.
Any help appreciated!
P.S. I had another question about this but I tried to put too much stuff in the same question - so let's keep it simple for now.
You have two choices:
Option 1: Use the svcutil.exe utility on the command line. It should be installed in your C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin directory (or something similar, depending on machine and OS you have)
Use svcutil -? for the list of all the many parameters. Basically, in its most simple form, use:
svcutil (name of your service).wsdl (name of your datafile).xsd
and that will create a corresponding (name of your service).cs C# file with the service and data contracts, and a sample config file.
The resulting *.cs file (or *.vb, if you want VB.NET) will contain the service contract (the methods, resulting from the WSDL) and the data contracts (the data portion, coming from the XSD) for your service.
Option 2: Use the "Add Service Reference" dialog in Visual Studio (on the "References" node in your Solution Explorer) and just enter the file name of your WSDL file:
This will create a service reference, which is basically the same as the output from the svcutil.exe utility - plus a few helper classes and files for Visual Studio.
Unfortunately, in both cases, the import will create a horribly overloaded config file which is probably one of the reasons lots of programmers think WCF is awfully complicated - it's really not, but these two import tools just do a horrendously bad job on creating the basic config for you.... don't let that scare you away!
If the Add Service Reference for the WSDL doesn't automatically convert all relevant and necessary XSD files, you might need to add those to your project, and then use something like XSD2Code to convert those to C# (or VB.NET) classes for you.
The wsdl.exe is the deprecated utility to convert a WSDL file into a ASMX (ASP.NET webservice) stub - don't use that anymore, use svcutil.exe or Visual Studio's Add Service Reference for WCF.
As for how to create a proper and minimal WCF config, check out the DotNet Rocks TV Show #122 with Miguel Castro entitled Extreme WCF. Miguel presents a great way to structure your WCF projects, and to create just as much config as is really needed (and thus can be understood a lot better than the generated mess by svcutil).
Just wondering under what circumstances would you prefer to generate a proxy from a WCF service when you can just invoke calls using the ChannelFactory?
This way you won't have to generate a proxy and worry about regenerating a proxy when the server is updated?
Thanks
There are 3 basic ways to create a WCF client:
Let Visual Studio generate your proxy. This auto generates code that connects to the service by reading the WSDL. If the service changes for any reason you have to regenerate it. The big advantage of this is that it is easy to set up - VS has a wizard and it's all automatic. The disadvantage is that you're relying on VS to do all the hard work for you, and so you lose control.
Use ChannelFactory with a known interface. This relies on you having local interfaces that describe the service (the service contract). The big advantage is that can manage change much more easily - you still have to recompile and fix changes, but now you're not regenerating code, you're referencing the new interfaces. Commonly this is used when you control both server and client as both can be much more easily mocked for unit testing. However the interfaces can be written for any service, even REST ones - take a look at this Twitter API.
Write your own proxy - this is fairly easy to do, especially for REST services, using the HttpClient or WebClient. This gives you the most fine grain control, but at the cost of lots of service API being in strings. For instance: var content = new HttpClient().Get("http://yoursite.com/resource/id").Content; - if the details of the API change you won't encounter an error until runtime.
Personally I've never liked option 1 - relying on the auto generated code is messy and loses too much control. Plus it often creates serialisation issues - I end up with two identical classes (one in the server code, one auto generated) which can be tided up but is a pain.
Option 2 should be perfect, but Channels are a little too limiting - for instance they completely lose the content of HTTP errors. That said having interfaces that describe the service is much easier to code with and maintain.
I use ChannelFactory along with MetadataResolver.Resolve method. Client configuration is a bother, so I get my ServiceEndpoint from the server.
When you use ChannelFactory(Of T), T is either the original contract that you can get from a reference in you project or a generated contract instance. In some projects, I generated the code from a Service Reference because I could not add a reference to the contract dll. You can even generate an asynch contract with the service reference and use that contract interface with ChannelFactory.
The main point of using ChannelFactory for me was to get rid of the WCF client config information. In the sample code below, you can see how to achieve a WCF client without config.
Dim fixedAddress = "net.tcp://server/service.svc/mex"
Dim availableBindings = MetadataResolver.Resolve(GetType(ContractAssembly.IContractName), New EndpointAddress(fixedAddress))
factoryService = New ChannelFactory(Of ContractAssembly.IContractName)(availableBindings(0))
accesService = factoryService.CreateChannel()
In my final project, the availableBindings are checked to use net.tcp or net.pipe if available. That way, I can use the best available binding for my needs. I only rely on the fact that a metadata endpoint exist on the server.
I hope this helps
BTW, this is done using .NET 3.5. However it does work also with 4.0.
Well in order to use ChannelFactory<T> you must be willing to share contract assemblies between the service and the client. If this is okay with you then ChannelFactory<T> can save you some time.
The proxy will build async functions for which is kind of nice.
My answer is a kind of summary of Keith's and Andrew Hare's answers.
If you do not control server, but have only WSDL/URL- generate proxy using Visual Studio or svcutil. (Note that Visual Studio sometimes failed, when svcutil works better).
When you control both server and client, share interfaces/contracts and call ChannelFactory
.
It's not just a matter of time saved. Using the WSDL generated proxy is dangerous because if you forget to update the service reference you can leave the solution in an inconsistent state. Everything compiles but the service contract is broken. I definetly suggest to use a ChannelFactory whenever possible, you make your life much easier.
A possible alternative could be to write a prebuild script that calls the SVCUtil utility to create the proxy everytime you build your project, but anyway ChannelFactory is much more neat and elegant.
I'm trying to use NeoLoad to generate and execute SOAP requests and upon supplying the WSDL, it doesn't seem to like the imports that they are referring to.
I'm thinking I would need to flatten the WSDL generated by the WCF service.
Are there any techniques I could use to flatten it?
I've been reading:
http://blogs.msdn.com/dotnetinterop/archive/2008/09/23/flatten-your-wsdl-with-this-custom-servicehost-for-wcf.aspx
http://blogs.thinktecture.com/cweyer/archive/2007/05/10/414840.aspx
Would this be something I should be trying out?
Yes, some clients have trouble with the (standards-compliant) way that Microsoft has implemented the WSDL and XSD.
Those two articles you mention are great starting points - they show how you can get your WCF service to render out a flattened WSDL (which includes the XSD inside it).
The same goes for WCF Extras on Codeplex, which also does a few more things in addition (most notably exporting the XML comments from your C# or VB.NET code into the WSDL). Highly recommended.