We've a WCF / ASP.NET hosted web service. The data types in the service contract use XSD.exe generated types, and hence are decorated with XmlSerialization attributes. We created a client for it using SvcUtil, including using the /ser:XmlSerializer parameter. Been working for many years.
We just upgraded our build scripts to use VS 2012, and the v 8.0A Windows/.NET SDK NETFX 4.0 Tools version of SvcUtil.exe (v 4.0.30319.17929).
We are now seeing a strange error message when our client (built w/ VS 2012 and the new 8.0A SvcUtil) attempts to call the WCF service:
Type 'System.Threading.Tasks.Task1[MyNamespace.MyClient.MyDataStructure]' cannot be serialized. Consider marking it with the DataContractAttribute attribute, and marking all of its members you want serialized with the DataMemberAttribute attribute. If the type is a collection, consider marking it with the CollectionDataContractAttribute. See the Microsoft .NET Framework documentation for other supported types.
This error prevents our application from being able to call the WCF service, and we're stuck.
I note that we are not passing a parameter to SvcUtil for /async. I also note that the SvcUtil help for .NET SDK 8.0A (v 4.0.30319.17929) indicates that the default is to generate synchronous and task-based asynchronous method signatures. Is there some built-in disconnect between System.Threading.Task and XmlSerializer ?
Suggestions for how we can prevent the runtime from somehow thinking we're using DataContractSerialization when we intend XmlSerialization?
Have an answer from Microsoft, posted here.
Short is that /syncOnly will be needed if you intend to build with .NET 4.5 SvcUtil but target the .NET 4 runtime.
Related
On the .net side, this just hangs. MyService is only deployed on the Java side.
var svc = Ignite.GetServices().GetServiceProxy<MyService>("MyService");
Do I need to do something special on the Java side or the .NET side to access the Java service from .NET side? It's also important that the .NET side is running in client mode. We don't want the GUI to participate in persistent storage or compute.
Apparently this is fixed, but I can't find any documentation on how to use it.
https://issues.apache.org/jira/browse/IGNITE-2686
Thanks.
I've added documentation:
https://apacheignite-net.readme.io/docs/calling-java-services
Main requirement is to have Java service class in classpath on all nodes (including .NET client node). This should be addressed in https://issues.apache.org/jira/browse/IGNITE-975.
Other than that it is quite flexible, you just need an interface in .NET with same signature as in Java service.
After reading some info about adding Dependency Injection (for use with Unity) i still have one issue: WcfTestClient.
At this point of development i really don't want to install my Windows Service each time i hit F5, i just simply want to keep using the WcfTestClient (i think, or are there better ways?).
But the document explaining the way to use Dependency Injection with WCF services all mention '.svc' file... my project type (WCF Service Library) does not have a '.svc' file.
Sample documents:
- How do I pass values to the constructor on my wcf service?
- http://www.i-avington.com/Posts/Post/usng-unity-with-a-wcf-service
- http://orand.blogspot.nl/2006/10/wcf-service-dependency-injection.html
How can i use Dependency Injection with Wcf Service Library working with WcfTestClient?
In most examples of WCF services that use MSMQ transport it is always preferred to create a proxy manually using svcutil in Visual Studio command prompt rather than simply adding a Service Reference. When you can just reference the service by providing its endpoint address to the Add Service Reference dialog in visual studio why would you want to create a proxy with VS command prompt (since it is slightly more laborious)? I just came across this while reading WCF 4 Step by Step:
Note that you cannot easily use the Add Service Reference Wizard in
Visual Studio to add a reference to a WCF service that uses the MSMQ
transport.
Why exactly is it difficult? What exactly is the benefit (if any) of the former method of referncing a WCF service? It seems to me that creating a proxy manually is just unnecessarily complicating the task.
You don't need to pre-generate a proxy as long as you have a reference to the assemblies which define the service interface, operations, and data contracts. You can then create the proxy on the fly using ChannelFactory.
var factory = new ChannelFactory<IMyServiceInterface>("MyServiceNameInAppConfig");
var proxy = factory.CreateChannel();
This is far simpler than using svcutil. However, if the service is remote and you cannot get access to the type assemblies then you have no other choice but to generate a proxy.
Regarding your question about why it's easier to use svcutil instead of VS to generate the proxy code, without seeing the actual book it is hard to comment, but under the hood visual studio uses svcutil to generate the code anyway, so I can't see how it would be any better or worse. When you do this manually then you have more control over what gets generated I guess.
We have an EPOS system that is built in VB6. A client is using Microsoft Dynamics AX as a CRM system. A 3rd party has created the AX implementation for our client and they've exposed a set of WCF web services that we need to consume to synchronise data between the EPOS and the AX CRM. Knowing VB6 would have issues calling WCF services, I created the following components to handle the communication between the EPOS and the AX CRM.
VB6 EPOS which calls -->
1) VB6 DLL wrapper which calls... -->
2) .NET(3.5) COM Callable Proxy DLL wrapper which calls... -->
3) .NET(3.5) Web Service Handler (Where the web servicesw actually get called) -->
Microsoft Dynamics AX CRM.
I built a test console app in Vb.NET to simulate calls from VB6 to help with debugging, so that test console app calls component 2.
Whilst doing this I was getting the following exception:-
"(could not find default endpoint element that references contract 'X' in the servicemodel client configuration section. this might be because no configuration file was found for your application, or because no endpoint element matching this contract could be found in the client element.)"
I googled around and found that I had to copy the bindings and endpoints section from Component 3's app.config to a new app.config for my Test Console app. I don't know WCF and haven't got the time at the moment, to really learn it to the point where I understand why this fixed this error.
Now though, I'm trying to call the services from the VB6 EPOS and this error is popping up again. So I added an app.config to Component 2, thinking that as Component 2 is the first .NET(3.5) component in the chain, that is where the endpoint declaration should go, but No. The error is still popping up.
Does anyone have any ideas? Any programming heroes out there that can shed some light on this for a simpleton please??? Please don't ask why we don't re-write the EPOS. We will. just not yet. Theres over 3 million lines of spaghetti code in there and I've only been working on it for 8 months!!!
As an aside, Doesn't this scenario break one of the golden rules of OOP, i.e. encapsulation. Why should my VB6 EPOS need to know what endpoints Component 3 uses to access the WCF service???
Great question here...
Your problem is essentially coming from all the required configuration data needed to work with a WCF Service.
When dealing with .NET Windows or Web Applications the configuration data on both the client and server sides of WCF Services reside in the application configuration file. For a windows application this file will be app.config, whereas it will be a web.config for a web application.
In your case, you would like to put the proxy logic in some form of a COM-visible .dll.
This is going to cause you some grief...in the .NET platform, the .config file for top-level host application (web or windows) is the place where all configuration data is read. Even if your application leverages dozens of .NET assemblies (each with custom configuration needs), the runtime is going to expect those configuration elements to all reside in the top-most application configuration file.
To resolve your issue, you are going to need to communicate to a service that VB6 does have access to (think ASMX web services) and have that service forward your call along to the appropriate WCF service.
The other alternative is to pass configuration variables directly from your VB6 application to your Com-visible assembly so you can use the extensibility model of WCF to create proxies (overriding the default behavior to read configuration data from a file) with your passed-in configuration.
I would say that the latter scenario could go both ways as far as being a violation of SOA/OOP..depending on the situation it may/may not be appropriate for the VB6 application to know about/store configuration details for communicating with the (eventual) WCF endpoint
What is "mexHttpBinding" in WCF? When should this binding be used in preference to other bindings?
It is a binding that returns metadata so you can build a proxy at the client side. See here. More here as well.
mexHTTPBinding allows to use WS-MetadataExchange over HTTP. You don't need it unless you implemented policies which may change over time and you need to discover your service with UDDI for example
Many people says it's needed for creating client side proxies. This is not true. For client side proxies you need to publish WSDL. You can do that by specifying in your service behavior.
Shortly, you don't know it -> you don't need it.
mexHttpBinding is used while adding a new Service Reference in a Project in Visual Studio 2013 (DEBUG) that will consume your WebService (providing the mexHttpBinding). After you've added the Service Reference successfully you might disable the mexHttpBinding.
It is all described in the App.config when you're creating a WCF Service Library Project in the Visual Studio 2013 ( Solution >> Add New Project >> Visual C# >> WCF >> WCF Service Library)