I have a server/client application developed in Delphi 2006. The client is Win32 and the Server is a .net 1.1 webservice.
We are in the process of updateing this project, but it has to be done in small steps. I started with the server and created a WCF project in VS2010(C# .net 4.0). The first step is to get the server running in WCF without changing the client. So I used the facade pattern, created a similar interface to the old delphi Webservice added a reference to the old .net 1.1 dll and in my implementation I just called the old .net 1.1 code.
Next step updating the proxy class on the client. This failed. The WSDL importer didn't understand the basicHttpBinding correctly, so the proxy class that was genereated couldn't replace the existing proxy.
After a bit of research I found this blog post.
http://kjellsj.blogspot.com/2006/12/how-to-expose-wcf-service-also-as-asmx.html
This worked, the ASMX WSDL was no different than the old .net 1.1 so everything appered ok.
But it wasn't. When testing the new service I discovered that all my parameters was blank/null on the server. I tried with Fiddler on the client and the parameters is present in the XML that is sent to the server.
So I'm stuck. Any thoughts on how to solve this would be much appreciated. Is there any code that could be interresting to see then let me know.
I ran into a similar problem with a web service asmx... certain data was losing their values. If you are using hierarchical data, you may need to declare the internal or inherited objects using an XmlInclude attribute. For example, if you have a User class that is used in your service and a Customer sub class, you may need to declare the Customer class to the service if it is not used directly in a web method. You would do this as follows.
[XmlInclude(typeof(Customer))]
public class Service : WebService
Of course, it may be nothing to do with this, so good luck if that's the case. :)
Confirm that the parameter names in the new service match the names in the old service. If you have changed the parameter names, they will not map from the XML so will be null in the executing code.
Add KnownType attribute to the sub classes
Related
Ok this is kind of a complicated situation so let me start by laying out what I'm trying to do.
I have a WCF web service that is using DataContractFormat to serialize requests as JSON. One of the clients of the web service generates a reference file using my wsdl and uses the soap endpoint on his end to make calls back and forth. Until now, this has been working great because we have had the ability to provide support for SOAP and also REST/JSON requests.
Our current project required us to include methods from RSA which exposes their webservice with a wsdl. So we are basically doing SOAP calls to them, and generating a reference file on our end and then using the classes and methods generated in our web service.
The problem we are getting is that the client is getting build errors in reference to not being able to serialize IPropertyChangedEventHandler which is included in all of RSA's classes. What I suspect is the problem is that RSA's classes are all defined using the System.Xml.Serialization methods and my web service is written to use the DataContractFormat instead of XMLSerializerFormat so it doesn't know how to serialize the classes. How do I get around this without completely rewriting the reference file using DataContract? Or is there possibly something else I might be overlooking?
Let me know if you need more details.
A coworker was able to figure out how to generate the RSA wsdl without the PropertyChangeEventHandler in the methods. We were able to get the reference file to generate without PropertyChanged by changing the svcmap file under the Service Reference folder
<EnableDataBinding>false</EnableDataBinding>
After changing this, we updated the service reference and all the PropertyChanged stuff was gone and we no longer got build errors.
I have a net.tcp binding example that apparently dates back to .NET 2.0 runtime version. The client code of the WCF Net.TCP binding example has an interface marked as "System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServiceModel", "2.0.x.x") or so.
it also defines some Request & Response classes where the request apparently wraps the parameters of the service operation contract and the Response class wraps the result/return value. And it also defines a controller class for the service.
Now, in a WCF hosted by winform with net.tcp binding, I have found no way to autogenerate these classes myself. I wonder, is that an old way of doing things? is it required? or can I just include in the client app a reference to the DLL that contains the service?
I made some changes and now nothing works and wondered if I can just get rid of those "autogenerated" classes (or if not, HOW can I regenerate them?).
I use Visual Studio 2012 Ultimate for .NET 4.5 under Windows 7 Ultimate. My application are two winforms (client and server) that use WCF with netTCP binding.
Apparently I have to point svcutil o the base address rather than that of the service or endpoint. Then it will generate the client code and config.
I have a WCF deployed on IIS. Now by adding web reference of it i am using it on my app.
So I have two questions:
Is it the best method of consuming WCF.
If the answer of first question is yes then what is the role of svcutil.exc, I mean what is the use of creating wcf proxy class. and if the answer is "No" then why?
It is the easiest solution if you develop with visual studio and have access the remote WCF service.
If you are developing using another IDE, you might want to use SvcUtil to generate your proxies.
If you prefer to have a simple CS file containing the generated client, you might also choose to generate it using SvcUtil.
You may also completely ignore SvcUtil and the Service Reference wizard and use the ChannelFactory class to generate proxies dynamically.
You should use "Add Service Reference" in Visual Studio (not Add Web Reference) for WCF.
It is the easiest way - since you can do it right in Visual Studio. What it does under the covers is basically call svcutil.exe (or you can do that manually, from the command line yourself), and create a service proxy class for use on the client side.
The use of svcutil.exe is many fold - you can create a client proxy class from a running service (or from an existing WSDL/XSD file), you can verify services, you can export metadata from a service for clients to consume, and a great many more options. It's the "Swiss Army Knife" of WCF tools.
WCF uses a concept that all calls to your service must go through a client proxy - this is the place where the entire WCF runtime lives, and where all the WCF extensibility points are located. This proxy converts your call to a method on the client into a serialized message that gets sent across the network to the server for processing, and it also handles "unpacking" the response from the call back into classes and objects on your client side for your use.
Adding a service reference is the quickest and easiest way but not always the best way. If you want performance then using ChannelFactory<T> is the way to go. You should know different ways to create a client side proxy and customisations that you can do.
An excellent resource is WcfGuidanceForWpf. Don't let the WPF in it scare you as it is really an excellent guidance for general WCF as well.
We currently have a WCF Service which is beginning to reach it's limits performance wise.
We have decided to add another server which will host another instance of the WCF Service.
We have web applications which must communicate with a specific server based on context... e.g. If the web application is dealing with objects from ServiceInstance1 then requests must be directed to ServiceInstance1's EndPoint. If the web application is dealing with objects from ServiceInstance2 then requests must be directed to ServiceInstance2's EndPoint.
I initially thought that a "Intermediate Service" or "Service Manager" could be created, the web application's Service Reference would be updated from the individual Service Instance to the "Intermediate Service" or "Service Manager" and said service would act as a "Broker" to the various Service Instances.
How is this accomplished?
I have currently added a ServiceReference to each service from the Manager however it seems that once a Service is "Referenced" it's types becomes specific to the that of the ServiceReference e.g.
ServiceInstance1's type's are all {ServiceInstance1}.
ServiceInstance2's type's are all {ServiceInstance2}.
I need the types to be the same on the web application end, so this obviously seems like the wrong way to do it.
I would also like that when methods are called on the client generated from referencing the "Intermediate Service" or "Service Manager" that the correct Service Instance is invoked, e.g.
IServiceManager.GetProjectById( {GUID} ) ->
Comes Back to ServiceManager ->
Determines which host has the project and returns the ProjectObject from the correct ServiceInstance.
Where ProjectObject is a Type Defined in ServiceInstance1 and ServiceInstance2.
I think the original service needs to have some of the DLL's pulled out so they can be referenced from the web application side and ServiceManager and a GenericWCF Client can be made.
If I am right hooray for me If someone can point me in the right direction I would appreciate it. If I am wrong can someone please scold me and show me how this is properly done!
The way to solve your problem is to create shared assembly with types used by both services. Reference this assembly on the client consuming your services (manager) and when creating proxies by Add service reference mark Reuse types from referenced assemblies.
What you are building is very simple message router. In WCF 4.0 there is additional support for routing services so you should check those features before developing your own. For WCF 3.5 MSDN magazine contains articles about building message router - part 1, part 2.
Just to Answer this and close it I wound up utilizing the Routing Strategy in .Net 4.0 and custom client class which I modeled after the generated classes from the Proxy.
Before I had the custom client ready I used the auto generated client code and I derived a class from it which allow me to change which service it was connecting to. I determined which service via a property which was made available on all service objects which were serialized.
Long story short this is working 100% as expected including the ServiceManager which can even be bypassed on certain calls which we allow.
We even have the ability to move a project from server to server during run time!
Thanks to everyone who helped! (Especially myself for actually doing the work without being spoon fed)
The easiest way to accomplish what you're trying to do is to stop generating your proxies using the server-hosted URL of the service. Instead, generate your proxies from the *.xsd and *.wsdl locally, and merely change the URL of the endpoint. Alternatively, you can use ChannelFactory<T> to generate proxies on-the-fly, and reference your interface .dll on the client side.
Once you've done that, you can use any common webserver load balancing technique to balance the load between the servers.
Not to put too fine a point on it, but Visual Studio's "Service Reference" is not useful, and should not be used, for services you develop. It's useful only for services developed externally, whose URL and contracts are likely to NEVER change. I personally have never had occasion to use it. For your own services, you should probably be using ChannelFactory<T> or a class based on ClientBase<T> to work out the proxies.
Has anyone done this? I've tried generating a c# proxy class and connecting through it, but I cannot figure out how to get IronPython to use the generated app.config file that defines the endpoint. It tries to connect, but I just get an error about no default endpoint. I would ideally like to make the connection using only IronPython code and not use the proxy class, if possible. The binding for the service I am trying to connect to is a NetTcpBinding if that makes any difference.
See my blog post. There are IronPython WCF service and client examples.
To use app.config, you probably must copy it to ipy.exe and rename it to ipy.exe.config but I have not tried it so I don't know whether it works or not.
Is your WCF service interface available in a shared assembly? If so, you could look at using the ChannelFactory to create your client proxy dynamically (instead of using the generated C# proxy). With that method you can supply all the details of the endpoint when you create the ChannelFactory and you won't require any configuration in your .config file.