Develop Reference

WCF, error 405 on Windows 2016 but not on 2008

WCF service running under ASP.NET 4.52, Silverlight client. The app used to work when hosted on Windows 2008 R2. Now I've set it up on a Windows 2016 server, and the very first service call errors out with error 405 - method not allowed. The method here is POST. The error description goes:
405 - HTTP verb used to access this page is not allowed.
On the Windows 2008 based instance, it's POST also, but the back end has no problem with that. The service uses HTTPS with Windows auth.
The relevant Web.config bits are:
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="winAuthBasicHttpBinding" maxBufferPoolSize="2147483647" maxReceivedMessageSize="2147483647" maxBufferSize="2147483647">
<readerQuotas maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxDepth="2147483647" maxNameTableCharCount="2147483647" maxStringContentLength="2147483647"/>
<security mode="Transport">
<transport clientCredentialType="Ntlm"/>
</security>
</binding>
</basicHttpBinding>
</bindings>
<behaviors>
<serviceBehaviors>
<behavior name="Foo.Web.Services.FooBehavior">
<serviceMetadata httpsGetEnabled="true"/>
<serviceDebug includeExceptionDetailInFaults="true"/>
<dataContractSerializer maxItemsInObjectGraph="2147483647"/>
</behavior>
</serviceBehaviors>
</behaviors>
<services>
<service behaviorConfiguration="Foo.Web.Services.FooBehavior" name="Foo.Web.Services.FooService">
<endpoint address="" binding="basicHttpBinding" bindingConfiguration="winAuthBasicHttpBinding" contract="Foo.Web.Services.IFooService">
<identity>
<dns value="localhost"/>
</identity>
</endpoint>
</service>
</services>
</system.serviceModel>
The erroring method has no annotations other than [OperationContract]. The interface only has [ServiceContract]. The service class has:
[WcfErrorBehavior]
[WcfSilverlightFaultBehavior]
[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
It might be relevant that the method has no arguments; I believe more recent versions of WCF use GET for those. The app is quite old.
The error reproduces with a generic HTTP client, it's not specific to the Silverlight front-end.
Looks like a difference in machine-level WCF configuration between .NET versions. Less likely, it could be that a Windows component is missing on the Windows 2016 box.
EDIT: enabled request tracing, got something back. There's a notification EXECUTE_REQUEST_HANDLER sent to StaticFileModule. A WCF service is most definitely not a static file.

Anyway, I want to reply to this thread. it might be useful to whoever encountered a similar issue.
#Seva Alekseyev, as you mentioned, for hosting WCF service created by Webhttpbinding in IIS, and some other protocol, such as Nettcpbinding, we should enable some kinds of Windows features.
For NetTcpbinding, we also need to enable the below Windows feature.
Feel free to let me know if there is anything I can help with.

Under Server Manager, roles and features, "HTTP Activation" was missing in the WCF category. My second hunch was right. That said, the error is somewhat misleading, so I'll leave this question here for posterity's sake.

WCF TCP Shared Services Enable Service Fails to Start

In short, when I go to start the worker process service process, it fails and returns:
The CS.Connector.Protean service on Local Computer started and then
stopped. Some services stop automatically if they are not in use by
other services or programs
I remove the attribute portSharingEnabled="true" from the service model in the config file and then the worker process service starts and executes as expected. I then add the attribute back into the config and the worker process services won't start again. I have include the service model config at the bottom of this post.
The Net.TCP Sharing Service is running, so it should be intercepting the incoming net.TCP connection.
I have read this MSDN article, but I must be missing something somewhere.
Could it be do doe with the mex end point not using a port sharing binding? I tried adding a binding to the mex end point, but still no joy. :.(
Help! Thanks
<system.serviceModel>
<bindings>
<netTcpBinding>
<binding name="TCPSecure" portSharingEnabled="true">
<security mode="Message" />
</binding>
</netTcpBinding>
</bindings>
<services>
<service name="Protean.Connector.ProteanConnector">
<endpoint address="" binding="netTcpBinding" bindingConfiguration="TCPSecure" contract="Protean.Connector.IProteanConnector"></endpoint>
<endpoint address="mex" binding="mexTcpBinding" contract="IMetadataExchange" />
<host>
<baseAddresses>
<add baseAddress="net.tcp://10.1.2.124:60000/ProteanConnector" />
</baseAddresses>
</host>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="">
<serviceMetadata httpGetEnabled="false" />
<serviceDebug includeExceptionDetailInFaults="false" />
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
Update!
I started off with a working service and confirmed this by a test.
I added the attribute port sharing and the service failed to start.
I removed the mex end point and the service ran successfully. An application that had a established connection was able to use the service successfully.
I added the mex back in with a reference to a binding that only had port sharing enabled and the service fail to start.
I need the mex to make the service discoverable to the IDE Visual Studios.
I suppose that the question now is, how does the end point, for the metadata exchange, work along with the port sharing attribute?
Update 2
MSDN Social Webpage Link
This forum tells me to change the mex binding from mexTcpBinding to netTcpBinging. I did and the service ran, but I am unable to discover the service now in the IDE.
Is this the correct solution path? The journey continues.
I'm starting to think the deeper I dig the more likely it will be that I stumble upon some government conspiracy. #HumourInDarkTimes #StrangerThings ;)

Solution
var type = typeof(LoggingManager);
using (var host = new ServiceHost(type))
{
/*
* Work-around to the conflict between global port sharing and local port sharing
* caused by Net.Tcp Sharing Serivces and the default port exclusivity (hogging) of Metadata Exchange binding.
*/
var mexBinding = new CustomBinding(MetadataExchangeBindings.CreateMexTcpBinding());
mexBinding.Elements.Find<TcpTransportBindingElement>().PortSharingEnabled = true;
host.AddServiceEndpoint(typeof(IMetadataExchange), mexBinding, "mex");
host.Open();
Console.WriteLine("Service started. Press [Enter] to exit.");
Console.ReadLine();
host.Close();
}
Description of Solution
I read a number of articles that suggests a solution through swapping the binding mexTcpBinding for netTCPBinding, I found that this did not work in my instance.
The above solution gets the mexTCPBinding and adds to it the attribute PortSharingEnabled = true. This is used in creating a new endpoint code-matically and passed to the service host. Finally, I have removed the meta-exchange end point from the config and, hey-presto, it worked.
Useful Links
Article explaining fix
Similar question

WCF Service Unable to start debugging on the web server

I am having an issue debugging my WCF service when I set the WCF service to SSL Required in my local IIS. I am able to hit the URL correctly for my service under http/https but I cannot debug and step through the code. I received a popup box with the following text:
Unable to start debugging on the web server. The web server is not configured correctly.
When I make the service not SSL Required I am able to step through my code as expected. I am new to dealing with IIS and have gone through a number of tutorials with the same result. Any help would be awesome
<system.serviceModel>
<behaviors>
<serviceBehaviors>
<behavior name="sslBehaviorConfiguration">
<!-- To avoid disclosing metadata information, set the values below to false before deployment -->
<serviceMetadata httpsGetEnabled="true"/>
</behavior>
</serviceBehaviors>
</behaviors>
<bindings>
<wsHttpBinding>
<binding name="sslBindingConfiguration">
<security mode="Transport" />
</binding>
</wsHttpBinding>
</bindings>
<services>
<service name="SslWCFProject.Service1" behaviorConfiguration="sslBehaviorConfiguration">
<endpoint binding="wsHttpBinding" bindingConfiguration="sslBindingConfiguration" contract="SslWCFProject.IService1" />
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
</service>
</services>
<!--<protocolMapping>
<add binding="wsHttpBinding" scheme="https"/>
</protocolMapping>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true"/>-->

1) First, I recommend checking the IIS logs. They are usually located in the following directory: C:\inetpub\logs\LogFiles. Just go into the W3SVC prefixed folder whose modification date most closely matches when you received the error. Open the log for the correct day and see the error details.
2) If that reveals nothing, then check out the Windows Application log in your Event Viewer.
3) Do you have a certificate (e.g. self signing certificate) on your computer? Is there a trusted site issue here?

