I've been given a WSDL file and several XSD files to build a web service for. Right now I'm trying to just get it setup to receive requests and respond.
My experience with WebServices is limited to the old asp version with an asmx file etc.
There is a lot of information in the XSD files, I don't want to build out the classes by hand, nor do I really understand exactly what that would entail anyways (I'd imagine just an xml serializable class but haven't looked into it).
Where do I start with this? I looked into WCF but its completely foreign to me so I'd kinda rather use the old style, but I'm struggling to find any info on how to set that up or get a head start with automated generation of classes from the XSD files.
I did try WCF a bit, but WSCF blue gives me errors (Cannot import wsdl:portType) when I try to generate the WebService code. And svcutil.exe will generate some of the XSD file info but not all of them for some reason.
So two questions:
How can I generate some stub classes from XSD files to get this going
A tutorial/walkthrough for generating a WCF service from a WSDL and multiple XSD files that does not use wscf blue?
Assuming you have a WSDL to start with, you can do the following. I did this when tasked with implementing an intermediate dispatch layer on top of an existing web service. The new service should expose the same interface as the original service but perform different functions internally. Note that I am talking about "classical" WCF services here (SOAP-based).
Step 1: Create code for the service interface from the WSDL
wsdl.exe /si /out:<targetfolder> <url-to-wsdl>
This generates a .cs file that contains the interfaces and additional data types (for transfer objects). Note that this file is not WCF-ready yet as wsdl.exe seems to assume you want to create an old .asmx service.
Step 2: Import interface code into your project
Add the generated file to your project. Add attributes for making the interfaces and their operations WCF-ready. You need to add [ServiceContract] to the interfaces and [OperationContract] to the operations.
Step 3: Create the WCF service
Create a WCF service (.svc file) and get rid of the generated interface. Instead, make the service implement the contract(s) from the generated interfaces. Now, you can implement the new functionality.
Step 4: Adjust the remaining binding, authentication settings etc. to match the original web service.
You can use the svcutil.exe to generate proxy .cs classes and app.config files for your client part of the service setup, from the wsdl and xsd files.
Following is a cmd that will will generate a proxy from the visual studio cmd line:
svcutil.exe c:\OutputFolder\ /o:serviceproxy.cs /config:app.config "C:\WSDL And XSD Folder\*.wsdl" "C:\WSDL And XSD Folder\*.xsd"
These might help you get started - if you plan to go the RESTful route:
http://www.codeproject.com/Articles/571813/A-Beginners-Tutorial-on-Creating-WCF-REST-Services
http://msdn.microsoft.com/en-us/library/bb412178.aspx
http://nareshkamuni.blogspot.com/2011/12/window-communication-foundation-wcf-in.html
More in depth - http://www.thatindigogirl.com/ - Michele Leroux Bustamante from a few years ago.
Not so much a walkthrough - but has good info http://rest.elkstein.org/2008/02/what-is-rest.html
Related
I have a WSDL definition for a SOAP service and I have successfully generated *.cs file from it using SvcUtil.
Implementing client is quite straightforward - I just need to call the necessary functions from the generated *.cs and that's it.
Implementing server seems more complicated. As I understand I need to implement an interface from the generated *.cs and then use some magic to turn it into the web server.
But I don't need a new web server, I already have a web server written in C# which already has many functionality unrelated to the SOAP service that I need to implement. I don't want to create another web server but I want my SOAP service to be just a part of my existing application (server), that is my server can answer e.g. requests http://example.com/request1, http://example.com/request2 etc. and I want this SOAP service to be just http://example.com/request3.
Since HTTP is already handled by my server I don't need .NET to handle it for me, basically my server can accept client connections and call the necessary handler based on the URL. I have a handler for SOAP request which looks approximately like this:
MyResponse HandleSOAPRequest(MyRequest request)
{
// 1. parse soap message from request.body
// 2. process it
// 3. generate response, serialize it in SOAP format and return it
}
The question is - can I rely on WSDL definition and .NET libraries to do it?
Currently I'm parsing SOAP request using XDocument and manually extract fields from it and serialize using simple string concatenation. Using .NET built-in functions to serialize or parse XML doesn't work. That is if I try to serialize response from an object of the class defined in the generated *.cs file then produced XML is different from what is expected by the protocol, similarly, if I try to parse request as an object of the class defined in the generated *.cs file I get error because XML parser expects different format. This applies to both the SoapFormatter and XmlSerializer.
Since .NET can implement client this means that everything that is necessary to parse and serialize SOAP messages is already implemented, I just need to figure out a way how to use this functionality.
The documentation for ServiceModel wasn't very helpful.
The easiest way would be to start the service via the ServiceHost:
ServiceHost host = new ServiceHost(typeof(YourService));
host.Open();
(I assumed here the configuration will come from the app.config and will not be setup in code like in the linked example below.)
How to: Expose a Contract to SOAP and Web Clients
The only drawback of this is that the application has to run with admin rights or otherwise a weird cofiguration is necessary.
Working with inherited code that reads data from one database (Visual Fox Pro) and stores it in SQL server. These are separate systems and use a WebService to send XML containing data from VFP.
A field has been added to both databases, and data has been seeded in the VFP database, but we are having problems with the WebService that is meant to sync the data. The WebService seems to be correctly generating and sending XML (with the new field and data) however it appears that the models that are meant to handle it on the .NET application are not being generated correctly and do nothing with this new field.
While viewing the object browser there is an 'OnlineAudienceWebServiceRef' within that, there is an OnlineAudienceDAL.OnlineAudienceFoxProRow which appears to contain a description of columns of the model. We are trying to add a new column to this Object (to receive the new data) but it appears auto-generated.
My question is, fundamentally, what is happening when Visual Studio is linked to a WebService? What files are generated, and how are they generated?
Given the web service correctly sends the new data, I was expecting Refs to be updated upon clicking 'Update Web Reference' from the solution explorer, but apparently that is not the case, and I would like know know what is going on.
There is an 'OnlineAudienceDAL.xsd' where we have added the new column, but we do not see that impacting the Object that is used to read the data.
According to App.config the app is using .NET v4, we are using Visual Studio 2010.
I am not familiar with .NET and the many things that are going on here, and would like to be pointed in a good direction. Sorry if this is confusing, please let me know what information I might be omitting and if anything is unclear.
Thank you for any help.
This is an example the Command Line Utility used by visual studio to generate the web service manually IF you have the WSDL (or XSD) file in a local folder. (WSDL is the Web Service Definition File)
This is in a batch file in my case... and also generates a VB file, but is easy to switch to C# I'm assuming with the last command line argument.
cd C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin
wsdl.exe "c:\development\WebServiceClients\CORE_Webservice_Interface_WS.wsdl" /fields /n:Telus /out:"c:\Development\output\WebServiceClients\referencefile.vb" /l:VB
WSDL.EXE is the core of this... below are the options...
c:\Program Files (x86)\Microsoft Visual Studio 8\SDK\v2.0\Bin>wsdl /?
Microsoft (R) Web Services Description Language Utility
[Microsoft (R) .NET Framework, Version 2.0.50727.42]
Copyright (C) Microsoft Corporation. All rights reserved.
wsdl.exe -
Utility to generate code for xml web service clients and xml web services
using ASP.NET from WSDL contract files, XSD schemas and .discomap
discovery documents. This tool can be used in conjunction with disco.exe.
wsdl.exe ...
OPTIONS -
-
A url or path to a WSDL contract, an XSD schema or .discomap document.
/nologo
Suppresses the banner.
/language:
The language to use for the generated proxy class. Choose from 'CS',
'VB', 'JS', 'VJS', 'CPP' or provide a fully-qualified name for a class
implementing System.CodeDom.Compiler.CodeDomProvider. The default
language is 'CS' (CSharp). Short form is '/l:'.
/sharetypes
Turns on type sharing feature. This feature creates one code file with
a single type definition for identical types shared between different
services (namespace, name and wire signature must be identical).
Reference the services with http:// URLs as command-line parameters
or create a discomap document for local files.
/verbose
Displays extra information when the /sharetypes switch is specified.
Short form is '/v'.
/fields
Generate fields instead of properties. Short form is '/f'.
/order
Generate explicit order identifiers on particle members.
/enableDataBinding
Implement INotifyPropertyChanged interface on all generated types
to enable data binding. Short form is '/edb'.
/namespace:
The namespace for the generated proxy or template. The default namespace
is the global namespace. Short form is '/n:'.
/out:
The filename or directory path for the generated proxy code. The default
filename is derived from the service name. Short form is '/o:'.
/protocol:
Override the default protocol to implement. Choose from 'SOAP',
'SOAP12', 'HttpGet', 'HttpPost'.
/username:
/password:
/domain:
The credentials to use when connecting to a server that
requires authentication. Short forms are '/u:', '/p:' and '/d:'.
/proxy:
The url of the proxy server to use for http requests.
The default is to use the system proxy setting.
/proxyusername:
/proxypassword:
/proxydomain:
The credentials to use when the connecting to a proxy server that
requires authentication. Short forms are '/pu:', '/pp:' and '/pd:'.
/appsettingurlkey:
The configuration key to use in the code generation to read the default
value for the Url property. The default is to not read from the config
file. Short form is '/urlkey:'.
/appsettingbaseurl:
The base url to use when calculating the url fragment. The
appsettingurlkey option must also be specified. The url fragment is
the result of calculating the relative url from the appsettingbaseurl
to the url in the WSDL document. Short form is '/baseurl:'.
/parsableerrors
Print errors in a format similar to those reported by compilers.
ADVANCED -
/server
Server switch has been deprecated. Please use /serverInterface instead.
Generate an abstract class for an xml web service implementation using
ASP.NET based on the contracts. The default is to generate client proxy
classes.
/serverInterface
Generates interfaces for server-side implementation of an ASP.Net
Web Service. An interface is generated for each binding in the wsdl
document(s). The wsdl alone implements the wsdl contract (classes
that implement the interface should not include either of the following
on the class methods: Web Service attributes or Serialization
attributes that change the wsdl contract). Short form is '/si'.
/parameters:
Read command-line options from the specified xml file. This allows you
to specify options not available from command line such as choosing
which type of asynchronous programming model is generated. For details,
please see the tool documentation. Short form is '/par:'.
Hi i need generate web service proxy for C# client. Web service is java. I have wsdl + xsd file for web service.
I try use wsdl.exe tool
wsdl /out:D:\filename.cs /protocol:SOAP12 C:\filename.wsdl
But problem is that some definition are in xsd file. how to merge it. I think it is new standard
Have a look at the /par switch for the WSDL tool
I know it's been a while since this question was asked, but I also needed to use an XSD with my WSDL today, so this popped up in my search.
I ended up using wsdl.exe like this:
wsdl C:\filename.wsdl C:\filename.xsd /out:C:\filename.cs /protocol:SOAP12
If nothing else, it might be useful to someone else someday :-)
can anyone tell me if there is a tool for creating the strongly typed classes (available via the schema) - i suppose similar to Paste as XML type ..
But i was hoping for a tool that i could run to automatically update the classes automatically when there are changes
Does anyone know if something like this exists?
If you have a WCF Data Service (f.k.a. "Astoria" or "ADO.NET Data Service"), you can use the regular Add Service Reference in Visual Studio, point it to the SVC file for the service, and voila - you get a data service client side proxy, with strong types and all, and the ability to query your data service (a REST service) using LINQ - LINQ-to-REST, so to speak!
See the MSDN docs for a few more bits of info.
I have numerous Web Services in my project that share types.
For simplicity I will demonstrate with two Web Services.
WebService1 at http://MyServer/WebService.asmx
webService2 at http://MyServer/WebService.asmx
When I generate the proxy for these two services I use:
wsdl /sharetypes http://MyServer/WebService1.asmx http://MyServer/WebService2.asmx
/appsettingurlkey:WebServiceUrl /namespace:MyNamespace /out:MyProxy.cs
The problem is that the appsettingurlkey is the same for each Web Service
in the proxy file. I want to be able to specify multiple
appsettingurlkey parameters. How is this accomplished? I figure
since the /sharetypes parameter became available, there should be a
solution for specifying the appsettingurlkey specifically for each
Web Service identified.
If this is not possible with the wsdl.exe, what would you propose I do? I would rather not update the generated code that wsdl.exe outputs and I don't want to go through my whole application passing in the Url to each instance of the Web Services.
The proxy classes generated are partial classes, so my solution would be to add your own constructor in a different (non-generated) code file, which explicitly reads a different setting for each proxy.
To suplement Elijah's own answer, here's the email answer I gave him.
I had to blog it because the XML didn't paste well into this text box: http://www.rickdoes.net/blog/archive/2008/09/29/wsdl-shared-types-and-configuration.aspx
Ahh, instead of creating another partial class with an overloaded constructor passing in the Url, the following additional parameters to the wsdl.exe will solve my problem...
wsdl /sharetypes http://MyServer/WebService1.asmx http://MyServer/WebService2.asmx /appsettingurlkey:WebServiceUrl /namespace:MyNamespace /out:MyProxy.cs /appsettingurlkey:BaseSoapUrl /appsettingbaseurl:http://MyServer/
If the web.config has a BaseSoapUrl appSetting, then it will use that to replace the http://MyServer/ sub string from the MyProxy.cs. If the appSetting is not present, then it will just use the path provided in the wsdl.exe (example: {BaseSoapUrl}/WebService1.asmx when using the appSetting or http://MyServer/WebService1.asmx when not using the appSetting).
A thanks goes out to Rick Kierner for pointing me in the right direction.