WCF Service Library Won't Accept System.Web Reference - asp.net

I have a WCF project service library that is receiving an encrypted username and password. I need to encrypt my response back to the requested user. I created a separate service library and add the encryption methods in it. Because I am using System.Web.HttpUtility.UrlEncode(EncryptUser(key, user),
Encoding.GetEncoding("utf-8")), I need to add a reference to System.Web dll. However, adding the reference to System.Web causes an issue with the WCF Service. Every time I compile, it says that the reference to USER.dll is not found. If I remove the reference to system.web dll, the WCF Service is not complaining, but I am getting a message "HttpUtility does not exist in the other project are you missing a reference?"
How do I get around this given it is specified in the requirement that I use System.Web.HttpUtility.UrlEncode?

The issue is fixed after going to the WCF project's property and change the target Framework to .NET Framework 4.

Related

Is there a way to call a webservice whose asmx file is deleted?

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.

Using a WCF Reference in a DLL used by Classic ASP

I created a .NET DLL library which is COM-visible for the Classic ASP to use. I referenced a WCF service in the library and whenever I try to call the DLL from the classic ASP, I receive the following error:
Could not find default endpoint element that references contract 'ContractName' in the ServiceModel client configuration section. This might be because no configuration file was found for your application, or because no endpoint element matching this contract could be found in the client element.
Now, I set the reference to be internal access level. I noticed that VS created a DLL.config file with the service endpoint information, so I put the config file in the assembly folder for this DLL, but no luck.
Any idea how to use WCF endpoint reference?
SOLVED
All I needed to do is to create a BasicHTTPBinding and provide an endpoint address on the fly.Then create a new instance of the web service using the created binding and endpoint address.

Why is a Service Reference required in web application in addition to the class library that uses the service?

I am intending to provide access to a web service for an ASP.NET web application through a class library, and have been experimenting with a simple weather service.
In case it makes a difference I am using Visual Web Developer 2010 Express.
The interface between the web application and the class library is a simple string passed and string returned to a single method of a single class e.g.
String forecast = LibClassInstance.GetForecast("Madrid");
I added the Service Reference to the class library using AddServiceReference and created my call to the service through the automatically generated proxy classes. So far so good.
I then went to call my simple GetForecast method from my web application and got a long error message to the effect that the service might not have been configured in my project's Web.config file. After adding the Service Reference to my application project as well, it all worked as expected. I was hoping that the service behind the class library code would be hidden from its clients.
Can anyone tell me why it was necessary for me to add a service reference to the web application as well as the class library in order to get it working?
Can anyone tell me why it was necessary for me to add a service reference to the web application as well as the class library in order to get it working?
It isn't necessary. But you do need to configure the service in Web.Config - as a starting point you can copy the system.serviceModel section that was generated in the app.config of your class library when you added the Service Reference.

WCF using it's own web.config

I have a MVC3 app that is calling a WCF Service Application. The WCF Service App has its own web.config file (comes when you create the project automatically). In this .config I added an appSetting section with key to retrieve.
When I run the MVC app and it calls the WCF svc and the svc cannot see this appsettings value. If I move the appSettings section over to the MVC web.config the service application sees the value.
I would expect this from a calling application if it were a Winform or client based application calling a DLL but not where I have 2 separate apps where I actually want separate configuration files.
For example, I want to configure unity in my web services to perform dependency injection. I don't want the calling web application to know or have to define these values. The service should have them.
The issue I had was with the Unity configuration in the MVC app. Originally I had been pointing at a class library for my services layer, I swapped this over to use WCF. When I did this I left in the old type registrations which unity resolved and caused it to look at the new WCF project (same namespaces/class names) as a class library instead of using the endpoints that I registered.
Ripped out those specific class registrations leaving just the interfaces and endpoints and it worked like a charm.

What are the ramifications of an unconfigured (but working) endpoint?

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.

Resources