<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <startup>
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
  </startup>

    <appSettings>

<add key="System:Xml:Serialization:UseLegacySerializerGeneration" value="true" />

    </appSettings>

</configuration> 

This is equivalent to the compat switch described in this KB article. However the above appSetting based switch is recommended. The compat switch described in this KB article is not compatible on a machine with .NET 4.0 runtime. As application will fail to load due to a configuration exception. The above appSetting based switch is compatible on both runtimes.

• Check if your IIS application pool is in Integrated mode. Note: Running of an OWIN middleware is supported only on IIS Integrated pipeline. Classic pool is not supported. 
• Check if you have Microsoft.Owin.Host.SystemWeb Nuget package installed. This package is required for the OWIN startup class detection.
• [Learnt from comments - Thanks @Eric]: If your Startup class is still not detected in IIS, try it again by clearing the ASP.net temporary files. 

System.IO.FileLoadException: Could not load file or assembly 'Microsoft.Owin, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

Reason for the failure:

This is a known issue with Nuget client: Refer this bug. Binding redirects not getting added automatically for worker role projects. The reason for this failure is SignalR/WebAPI binaries are built with a dependency over Microsoft.Owin version 2.0.0. But the latest available version of Microsoft.Owin in the public feed is > 2.0.0. To fix this assembly binding issue when you install the same SignalR/WebAPI packages on a console application or a web application you will see assembly binding redirects being automatically added for you in the app.config by Nuget client. Due to an issue with Nuget client this is not happening in case of worker role projects.

Fix for this issue:

To fix this issue add this to your worker role project's app.config (Alternatively try adding your signalR package to a console app and copy paste the binding redirects from its app.config):

<configuration>
 <runtime>
 <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
 <dependentAssembly>
 <assemblyIdentity name="Microsoft.Owin" publicKeyToken="31bf3856ad364e35" culture="neutral" />
 <bindingRedirect oldVersion="0.0.0.0-2.0.2.0" newVersion="2.0.2.0" />
 </dependentAssembly>
 <dependentAssembly>
 <assemblyIdentity name="Microsoft.Owin.Security" publicKeyToken="31bf3856ad364e35" culture="neutral" />
 <bindingRedirect oldVersion="0.0.0.0-2.0.2.0" newVersion="2.0.2.0" />
 </dependentAssembly>
 </assemblyBinding>
 </runtime>
 </configuration>

Do you notice that your WCF NetTcp endpoint sharing port with a mexTcp endpoint fails to activate with a AddressAlreadyInUseException on upgrade to .Net 4.5?

System.ServiceModel.AddressAlreadyInUseException: There is already a listener on IP endpoint 0.0.0.0:[Port#]. This could happen if there is another application already listening on this endpoint or if you have multiple service endpoints in your service host with the same IP endpoint but with incompatible binding configurations. --->

System.Net.Sockets.SocketException: Only one usage of each socket address (protocol/network address/port) is normally permitted at System.Net.Sockets.Socket.DoBind(EndPoint endPointSnapshot, SocketAddress socketAddress) at

…

Here are some pointers for you to get it fixed.

• Check if you have explicitly configured listenBackLog or maxConnections property of the NetTcp binding to a .Net 4.0 default of 10 like this:

<netTcpBinding><binding listenBacklog="10" maxConnections="10">…

• If so delete these explicitly defined settings on the NetTcp binding and restart the service.

Does that resolve your problem? Here is a little bit background about the problem. There are some limitations when it comes to port sharing for TCP endpoints which are documented here under the section "Sharing a port between a service endpoint and a mex endpoint using the NetTcpBinding". If you are sharing port between two TCP endpoints these listenBackLog & maxConnections parameters used by both the endpoints should be the same. If they are different you will run into this issue.

Now, why does that work on .Net 4.0 but not on .Net 4.5?

In .Net 4.0 defaults for these properties are 10. Since the configured values match with the mexTcpEndpoint’s default values it works fine on .Net 4.0

On the other hand, in .Net 4.5 the revised defaults for these properties = 12 * ProcessorCount. Since the configured values (10) does not match with the mexTcpEndpoint’s default values of 12 * ProcessorCount it throws this exception.

If you notice, the 4.5 defaults for these values are definitely higher than 4.0 defaults. So by removing the explicitly configured properties your service will start working fine. Alternatively you can expose the mex endpoint on a different port as described in this post.

“This method or property is not supported after HttpRequest.GetBufferlessInputStream has been invoked.”

If you had a WCF 4.0 app which worked perfectly but on upgrading your .net framework to 4.5 you notice the service failing on accessing this property, here is the way to work-around the issue:

1. Add a simple HttpModule in the same WCF project which will access the InputStream property for each request before WCF reads it so that it will enforce the HttpContext.Request.ReadEntityBody to be "Classic" and will ensure compatibility. 

public class WcfReadEntityBodyModeWorkaroundModule : IHttpModule

    {

        public void Dispose()

        { 

        }

         public void Init(HttpApplication context)

        {

            context.BeginRequest += context_BeginRequest;

        }

         void context_BeginRequest(object sender, EventArgs e)

        {

            //This will force the HttpContext.Request.ReadEntityBody to be "Classic" and will ensure compatibility..

            Stream stream = (sender as HttpApplication).Request.InputStream;

        }

 } 

2. Register this module in your web.config by adding these lines in <configuration><modules> setting.

 <system.webServer>

    <modules ...>

      <!-- Register the managed module -->

      <add name="WcfReadEntityBodyModeWorkaroundModule" type="MyAssembly.WcfReadEntityBodyModeWorkaroundModule, MyAssembly" />

    </modules>

…

<…

If your project cannot be modified, then you can write this Http module in a separate assembly, GAC it separately and register this module in the web.config.

Now try accessing the service it should succeed for you!

Note: This issue has been fixed with .net 4.5.1 update. To get the old behavior (4.0 behavior) back please apply the below compat switch in your web.config:

<configuration>  
  <appSettings>
    <add key="wcf:serviceHostingEnvironment:useClassicReadEntityBodyMode" value="true" />
  </appSettings>
</configuration>

What does that mean?

If you develop a WCF service (target framework 4.0 or 4.5) on a machine with .net framework 4.5 assuming these default values and deploy the same service:

• On a machine with .net framework 4.0 runtime: The service will get only .net framework 4.0 defaults which is lesser than 4.5 defaults. So scalability of the service will be reduced to what was supported in WCF 4.0.
• On a machine with .net framework 4.5 runtime: you should see no issues.

The service cannot be activated because it does not support ASP.NET compatibility. ASP.NET compatibility is enabled for this application. Turn off ASP.NET compatibility mode in the web.config or add the AspNetCompatibilityRequirements attribute to the service type with RequirementsMode setting as 'Allowed' or 'Required'.

Check if your service definition explicitly overriddes the default value of AspNetCompatibilityRequirements() attribute. If not explicitly annotate your service definition with [AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)] attribute like in v4.0.

