While consuming a web service in my application I have two choices(ref. msdn)
Adding the Proxy Using the WSDL Tool
2.Adding the Proxy Using a Web Reference in Visual Studio
Now what should I choose, 2nd option is very simple and I generally follow that.
I want to know what are the pros and cons of both the options(if any) and ideally what should I choose?
Thanks.
They essentially achieve the same thing. The second gets the WSDL from the web service and generates the proxy, which requires the service to be online at the time.
Add the reference automaticly when possible, Visual Studio will do everything for you.
Under certain scenarios this is not possible. so you will have to do some manual work, like running the command to generate the proxy class and copying some configuration lines into the web.config manually.
Related
I have a small routine that programmatically builds an XML file that resides in memory based on a dataset that I send to the routine (it's called CreateAdXML()).
My buddy says I should turn it into a 'webservice', but I'm not quite sure what he means or how to do that. Can someone offer me some pointers? Is it relatively easy to take existing code for an asp.net site and turn it into a webservice?
There are many possibilities to create web services for an ASP.NET application. It all comes down to what you actually need:
If you need secure connections, advanced serialization, WSDL support etc...
Go for WCF (http://en.wikipedia.org/wiki/Windows_Communication_Foundation)
MSDN : http://msdn.microsoft.com/en-us/library/vstudio/ms735119(v=vs.90).aspx
If you only to expose a few methods:
Go for WebMethods (that's deprecated + quick and dirty in my opinion)
WebMethod tutorial: http://msdn.microsoft.com/en-us/library/byxd99hx(v=vs.90).aspx
If you need to expose data through a standardized interface, interoperable and bandwith-friendly service (that's called REST):
Go for Web APIs
Official page: http://www.asp.net/web-api
There also a lot of webservices frameworks available on codeplex, do some research to see if one suits your need better. A few well known are RestSharp and ServiceStack.
My advice:
From what you described, I would go with WebMethods for test purposes only. Once you know more about the client that will consume you web service, chose one of the apropriate framework.
If however you need to expose more methods, you should consider using Web APIs or WCF from the start, since these are much cleaner web service frameworks. It will also make you service stack MUCH easier to maintain.
It sounds to me more like you need to make it a utility method instead of a web service, as this will allow all of your web project to use this functionality, but not necessarily expose it beyond the boundaries of your application.
If you insist on making it a web service, then read A Beginner's Tutorial for Understanding Windows Communication Foundation (WCF).
It is fairly easy to create web services from ASP.NET code (VB.NET/C# etc..)
You can use the following link to help you understand more about ASP.NET Web Services.
http://msdn.microsoft.com/en-us/library/t745kdsh(v=vs.90).aspx
HOW TO: Write a Simple Web Service by Using Visual C# .NET
But all of the other answers are good too.
Since 2011sp1 Tridion comes with a precompiled core service client. Would there still be a reason to generate your own proxy by adding a service reference? Or is that older method officially deprecated now?
Let's take a look at advantages of compiled dll vs service reference:
Core service is growing and it's quite a problem to generate service reference reference on slower network. The bigger core service will be the harder it will be to generate service reference (there are workarounds of course)
Compiled dll is compiled using "correct" settings. There are some options you can set when generating service reference, like return types and types to be reused from other assemblies. By using compiled dll you are sure that you get everything right.
You can get quite a mess with you app.config when updating service reference. I think updating dll and config is a bit easier.
It's tricky to generate service reference when you have LDAP or SSO or HTTPs configured
The precompiled coreservice client is distributed by default to help implementers. As generating the own proxy is bit difficult (you might need to change some config in svcutil).
The precompiled coreservice client always uses the latest endpoint. Depending upon your situation you might need to generate your own proxy if you want to connect with the old endpoint always.
Otherwise you can use the precompiled client which will make sure you are connecting to the latest endpoint but that might break your client (you might need to fix something or recompile).
I have a Web service currently in an ASMX file.
I want to move this code into its own class library project which generates a DLL. I want to be able to drop this DLL into any Web application and have it work.
However, without an ASMX file, I have no URL endpoint. How do I get around this?
Essentially, I want to run a Web service without having to distribute an ASMX. I just want to distribute a DLL. Can I map the endpoint for the Web service in the web.config, or something?
(I think that perhaps WCF might do this, but one look at the config for that, and it feels like the cure is worse than the disease...)
If I understand your question correctly - the short answer is no - you can't turn a web service into a dll.
An .asmx file is essentially a page that has to be served by IIS in order to work.
Although you might experiment with embedding it as a resource and using HttpHandlers to route the request. But in the end that wouldn't really be an asmx service (see this link).
Now, your .dll can CALL a webservice and can have the url configured for the calling of that service in the web.config or app.config whichever you need, but the service itself can't be wrapped up in a dll.
What WCF does is allow you to create a service library, but it still has to be hosted to be publicly available however you can access it as if it were a dll locally by self hosting it.
Here is a sneaky way of getting it that actuall has the app WRITE the webservice if it does not exist - pretty tricky...
Embed ASMX in DLL (sort of)
Would hosting your service in a Windows Service resolve you problem? http://msdn.microsoft.com/en-us/library/Aa529311.aspx
__Allan
I have a fully functional wcf service where I can perform CRUD operations using jQuery on the client. I want this small service application to be portable so I am trying to avoid any app or web.config settings (e.g. Specific address endpoints). I have compiled my service application into a small dll file and have tried it in several different projects hosted at various web addresses. Everything works fine.
The only setting I put in the web.config file was for aspNetCompatibilityEnabled because I am using forms authentication. I did not define a name or a namespace for my service contract and my app.config file is empty sans a connectionstring. When I type in the address to my .svc file I get the 'endpoint not found error'. However my service is fully functional when I use the UriTemplates I defined in my operation contracts. What are the ramifications of this?
I don't care about exposing my data objects or methods on the .svc file. I just need this service to be portable and not blow up due to some unforeseen error.
Cautiously optimistic.
UPDATE
After further investigation it appears my example above is the default behavior for WCF. There is a good article from MS that explains it here.
I'm not sure what do you mean by portable. Your service is in dll, which can be used in any web application. Then it depends on your version of .NET Framework.
In .NET 3.5 you have to host the service in .svc file and configure it (service, endpoints, behaviors, AspNetCompatibility) in configuration file or in code.
In .NET 4.0 you can take advantage of simplyfied configuration model which can create endpoints for you based on other provided information. You can host the service in .svc file, by configuration based activation or by service route. In all cases it is important to use WebServiceHostFactory to allow automatic creation of endpoint using WebHttpBinding. You only need to configure AspNetCompatibility. If you need to futher specify webHttp behavior you can place it also in configuration without specifying behavior's name. Such behavior will be taken as default for all services (also not possible in .NET 3.5).
In neither case you don't need to configure base address because it is always taken from hosting web application.
First off, i'm fairly new to programming, I've built a few asmx web services but I am a little lost regarding how I should set up a WCF web service. I've tried to research this over the past couple days by reading through a lot of the documentation/articles/videos on MSDN but I'm still a confused.
Since my current web services are hosted on a separate box using IIS, from what I understand I need to create a WCF Library, then reference the Library in another WCF App and then host that app in IIS and reference the WCF App from my Front End? Seems like an extra step to me...? Not to mention a pain when developing on my local box.
Any advice or a point in the right direction would be very much appreciated. Thanks!
WCF gives you the option of sharing common assemblies (i.e. so both your service and clients can use the same domain model library), but it's not a necessary step.
You can host a WCF service through ASP.NET, same as ASMX. The "WCF Service Application" project template in Visual Studio configures it this way by default - as a WCF service hosted in IIS.
For the most common scenarios, it's really no different from ASMX. You create a WCF Service application, deploy it to a web server, and add service references in client applications. The importer will automatically generate classes for you, so you don't need to reference any assembly. No extra steps.
If you haven't already, you really should have a look through Microsoft's Tutorial. You'll find the steps very similar to those for setting up an ASMX-based architecture.