I believe I found my answer. It looks like the checkbox in IIS for the website for Require SSL is associated the client certificate and requiring a client certificate to access the service instead of the section which is below it (although I will need to select required in the future). For the post I found When this is checked off I cannot debug the service but I can attach to the process in order to debug it.
http://blogs.msdn.com/b/vijaysk/archive/2007/10/18/visual-studio-debugging-websites-that-require-client-certificates.aspx
If I am wrong please let me know. If I come across anything else I'll update this question again with my progress just to keep in documented.

There was no endpoint listening at (url) that could accept the message

I'm building an ASP.NET website - it's a solution with a few projects, a data base and a web service. Everything worked fine, but last time I tried to run the project, I got the following error:
There was no endpoint listening at http://localhost:[number]/BooksWS.svc that could accept the
message. This is often caused by an incorrect address or SOAP action. See InnerException,
if present, for more details.
The inner exception says:
Unable to connect to the remote server
This error sort of came out of the blue, so I'm not sure what additional information I should provide. Does anyone have any idea why this could happen?
I suppose even a general answer could help, the only info I found about this error in the web concerned WCF.

go to webconfig page of your site, look for the tag endpoint, and check the port in the address attribute, maybe there was a change in the port number

Another case I just had - when the request size is bigger than the request size set in IIS as a limit, then you can get that error too.
Check the IIS request limit and increase it if it's lower than you need.
Here is how you can check and change the IIS request limit:
Open the IIS
Click your site and/or your mapped application
Click on Feature view and click Request Filtering
Click - Edit Feature Settings.
I just found also another thread in stack
IIS 7.5 hosted WCF service throws EndpointNotFoundException with 404 only for large requests

