It took a good bit of trial and error, but I was finally able to host my WCF Service in IIS.
I can browse to the WSDL no problem, and see all of the different methods/attributes.
Now what? I need to use my service inside of another Web App. How do I do that?
I was able to use svcutil.exe to generate the *.cs and output.config files, add that to my web app, and add a reference to System.ServiceModel That worked fine.
BUT, I need to figure out how to use my service hosted in IIS.
In my web app I've added a web reference to the WSDL, but I can't figure out how to expose the methods/attributes.
I'm not ruling out the possibility that there's a better way to do this...so I'm open to suggestions.
Can anyone point me in the right direction?
Right click on the client project and click "Add Service Reference". Then put in the address of your WCF service and it will create the proxies and plumbing for you.
You can add Service Reference to your service. By doing this you don't need the svcutil.
Or you can use the .cs that svcutil generated for you.
http://msdn.microsoft.com/en-us/library/ms730144.aspx
Simply you have to use the class on your .cs file. Istantiate it and call wcf methods...
Related
I'm writing asp.net/c# project and need to call web services which other client provide. I've found that most people right click "service reference" to add url and use it. The thing is, I got .wsdl file only, is there any way to use it directly?
I've tried the solutions in here and they didn't work.
Thank you for answering.
We've requested a company to write a webservice that we can use to get some information.They have sent us WSDL and XSD files. Could you please tell me how I can use these files to query data?
I can do it easily if I have a link to a webservice. I just provide the link and Visual Studio generates web reference for me. After that I can use that reference just like a normal class. In this case I have no link. Just above mentioned files. Thank you.
You can create a proxy (add service reference in visual studio) from a wsdl file. You can read about svcutil at http://msdn.microsoft.com/en-us/library/aa347733.aspx, but VS2010 allow you to put a wsdl file on adress when adding service reference.
VS2010 can't create a web service reference from some WSDLs. Have
to write custom wrapper for those. OR edit your WSDL in a way so
VS can consume it. For example it may be ok for you to remove web
service method references for the methods that you are not planning to
use if those references create trouble for you.
Unless you're stuck with .NET 2.0, you should not use ASMX web service technology.
You should use "Add Service Reference" and point it to the WSDL on disk. It will create a set of "proxy" classes with methods that you can call just as though it were a "normal" class.
See "How to Consume a Web Service" for a walkthrough with example.
Use WSDL.EXE utility to generate a Web Service proxy from WSDL.
e.g.
wsdl /language:CS /n:"Microsoft.SqlServer.ReportingServices2010" http://<Server
Name>/reportserver/reportservice2010.asmx?wsdl
check this for Creating and Consuming .NET Web Services in 5 Easy Steps Article and then Creating the Web Service Proxy
Ref:
WSDL and consume web service
consume non .NET webservice through WSDL file
How to use a WSDL
My team and I have a asp.net web forms application and are using several class libraries. In one of those libraries, we are trying to consume a web service. The web reference was added in the web app project and the appropriate references have been added. The app compiles. When attempting to consume said web service in the class library, the credentials don't seem to work, and the call fails. However, if we take the web service call out of the class library, and consume it within the web app, it works.
Any ideas why this is not working in the class library.
Double check your configuration file includes the correct information for the Web service.
Try changing the URL behavior to dynamic as well.
Also, as John stated, I'm assuming you're adding the service to the class library because you intend to use it from the library, as opposed to other areas of the Web application.
"the credentials don't seem to work, and the call fails"...can you give a small stack trace of the error?
Just to clarify, in my current project, we use WCF endpoints within a class library with bindings and credentials. The same can be done for a SOAP ASMX Web reference as you're attempting.
You can add a web service reference by doing the following steps:
right click on the project on the Solution Explorer
click Add Service Reference
click Advanced
you will find "Add Web Reference" at the end of the form
If you are adding the reference in application and then consuming it from class library... How you call the class library.. by adding reference and invoking the method of class library and then how you are accessing proxy from the class library you need to reference it... It seems to me a circular reference. Which shouldn't be compiled at first place... Are you describing your structure correctly???
It's always better to add a simple project with just web reference and then add the reference of this project on all the projects which requires it.
You can add a web service reference by doing the following steps:
right click on the project on the Solution Explorer
click Add Service Reference
click Advanced
you will find "Add Web Reference" at the end of the form
By #AMgdy 's solution,It'll auto generate a Reference.cs class.It defined all of method of webservices.
May be you called it wrong!!
Here is an example:
var serviceName = new ServiceName
{
Credentials = new NetworkCredential("Username", "Password", "Domain"),
Url = "Here you put the correct url of the web service if you published somewhere else"
};
serviceName.CallWebMethod();
make sure that you entered the correct Credential username and password and make sure the you published the webservice to a place you access it.
Have you defined any credential information in a config file in the web app? If so, the class library probably can't fetch them correctly. Just a guess though. And John Saunders is right. Seems a bit backwards reading your description of your apps structure.
I started learning web services. I learnt about web services, UDDI, WSDL, SOAP etc. and architecture of web services. Visual Studio is running the service in local system successfully.
Then I deployed the entire folder of that web service in IIS wwwroot, and tested. Its running successfully.
But when I remove the other file from the wwwroot\webService1 folder (I left only service1.asmx and bin folder) then also service is running.
Here I see that only two file are used in ruuning the webservice one is .asmx and another one is webService.dll in bin folder.
I'm not able to understand where is SOAP, WSDL, namespace or other things, that are required to run web service.
Please clarify.
SOAP, WSDL, Namespace are all handled by IIS and ASP.NET. In your scenario, your web service endpoint is your asmx file (no .cs file required in your deployment), and the DLL in the bin folder contains the code that you wrote for your webservice (so it does something).
If you call up your webservice in a web browser, you should see your web methods listed out to test. IIS knows how to process *.asmx files to do this. If you click on one, you should see a sample form (if input parameters are expected) and a button. Again, IIS knows how to serve this out to you. When you click the button, IIS and ASP.NET handle the work of SOAPing your request, handling it with your code, and SOAPing the response back to you.
If you create a "test" project in Visual Studio, and set a web service reference that points to your deployed web service, Visual Studio will create a proxy class and pull in some additional code from it's discovery of the service. Try it. You should get at least: a WSDL which defines your web service, a file called reference.cs which contains the code that does the heavy lifting of calling your webservice (SOAPing the request from your application and unSOAPing from the response).
If you download a tool called Fiddler, you should be able to intercept and inspect the SOAP call to your web service.
Take a look at Web Services with ASP.NET for additional information.
There are no such 'files' at all. The asmx and dll files contain all of the code for the service. You can see some of that in the URLs that are requested for the SOAP/WSDL info.
I believe if you append ?WSDL after .asmx you will see the definitions.
Such as this example:
WSDL Example
I think these are protocols and does not require anything. IIS and the requesting applications understand these protocols.
I just hit a huge brick wall with Paypal. I had created a regular C# project to create some wrapper classes using their WSDL.
If you create a non-web project, the only option you get to add a wsdl is a Web Service Reference. And this builds kinda the same set of proxy classes as a Web Reference would but not really..it adds more that even the PayPal guys are not aware of.
So I was this entire time looking for the right Interface in this list of proxy classes to use as the service (SoapBinding) and the PayPalAPIAASoapBinding was not there I kept telling our PayPal point in contact.
I could only see the following 2 Interfaces that appeared to me what I needed to use since I did not see a PayPalAPIAASoapBinding which you CAN see in a Web Reference based service reference:
PayPalAPIAAInterfaceClient
PayPalAPIInterfaceClient
So I figured out oh, I probably had created a Service Reference vs. a Web Reference which Web Reference is an option in a Web project. But I don't want my service reference tightly coupled to my web project. So that's why I created the C# Project.
So what the heck is a Service Reference vs. Web Reference? And how am I supposed to separate this out into anther project if Service Reference is going to throw me a loop and give me a set of different interfaces than a Web Reference would?
Also, to make things even MORE confusing, VS 2008 has a Web Service Application project.
So what do I use? We're using the .NET 3.5 framework and we're not ready to move to WCF. So can I still use the new Service Reference even if not using WCF or what? IF you're using .NET 3.5 and not WCF yet and you still want to do basic web services, do you still go the Service Reference route and just not use the WCF framework? Meaning can it be used like a .NET 2.0 Web Reference still, just that you're going to get an entirely different generation of the WSDL?
Add Web Reference is the old-style, deprecated ASP.NET webservices (ASMX) technology (using only the XmlSerializer for your stuff) - if you do this, you get an ASMX client for an ASMX web service. You can do this in just about any project (Web App, Web Site, Console App, Winforms - you name it).
Add Service Reference is the new way of doing it, adding a WCF service reference, which gives you a much more advanced, much more flexible service model than just plain old ASMX stuff.
Since you're not ready to move to WCF, you can also still add the old-style web reference, if you really must: when you do a "Add Service Reference", on the dialog that comes up, click on the [Advanced] button in the button left corner:
and on the next dialog that comes up, pick the [Add Web Reference] button at the bottom.
If I understand your question right:
To add a .net 2.0 Web Service Reference instead of a WCF Service Reference, right-click on your project and click 'Add Service Reference.'
Then click "Advanced.." at the bottom left of the dialog.
Then click "Add Web Reference.." on the bottom left of the next dialog.
Now you can add a regular SOAP web reference like you are looking for.
Adding a service reference allows you to create a WCF client, which can be used to talk to a regular web service provided you use the appropriate binding. Adding a web reference will allow you to create only a web service (i.e., SOAP) reference.
If you are absolutely certain you are not ready for WCF (really don't know why) then you should create a regular web service reference.
In the end, both do the same thing. There are some differences in code: Web Services doesn't add a Root namespace of project, but Service Reference adds service classes to the namespace of the project. The ServiceSoapClient class gets a different naming, which is not important. In working with TFS I'd rather use Service Reference because it works better with source control. Both work with SOAP protocols.
I find it better to use the Service Reference because it is new and will thus be better maintained.