So, as expected, this turned out to be a version conflict in the default handler mappings in ApplicationHost.config. In particular, IIS has mappings for ASP.NET 2.0 and specific ASP.NET 4.0 links for the service activation processor (and module), and 2.0 links were not limited to the pre-confidential version.
To fix this problem, I had to change (in the root of the system in ApplicationHost.config):
<add name="svc-Integrated" path="*.svc" verb="*" type="System.ServiceModel.Activation.HttpHandler, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" preCondition="integratedMode" />
in
<add name="svc-Integrated" path="*.svc" verb="*" type="System.ServiceModel.Activation.HttpHandler, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" preCondition="integratedMode,runtimeVersionv2.0" />
Pay attention to EXPLICIT runtimeVersion2.0. There are additional * .svc cards in the same section for runtimeVersion4.0, which then run at appropriate intervals.
According to Microsoft, this situation can occur when some old tools are installed (am I guessing Azure tools?) That do not register the execution version properly.
The problem is resolved.
Rick strahl
source share