An another possible case is make sure that you have installed WCF Activation feature.
Go to Server Manager > Features > Add Features

I had this problem when I was trying to call a WCF service hosted in a new server from a windows application from my local. I was getting same error message and at end had this "No connection could be made because the target machine actively refused it 127.0.0.1:8888". I donot know whether I am wrong or correct but I feel whenever the server was getting request from my windows application it is routing to something else. So I did some reading and added below in Web.config of service host project. After that everything worked like a magic.
<system.net>
<defaultProxy enabled="false">
</defaultProxy>
</system.net>

Short answer but did you have Skype open? This interferes specifically with ASP.NET by default (and localhosts in general) using port:80.
In Windows: Go to Tools -> Options -> Advanced -> Connection and uncheck the box "use port 80 and 443 as alternatives for incoming connections".

Try this:
Delete the service instance.
Create a new instance of the service.
Sometimes the port is changed and generated error.

I tried a bunch of these ideas to get HTTPS working, but the key for me was adding the protocol mapping. Here's what my server config file looks like, this works for both HTTP and HTTPS client connections:
<system.serviceModel>
<protocolMapping>
<add scheme="https" binding="wsHttpBinding" bindingConfiguration="TransportSecurityBinding" />
</protocolMapping>
<services>
<service name="FeatureService" behaviorConfiguration="HttpsBehavior">
<endpoint address="soap" binding="wsHttpBinding" contract="MyServices.IFeature" bindingConfiguration="TransportSecurityBinding" />
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="HttpsBehavior">
<serviceMetadata httpGetEnabled="true" httpsGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="true" />
</behavior>
<behavior name="">
<serviceMetadata httpGetEnabled="true" httpsGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="false" />
</behavior>
</serviceBehaviors>
</behaviors>
<bindings>
<wsHttpBinding>
<binding name="TransportSecurityBinding" maxReceivedMessageSize="2147483647">
<security mode="Transport">
<transport clientCredentialType="None" />
</security>
</binding>
</wsHttpBinding>
</bindings>
<serviceHostingEnvironment multipleSiteBindingsEnabled="true" />
</system.serviceModel>

If you are using custom binding, please make sure that you are putting the same name for both custom binding (Server and Client)in config files
<bindings>
<customBinding>
<binding name="BufferedHttpServerNoAuth" closeTimeout="00:10:00" openTimeout="00:10:00" receiveTimeout="00:10:00" sendTimeout="00:10:00">
<gzipMessageEncoding innerMessageEncoding="textMessageEncoding" MaxArrayLength="10485760" MaxBytesPerRead="31457280" MaxStringContentLength="102400000" />
<httpsTransport hostNameComparisonMode="StrongWildcard" manualAddressing="False" maxReceivedMessageSize="31457280" authenticationScheme="Anonymous" bypassProxyOnLocal="True" realm="" useDefaultWebProxy="False" />
</binding>
</customBinding>
</bindings>
the binding name "BufferedHttpServerNoAuth" should be same in both.
Hope this would help someone

This is ancient history but I just ran into this issue and the fix for me was recycling the application pool of the website in IIS. Easy fix, for once.

I changed my website and app bindings to a new port and it worked for me. This error might occur because the port the website uses is not available. Hence sometimes the problem is solved by simply restarting the machine
-Edit-
Alternative (and easier) solution:reference
Get PID of process which is using the port
CMD command-
netstat -aon | findstr 0.0:80
Use the PID to get process name -
tasklist /FI "PID eq "
Open task manager, find this process and stop it.
(Note- Make sure you do not stop Net.tcp services)

I solved it by passing the binding with endpoint.
"http://abcd.net/SampleFileService.svc/basicHttpWSSecurity"

Click on Service which you have created right click on it then select update references after this rebuild the application it will work

WCF streamed response failing on large data

