WCF Error The ExtendedProtectionPolicy.PolicyEnforcement values do not match

Error Message :

==============

The extended protection settings configured on IIS do not match the settings configured on the transport.  The ExtendedProtectionPolicy.PolicyEnforcement values do not match.  IIS has a value of Never while the WCF Transport has a value of Always. 

Binding Configuration Used:

<bindings>
  <netTcpBinding>
     <binding name="mynet" sendTimeout="00:00:05" portSharingEnabled="true">
       <security mode="None" />
     </binding>
  </netTcpBinding><basicHttpBinding>
     <binding name="myBinding" maxReceivedMessageSize="2147483647">        
       <security mode="TransportCredentialOnly">
         <transport clientCredentialType="Windows">
           <extendedProtectionPolicy policyEnforcement="Always"/>
         </transport>
       </security>
     </binding>
  </basicHttpBinding>
</bindings>

Solution : Set site policy enforcement :
===============================

1. Go to IIS and then to your hosted service listed under Sites.
2. Then go to "Authentication" in the IIS  section group.

3. Enable Windows Authentication.

4. Select Windows Authentication and click on Advanced Settings from Action panel.

5. Then set the extended protection to "Required" and click OK.
6. Now recheck the service URL.

Configure WCF for IIS on Windows 8

I have encountered with this issue when I was trying to deploy a WCF service on a fresh Windows 8.1 machine.

My next action was to try registering ASP.Net applications for IIS using ASP.Net IIS Registration tool (aspnet_regiis -i) as all the IIS default components have been already installed and functioning.

I've installed the below options in .Net Framework 4.5 Advanced Services from the Windows Features (as described in this msdn blog) and my WCF service got up and running.

If you are a console lover, you can use these commands in command prompt to enable the HTTP Activation.

Ref : Stack Overflow Post

C:\> DISM /Online /Enable-Feature /FeatureName:WCF-HTTP-Activation
C:\> DISM /Online /Enable-Feature /FeatureName:WCF-HTTP-Activation45

Type Sharing Issue with Multiple WCF Service References

I've encountered with a strange issue where the WCF test client could not generate the WSDL for the WCF service. No solutions have been available when googling with the error message we've got. So I split the service contract into three separate services depending on their functionality of them with the intention of adding them as 3 separate service references.

Then I've added the 3 service references to the front-end projects with the type-sharing option. But still had to re-factor a considerable number of lines of codes as the previous service client splits into 3 now. I've opened the files (except the xsds) generated by the service reference, then found this interesting behaviour in a file called "Reference.svcmap"

I've listed all my other mex endpoints as below and incremented the souceId, then I've regenerated the service reference.

Bingo..... Now using the ServiceAClient object I could invoke all the service methods available in ServiceB, ServiceC and ServiceD.

WCF (Windows Communication Foundation) First Step

Prerequisite : Microsoft Visual Studio 2010 (.net 4.0)

The purpose of this WCF article is to give a basic idea about how to create a simple WCF service.

To begin this tutorial, First, open up Visual Studio 2010 and create an empty Visual Studio solution. In My case, "WCF All in One Place".

Then add a WCF Service Library Project as Follows.

Now, There should be 3 files appear in the WCFServiceLibray project. The basic purpose of those files is as follows.
- Service.cs : Contains the service implement ion code
- IService.cs : Contains the service contract/ Service Interface class
- App.config : Contains the service configurations


You should be able to build and run the solution. If you do, the WCF Test Client should automatically host your WCF service and show what are the methods in your service and will give you a chance to play with those methods. If you have noticed your service metadata is exposed via the following mex end point.

 "http://localhost:8732/Design_Time_Addresses/WcfServiceLibrary/Service1/mex" 

"The metadata that the mex endpoint exposes describes the service, the various operations it has, parameters the operations require, and the return types. In other words, the metadata exposes the contract. With this information, the client can create a proxy to interact with the service. Clients use the mex endpoint to access the metadata."

Let's customize the project as we need. I suggest you to detached (decouple) the Service from its service contact, since I'm going to deploy this solution in several ways.

So first add another class library project to the solution called "ServiceContract" and delete the automatically create class1.cs.

Then add a new Interface class called "IServiceContratc.cs" to the ServiceContract project and place the following code inside the interface class.

Then delete the IService1.cs and Service1.cs classes from the WcfServiceLibrary project and add a new class called SampleService.cs to the same project and place the following code.

 

 Change the following attributes in the app.config file located in the WcfServiceLibrary project as follows.

- service name="WcfServiceLibrary.SampleService"

- baseAddress = "http://localhost:8732/WcfServiceLibrary/SampleService/"

- contract="ServiceContract.IServiceContract"

Debug the WcfServiceLibrary project, and the WCF Test Client window should list your new methods. Click on the .. method and enter the two values for the required two parameters.

and click on the invoke button. A pop-up dialogue box may appear and click OK after clicking on the tick (Don't show this....).  Then observe the Response.

Click on the XML tab located in the bottom center of the window and observe the request message sent by the WCF Test Client.

Password is in the plain sight !!. This is why you are required to think of securing your WCF services.