I am trying to create a Windows Store App that consumes a web service. Visual Studio denies to create service proxy methods with following warning in logs:
Custom tool warning: Contract ... is not compatible with Windows Store apps because it contains one or more operations with SOAP Encoding (use='encoded'). Only the non-encoded operations will be generated.
So the questions are:
Where can I find full list of Windows Store app limitations on web services consumption?
Are there any known workarounds (given I can't change the service)?
It seems you're pretty much screwed if you can't change the web service because of the way that any wrappers are most likely SOAP encoded, and also the SOAP Toolkit doesn't allow for much output customisation.
Perhaps writing a (possibly functionally duplicated) web.api based webservice is a better solution? See this link for an example
EDIT: In response to the first comment...
Yes and no; essentially create a REST (whether that be webapi, WCF etc is upto you) wrapper.
See these informative posts on creating a REST wrapper:
helpfull post number 1 and helpfull post number 2
You can create a NETStandard class library to reference the webservice, then reference this library to your web project.
Related
I was tasked at work to create a web application (viewable in Firefox on Linux!) that displays results in a tabular format using data exposed by a WCF service (written in C#) hosted on a separate Windows 7 machine on the same network. Rather than returning formatted HTML, the WCF service returns structs and it will be up to the client application to take these objects, pull out the data, and format it.
Unfortunately, it has been a couple years since I have worked with any sort of web technologies. What is the best approach to solve this problem? Is there anything more current than REST/AJAX/JSON/jQuery technologies? If anyone can point out some helpful and current resources on the proper way to accomplish this, it would be most appreciated.
Use a SOAP framework to consume the WCF service. Configure WCF to use SOAP (one of the HTTP-bindings).
Webservices are easy to consume these days thanks to a standard RPC format (SOAP) and libraries supporting it. You can surely find a SOAP client for any language you are proficient in.
Checking back in here to report my own solution for this problem. I ended up going a bit of a different route that produced the simplest solution for the situation. Instead of consuming any services on the Linux side, I simply made an ASP.NET website on the Windows/IIS side (where it is easy to consume the WCF services right from Visual Studio), and then just render the website on the Linux side via the URL in a Firefox browser. For me, that fulfilled the customer requirements and was perfect, although this may not be the best approach for others that need to work with or manipulate the data in some way.
I am a Java developer who has created a rather big Web service that works nice with Java clients or other tools (Soap UI).
One of our clients wants to write a .NET client for the web service and uses the "add service reference" feature of VS2010. According to the client this does not work since our WSDL and XSD files use "Forbidden XML constructs" as defined in this article:
The problem is that we have made heavy usage of xsd:attribute data in WSDL.
So the question is:
Is there a workaround to make .NET stub generation code compliant with WSDL/XSD files that contain xsd:attribute? Is there another .NET library for webservices that supports this feature?
Another question of mine would be why does Microsoft impose these limitations in the first place? Why xsd:attribute is a forbidden costruct in a web service??? Any clues on that?
Probably related: C#.NET Generating web service reference using WSDL (from XML schema) problem
If you have access to a machine with the .NET Framework on it why don't you use svcutil to generate a proxy/config settings for him and send it to him?
See www.svcutil.com for the list of switches and options that are available to you
I have found that if the customer cannot do it one way and you provide a documented (possibly automated) way of doing things then that will generally suffice.
I have tested the HelloWorld.wsdl supplied in the link with the .NET version of Remobjects (http://www.remobjects.com) and it seemed to work fine. I don't have an actual service to test this with but I would suggest that you (or the client :) ) download it and give it a try.
The .NET version can be found here:
http://www.remobjects.com/ro/net.aspx
Apparently the answer is that you should NOT use the modern way of generating stubs with svcutil.exe and instead use the legacy way with wsdl.exe
Creating stubs from the command line with wsdl.exe works fine. The resulting code works as expected and the .NET client connects to the Axis2 Web service.
I am a total newbie to the WCF world. I have an ASP.net (v4) website running on our dedicated windows 2008 server box. I'll refer to the website as, webisteA.com
I'm creating a new website, websiteB.com.au and I'd like to expose the functionality in WebsiteA.com to the new site. Things like logging in, registering in the database etc.
I think the best way to do this is to create a WCF service which sits in WebsiteA.com - but I am struggling to find any tutorials on how to do this. There are lots about creating a new project, but not that many about adding a WCF service to existing websites.
Is this the best way to do it? In the future I'd also like to use the service for mobile apps in the future too - not sure if that will make a difference.
OR - do I create a new service in a new app which is totally seperate to websiteA.com and websiteB.com and host this as website0.com and expose the database via that?
The questions I don't have answers for are...
is it restful? Do I use XML or JSON?
Baiscally, I want to be able to use it like an API - for example, saying "show me all the members who meet criteria X".
Thanks for any information.
ps) I have visual studio express 2010 c# (and a trial of studio pro)
You can certainly include WCF within the website A project - but have you considered the ASP.NET Web API? I haven't used it yet - but did use the earlier WCF Web API which spawned it.
Neat features include Content Negotiation (if the client asks for XML the API sends XML. If it asks for JSON is gets JSON) and a lot less config cruft (WCF web.configs are dreadful and completely overcomplicated IMO)
It's probably a lot easier to make a RESTy API with the ASP.NET Web API than with standard WCF.
A great open-source .NET solution is NancyFX which is really worth a look too.
I have N quantity of "clients", and each one has to implement a web service for my .Net app to consume. I dont want to add a service reference for each client because they can change at any moment, as well as the URLs, so I store the URLs on a database and dinamycally create the endpoint depending on which client I want to access.
I was wondering if I have to force my clients to write the same type of services(either WCF or JAX-WS) or I can still connect to one or another without writing some kind of conditional logic.
ie. If JAX-WS then "do this" ELSE IF WCF "do other stuff"
Also I was wondering if adding WS-*(wshttpbinding) security would add more complexity for the interoperability(or interchangeability) of the two technologies.
Any comments about this approach would be greatly appreciated.
It's possible to implement this without having to use an if-else , all clients/implementations (.NET and Java) must to use the same contract (WSDL) which should not be a big issue.
For the WS-* this is quite easy using only .NET BUT it's hard (not impossible) to get it working from .NET to Java so I usually end up doing basicHttp using SSL with either basicauthentication (username/password) or certificates. This is a lot easier than wsHttpBinding from .NET to Java.
Like Cheeso says, start with the WSDL, i.e. create a client and service in .NET, this will give you a WSDL, then take that WSDL and use it to implement the Java clients.
Start with WSDL first. If you don't know what this means, google it.
This does not guarantee interoperability but it gets you a long way on the path.
As for adding WS-*, yes, that introduces an additional level of interop challenge.
How do I build a XML-RPC web service in C#?
I've seen some people produce "web services" that are just simple .aspx pages that spits out Xml instead of html.
The "proper" way to do this is to probably to implement your own custom http handler though.
That said, you should have a really good reason to not use SOAP based services before you go to all that effort.
UPDATE: Have you seen XML-RPC.NET?
[It] is a library for implementing XML-RPC Services and clients in the .NET environment.
You could implement either a generic handler (.ashx) or an ASP.NET 2.0-compatible service (.asmx). You would then need to handle the XML parsing and construction either using .NET classes for XML or just on your own.
Edit: I took out information about WCF since the question changed, making it irrelevant.
if you mean RPC where you cliend simply sends raw XML via form variables, etc, and you parse it in the implementation of your service, .net 3.5 and wcf support out of the box POX services.
http://msdn.microsoft.com/en-us/library/aa395208.aspx