I'm currently experiencing an issue using WCF streaming to return a large set of serialized objects over the internet while hosted through IIS. I'm not sure if it is a network issue or a WCF issue, but the symptoms are hard for me to justify as network issues, as I'll describe below.
The objects are a variety of different objects sent over the one stream, most of which are small but there are also jpegs in there which range from 10k->500k per object. The different cases that I can't really reconcile are:
If we run it over our internal network it works perfectly, even if we increase the data transferred 10-fold higher than the real case so we're sending gigabytes of data.
If we run it on the servers hosting the solution we get an error (detailed below) after a few minutes and a few hundred megabytes transferred.
If we run it on the servers but remove the photos (Sending only the other data) it succeeds and sends roughly 40mb over a longer time period than the failure takes (The longer time is because it takes longer to process the other data, so that's expected).
We have tested simply downloading a 1GB file off the webserver (Significantly more than any of the tests other than the ones we tried on our local network) and it succeeded multiple times without issue.
The error we receive client-side is (Note: We went nowhere near the 3 hour timeout we have set):
System.Reflection.TargetInvocationException: An exception occurred during the operation, making the result invalid. Check InnerException for exception details. --->
System.ServiceModel.CommunicationException: The socket connection was aborted. This could be caused by an error processing your message or a receive timeout being exceeded by the remote host, or an underlying network resource issue. Local socket timeout was '03:00:00'. --->
System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. --->
System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host
And server-side we see:
System.ServiceModel.CommunicationException,
System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 The remote host closed the connection. The error code is 0x80070016.
The WCF binding setup is (With a little anonymizing):
<system.serviceModel>
<serviceHostingEnvironment>
<baseAddressPrefixFilters>
<add prefix="http://anonymous"/>
</baseAddressPrefixFilters>
</serviceHostingEnvironment>
<bindings>
<basicHttpBinding>
<binding name="StreamedHttpBindingConfig" transferMode="StreamedResponse" maxReceivedMessageSize="2147483647" maxBufferSize="8388608" sendTimeout="01:00:00">
<readerQuotas maxStringContentLength="2147483647" maxArrayLength="2147483647"
maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" maxDepth="2147483647" />
<security mode="None" />
</binding>
</basicHttpBinding>
</bindings>
<services>
<service behaviorConfiguration="wsHttpBindingBehaviour" name="AnonymousName">
<endpoint address="" binding="basicHttpBinding" bindingConfiguration="StreamedHttpBindingConfig" name="wsHttpBinaryBindingEndpoint" contract="Service.IAnonymous" />
<endpoint address="mex" binding="mexHttpBinding" name="mexHttpBindingEndpoint" contract="IMetadataExchange" />
<host>
<baseAddresses>
<add baseAddress="http://anonymous/Service" />
</baseAddresses>
</host>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="wsHttpBindingBehaviour">
<serviceThrottling maxConcurrentCalls="160" maxConcurrentSessions="100" maxConcurrentInstances="100" />
<dataContractSerializer maxItemsInObjectGraph="2147483647"/>
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="true" />
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
And the service contract is (Method/param names changed to anonymize, but types the same):
System.ServiceModel.Channels.Message GetData(System.ServiceModel.Channels.Message request);
Which looks like a network issue to me, but I can't imagine why it would succeed on the longer time-period with smaller data if it was intermittent network issues and I can't see why downloading a large file would've been unaffected if this was the case. Does anyone know a potential cause for this, or any idea what the next step of diagnosing it is?

CommunicationException is genericized and does not reveal the underlying exception. In the future, when reporting errors, I'd recommend turning on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the configuration behavior) on the server in order to send the exception information back to the client, and then report the nested exception you get in Detail.
For example:
<behaviors>
<serviceBehaviors>
<behavior
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="true" />
</behavior>
</serviceBehaviors>
</behaviors>
It's hard to tell from what is going wrong at all. Here is some more things I suggest, which I also suggested in another post:
Enable tracing on the service side and the client side, generate tracing logs, and analyze with SvcTraceViewer. To do this, follow the instructions at this MSDN article on using the service trace viewer.
Turn on debug exceptions. This is done by turning in includeExceptionDetailInFaults, which you can do by following the instructions here.
Use Fiddler to monitor the wire traffic on both the client side and the service side.
Generally, once you do this, you should plenty of more info on what's going funky at the service side and can diagnose the issue pretty quickly. Try it, and please report back! :)

I was looking for a solution for a very long time and added every configuration I found to increase the amount of data. what helped me eventually was this line under <behavior> tag in web.config that in server side:
<dataContractSerializer maxItemsInObjectGraph ="2147483647"/>
and making sure I have the same behavior in the client side.