The reason for this kind of a failure is due to defaults change of ASP.NET compatibility mode value in 4.5. When you set the aspNetCompabitilityEnabled=”true” in your web.config and without setting any compatibility setting on service
definition, then:

On machine with v4.5 runtime: Individual service definitions automatically gets RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed as the default. So your service will activate successfully.

On machine with v4.0 runtime: Individual service definitions automatically gets RequirementsMode = AspNetCompatibilityRequirementsMode.NotAllowed as the default. So your service will fail to activate with the above error.

As I mentioned before, you can solve this issue by explicitly overriding default value of AspNetCompatibilityRequirements attribute on individual service definitions to avoid v4.0 defaults to kick in.

Here is what you can do about it:

Check if your error tab shows some error like...

Warning     1                 Custom tool warning: Cannot import wsdl:portType

Detail: An exception was thrown while running a WSDL import extension: System.ServiceModel.Description.DataContractSerializerMessageContractImporter

Error: Type 'Newtonsoft.Json.Linq.JToken' is a recursive collection data contract which is not supported. Consider modifying the definition of collection 'Newtonsoft.Json.Linq.JToken' to remove references to itself.

XPath to Error Source: //wsdl:definitions[@targetNamespace='https://tempuri.org/']/wsdl:portType[@name='IService1']

If so, you can use the following work around(s):

1. In add service reference dialog -> [Advanced ... ] -> Reuse types in referenced assemblies (Checked by default) -> Choose the non default 'Reuse types in specified referenced assemblies' radio -> Make sure you exclude Newtonsoft.Json.dll from the list. Try adding service reference now and see it succeeds.

2. Alternatively you can remove reference of this Newtonsoft.Json.dll while generating proxy and add that back after proxy generation is complete.

Configuration binding extension 'system.serviceModel/bindings/netHttpBinding' could not be found. Verify that this binding extension is properly registered in system.serviceModel/extensions/bindingExtensions and that it is spelled correctly.

OR

Configuration binding extension 'system.serviceModel/bindings/basicHttpsBinding' could not be found. Verify that this binding extension is properly registered in system.serviceModel/extensions/bindingExtensions and that it is spelled correctly.

OR

Configuration binding extension 'system.serviceModel/bindings/udpBinding' could not be found. Verify that this binding extension is properly registered in system.serviceModel/extensions/bindingExtensions and that it is spelled correctly.

If its web hosted, add this setting <httpRuntime targetFramework="4.5" /> to your web.config to solve the issue.

<system.web>

    <compilation debug="true" targetFramework="4.5" />

    <httpRuntime targetFramework="4.5"/>

  </system.web>

 If your app is self hosted, make sure you compile your project with targetFramework v4.5.

netHttpBinding, basicHttpsBinding and udpBinding work only in binaries built with target framework v4.5. Adding a httpRuntime setting to web.config will make sure that the IIS application pool created for your app has a version v4.5.