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.
Related
I have an IIS server which runs an app containing several web services. There is a .asmx file for each web service. For some reason, I have to restrict the access to the web services so i have deleted some of the asmx files.
Now my question is, can a client still call all the web services even without the asmx file? (I haven't changed the code, just deleted the .asmx files)
You cannot use the code behind without an asmx file. IIS does not know which class to use for implementation of the service.
You need to recreate the asmx file. Their content is quite simple. It is just a single line like
<%# WebService Language="C#" CodeBehind="ASWBW_002.asmx.cs" Class="P0300_GUI.Interfaces.ASWBW_002" %>
All you need is the name of the implementing class including the namespace. Usually this is the File name and parts of the path.
The ASMX file serves as a binding between the contract and its implementation. The client upon hitting the ASMX, the corresponding IIS handler invokes the underlying class to get the methods to fire. Removing this binding renders the service unavailable.
For a proper solution, follow these:-
In general, you need to identify who all clients can access your web service. Once done, you need a mechanism to provide them the WSDL file so they can generate their proxy classes.
Once done, disable the WSDL discovery using steps Disable Service Help Page by removing the documentation protocol. Post this, no client can get the WSDL and hence any updates (even existing verified clients)
If you want to implement selective availability, you have to incorporate SOAP Header based security using WS-Security policy.
Please note that WS-* and ASMX technologies are now considered as legacy and are not supported by Microsoft. Please upgrade to WCF/WebAPI instead.
I'm wondering if it is okay to add a reference to a web service within the same project (web application), i.e. I'm adding a reference in the same project where the service is defined.
The reason for doing so is because
Hosting the service becomes easier (gets automatically hosted when hosting the web app).
Invoking the service is done dynamically, i.e. the service url is fetched (from db) at run time and methods on that particular service are invoked. (this is a web app which is hosted on many domains. each app knows the service url of other apps (urls stored in db). since I have a reference to the service, I can change the url at runtime by updating the Url of the proxy and invoke it.)
Also, I'm not sure if this is the way to go about it. I have seen a lot of people suggest using WCF instead of a web service, but I don't see how I could accomplish the same thing with WCF.
There is already a question regarding this on SO - Add Service Reference to WCF Service within Same Project, but i don't think it is valid for my situation.
If the service is already in your project, you can use it directly without requiring a web service proxy.
After all, Web services are for exposing your application functionality to the outside world and not to other parts of your system.
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 created a class library with two wcf services in them. When adding a wcf item it did not add a svc file.
Do I have to manually add them to my main web project?
How might I go about this?
If all you need is the actual .svc endpoint all you have to do is add a new WCF Service item. Delete the extra files that come with it (usually like IService1.cs) as well as the code behind (Service1.svc.cs).
Inside the .svc file should look something like this:
<%# ServiceHost
Language="C#"
Debug="true"
Service="Service.Service1"
CodeBehind="Service1.svc.cs" %>
Just remove the CodeBehind part and change the Service value to your own personal class. As long as your config is set up (.net 4.0 made this really simple to get working) you should be good to go!
Which version of .NET are you using? As of 4.0, the *.svc file is no longer needed for IIS-hosted WCF services.
As Bengel indicated, 4.0 has made configuring WCF services a lot easier, by providing default bindings and endpoints.
It's not clear in your question whether your web site is going to being hosting the WCF service, or simply using it (as a client), though since you're looking for the .svc file I'm leaning towards the former.
In WCF 3.5, you'll need to manually add a *.svc file as Bengel indicated in his answer. The easiest way to do this is to add a new text file, and change the extension yourself.
You'll also need to configure the binding(s) and endpoint(s) and all that other good stuff.
If you're using WCF 4.0, you don't need the *.svc file, and you can opt to use the default bindings/endpoints that WCF provides.
The service address is based on the base address of the host, and one default endpoint will be created for each unique binding/contract (so if you have two services running on NetTcp, you'll get 2 default endpoints, and if you have two services running on NetTcp and WsHttpBinding, you'll get 4 default endpoints).
You can specify values for a binding and still have it be the default binding by ommitting the name attribute.
There's a good writeup on all of this - A Developer's Introduction to Windows Communication Foundation 4 that goes into more detail with examples.
Long story short - if you're using WCF 4.0, you don't need the .svc file. If you're using WCF 3.5, you'll need to add the .svc file to your web site.
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