What is the best way to call a WebService via C++ ??
I want to avoid to use a C# Wrapper DLL with a COM Interface, so is there a Native way without using Sockets? In my current project the interface is trivial, but if there would be also a proxy generation it would be definitely the better choice :-)
Related
I have some troubles with using Portable Class Library. I develop both iOS and Android app and I want to create shared business layer using PCL. However, I use WCF class. Particularly the problem is when I use IExtendableObject, which isn’t exist in PCL. Is it possible to circumvent this problem?
Sorry, but what is exactly IExtendableObject ? Do you mean IExtensibleDataObject ?
Exposing a WCF service does not requires Xamarin. Use your favorite IDE to designa and develop it. You just have to use basicHttpBinding, because Xamarin can only consume a WCF web service using this kind of binding. Do not create a WCF service with a PCL !
PCL allows you to share code between all your mobile applications. In your case, this is at least the proxy code. To create a Xamarin compatible proxy you will use the Silverlight Service Model Proxy Generation Tool from Silverlight SDK 5 (SLsvcUtil.exe). Unfortunatelly, this type ExtensionDataObject isn't available in Silverlight.
I'm a bit surprised to see this requirement in Xamarin as it's used for Forward-Compatible Data Contracts.
Thank you for advise! It works, but we won't do it in our project. Insteed of it, we now use sharing code method: http://docs.xamarin.com/guides/cross-platform/application_fundamentals/building_cross_platform_applications/sharing_code_options/
I wish to use a particular API from my ASP Classic code. The API comes in the form of a DLL with .h and lib file. I have managed to use the api from my own Windows C++ application. I now wish to do the same for ASP. There is also a .NET Wrapper for this API which I haven't examined yet.
Furthermore, we will at some stage in the future migrate to ASP .NET or Python Django.
How would you recommend I wrap this API?
Thanks,
Barry
The best way is to wrap the DLL API that you need to use as a COM object.
The original ASP model makes use of COM to interface with native code.
I have a VB6 application that I want to communicate with a WCF Windows Service that I have written which imports Security Certificates. The only function in the service takes two string arguments. I have been having a lot of difficulty getting the two programs to communicate however.
In VB.NET, it is easy, just make a reference to the service as you would a web service. In VB6, however, it is not so simple it seems. Searching only seems to pull up examples of how to WRITE a Windows service in VB6.
Anyone know how this is done?
The easyest way I have found to access a WCF service from VB6 is to create a .Net ComObject wrapper for the service client. Then in VB6 all your are doing is a create object and calling some methods on the object. All the WCF work takes place in the .Net com object.
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.
I have a windows workflow foundation 4 service and a simple client.
When I add the service reference in the client visual studio doesn't generate a proxy class,
only the interface and types.
Anybody have any solution?
What should I do to work with the wf4 service properly? What kind of namespace and classes and contracts I need to use?
Thanks!
When the client project is a workflow project type setting a service reference works a bit different. Instead of generating the standard proxy classes it generates Send & ReceiveReply activities for use on a workflow. Very nice if you are building a workflow, not so when you want to call the service using regular code.
You can either use SvcUtil manually to generate your proxy classes or use the ChannelFactory with the generated interface to create the required proxy object. The last is usually the easier option.