I've got a WCF service that's using file-less activation:
<bindings>
<basicHttpBinding>
<binding transferMode="Streamed">
<security mode="Transport"/>
</binding>
</basicHttpBinding>
</bindings>
<serviceHostingEnvironment multipleSiteBindingsEnabled="true">
<serviceActivations>
<add relativeAddress="RulesService.svc"
service="Big.Company.RulesService.Service, RulesService" />
</serviceActivations>
</serviceHostingEnvironment>
On some machines, I see the following exception:
Service
'Big.Company.RulesService.Service' has
zero application (non-infrastructure)
endpoints. This might be because no
configuration file was found for your
application, or because no service
element matching the service name
could be found in the configuration
file, or because no endpoints were
defined in the service element.
As far as I can tell, .svc is correctly mapped to the .NET 4.0 activation module. The application is in the "ASP.NET v4.0" application pool, which is configured for .NET v4.0, using the integrated pipeline.
If I remove the Web.config file, I get a 404 error. If I rename the bin\RulesService.dll file, I get a 'service not found' exception.
What's wrong with it?
Update: It appears to be a problem when turning on SSL. If I connect using HTTPS, it's fine, until I turn on 'Require SSL' in IIS.
An afternoon of using Reflector led me to the ConfigLoader.AddDefaultEndpoints method, which looks at the ProtocolMappingSection of the config file to work out which default endpoints to add.
It appears that HTTPS doesn't set up this section implicitly.
I solved it (with a hint from something I'd seen earlier in the day) by adding the following to my Web.config file:
<protocolMapping>
<add scheme="https" binding="basicHttpBinding"/>
<add scheme="http" binding="basicHttpBinding"/>
</protocolMapping>
I had only an HTTPS binding in IIS for my service and adding an http binding solved my problem. Without any file configuration.
(Sorry for the french screenshot
)
Adding the following to the config file and removing the http binding in IIS also solved my problem.
<protocolMapping>
<add scheme="https" binding="basicHttpBinding"/>
</protocolMapping>
I had the identical problem at work and it was a permissions issue.
Related
I've been working with silverlight application for over a month now, and have stumbled upon a weird issue.
I have a WCF service running in IIS, accessible from the URL :
https://xyztestname.com/service1.svc
I am able to consume this in visual studio and when deployed from visual studio, am able to get proper call backs from WCF service and everything works fine.
When i deploy the package files in to the same folder as the Service1.svc in IIS, the WCF service is not hitting properly.
Please help me resolve this issue :(! Here is my web.config file.
<?xml version="1.0"?>
<!--
For more information on how to configure your ASP.NET application, please visit
http://go.microsoft.com/fwlink/?LinkId=169433
-->
<configuration>
<system.web>
<compilation debug="true" targetFramework="4.0" />
<customErrors mode="Off"/>
</system.web>
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="BasicHttpEndpointBinding">
<security mode="TransportCredentialOnly">
<transport clientCredentialType="None" />
</security>
</binding>
</basicHttpBinding>
</bindings>
<services>
<service name="InformationService.Service1">
<endpoint address="" binding="basicHttpBinding" bindingConfiguration="BasicHttpEndpointBinding"
name="BasicHttpEndpoint" contract="InformationService.IService1">
</endpoint>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="">
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="false" />
</behavior>
</serviceBehaviors>
</behaviors>
<serviceHostingEnvironment multipleSiteBindingsEnabled="true" />
</system.serviceModel>
</configuration>
I dont know where i am going wrong. But the same Virtual folder when accessed through intranet works fine, but doesn't work when accessed through internet :( Please help.
Edit:
After checking into the client config, i found out that Visual studio automatically resolved the URL into an intranet URL. When i changed back to the internet URL, i am getting an exception thrown.
n error occurred while trying to make a request to URI 'https://xyztestname.com/Service1.svc'. This could be due to attempting to access a service in a cross-domain way without a proper cross-domain policy in place, or a policy that is unsuitable for SOAP services. You may need to contact the owner of the service to publish a cross-domain policy file and to ensure it allows SOAP-related HTTP headers to be sent. This error may also be caused by using internal types in the web service proxy without using the InternalsVisibleToAttribute attribute. Please see the inner exception for more details.
However, I have copied both the crossdomain and clientaccesspolicy files into the root of the application in IIS. :( Please help.
You have to deploy your application to the specific ip and port to be able to use it in internet.
I think you can.
To do this you need to edit applicationhost.config file manually (edit bindingInformation '::')
To start iisexpress, you need administrator privileges
1 – Bind your application to your public IP address
Normally when you run an application in IIS Express, it’s only accessible on http://localhost:[someport]. In order to access it from another machine, it needs to be bound to your public IP address as well. Open D:\Users[YourName]\Documents\IISExpress\config\applicationhost.config and find your site. You will find something like this:
<site name="YOUR PROJECT NAME HERE" id="2">
<application path="/">
<virtualDirectory path="/" physicalPath="YOUR PHYSICAL PATH HERE"
<binding protocol="http" bindingInformation="*:58938:localhost" />
</bindings>
</site>
In , add another row:
<binding protocol="http" bindingInformation="*:58938:192.168.1.42" />
(But with your IP, and port number, of course)
2 - Allow incoming connections
If you’re running Windows 7, pretty much all incoming connections are locked down, so you need to specifically allow incoming connections to your application. First, start an administrative command prompt. Second, run these commands, replacing 192.168.1.42:58938 with whatever IP and port you are using:
netsh http add urlacl url=http://192.168.1.42:58938/ user=everyone
This just tells http.sys that it’s ok to talk to this url.
netsh advfirewall firewall add rule name="IISExpressWeb" dir=in protocol=tcp localport=58938 profile=private remoteip=localsubnet action=allow
This adds a rule in the Windows Firewall, allowing incoming connections to port 58938 for computers on your local subnet.
And there you go, you can now press Ctrl-F5 in Visual Studio, and browse you site from another computer!
I have been googling everywhere I can possibly find (including here on Stackoverflow) to figure out an error I've got trying to deploy a WCF service to IIS 7.5 on Windows 7 x64 that runs only over SSL with basic HTTP authentication. I've got a site in IIS which has a binding to port 50443 for HTTPS with a self-signed cert. (I can't use the standard port 443, as we plan on deploying this to IIS on a server which is already running Tomcat which is listening on 80 and 443.)
This is the web.config:
<configuration>
<system.web>
<compilation debug="true" targetFramework="4.0" />
</system.web>
<system.serviceModel>
<behaviors>
<serviceBehaviors>
<behavior>
<serviceMetadata httpsGetEnabled="true"/>
<serviceDebug includeExceptionDetailInFaults="false"/>
</behavior>
</serviceBehaviors>
</behaviors>
<bindings>
<basicHttpBinding>
<binding name="SSLBinding">
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Basic"/>
</security>
</binding>
</basicHttpBinding>
</bindings>
<services>
<service name="HelloWorldWcf.HelloWorldWcfService">
<endpoint name="HelloWorldWcf.HelloWorldWcfService"
address="https://mylaptop:50443/HelloWorld/Service1.svc"
binding="basicHttpBinding"
bindingConfiguration="SSLBinding"
contract="HelloWorldWcf.IHelloWorldWcfService"/>
<endpoint address="https://mylaptop:50443/HelloWorld/Service1.svc/mex"
binding="mexHttpsBinding"
contract="IMetadataExchange"/>
</service>
</services>
</system.serviceModel>
<system.webServer>
<modules runAllManagedModulesForAllRequests="true"/>
</system.webServer>
</configuration>
If I browse to the service endpoint address and enter the basic authentication credentials manually, I get the following exception error message displayed in my browser:
The provided URI scheme 'https' is invalid; expected 'http'.
Parameter name: context.ListenUriBaseAddress
This is the same error I got trying to run a WCF client against a similar service, except that it ends with "Parameter name: via" (because the parameter name of the method that shows up in the call stack, "System.ServiceModel.Channels.TransportChannelFactory`1.ValidateScheme(URI via)", is in fact "via").
I've tweaked the server and client config files so many times I've lost track, but the web.config file above is my best guess so far--and it doesn't even work from a browser, much less a WCF client.
What do I need to do to access a WCF service hosted in IIS 7.5 on a nonstandard SSL port with basic HTTP authentication over HTTPS? Help! (& Thanks!)
try add this to binding
<security mode="Transport">
<transport clientCredentialType="None" proxyCredentialType="None" realm=""/>
<message clientCredentialType="Certificate" algorithmSuite="Default" />
</security>
Arrrrgh! Okay, the remaining steps to get it to work:
Replace my <security> node in the web.config with burning_LEGION's.
Eliminate the "mex" endpoint from the web.config. (This allowed me to get to the usual "You have created a service" friendly web page in my browser.)
Escaped the backslash in the "DOMAIN\username" string I was assigning to HelloWorldWcfServiceClient.ClientCredentials.UserName.UserName in the client C# code. (Did I say "arrrrgh!"? Man, is my face red.) This eliminated the error I got after steps 1 and 2:
System.ServiceModel.Security.MessageSecurityException: "The HTTP
request is unauthorized with client authentication scheme 'Basic'. The
authentication header received from the server was 'Basic
realm="mylaptop"'.---> System.Net.WebException: The remote server
returned an error: (401) Unauthorized.
I got the idea for step 2 from here which made me think mex was unhappy with HTTPS, and for step 3 from here where I noticed the user name was #"domain\username", not "domain\username".
+1 to burning_LEGION for the assist!
So, the unanswered questions: (1) why does the security/message node have any effect on a configuration that doesn't use message security (only transport security)? (2) what's the point of the mex endpoint if it just interferes with normal operation? (3) If mode="TransportCredentialOnly" doesn't work with HTTPS, why don't I get an error indicating this?
This is driving me nuts. I have a .net 4, wcf service that is outputting jsonp. It works using the built in web server with vs.net however if i try to host in iis7 on windows 7 64bit i don't get any response.
If I try to navigate to svc file while hosted in iis7 I get
"Security settings for this service require 'Anonymous' Authentication but it is not enabled for the IIS application that hosts this service."
If trying to access via client jquery jsonp request i don't get any response from the service being hosted in iis7
So, the configuration of the service (web.config) is fine when hosted within vs.net web server (just doesn't work with iis)
Here is the config
<system.serviceModel>
<behaviors>
<endpointBehaviors>
<behavior name="webHttpBehavior">
<webHttp />
</behavior>
</endpointBehaviors>
</behaviors>
<bindings>
<webHttpBinding>
<binding name="webHttpBindingWithJsonP" crossDomainScriptAccessEnabled="true" />
</webHttpBinding>
</bindings>
<services>
<service name="ServiceSite.CustomersService">
<endpoint address="" binding="webHttpBinding"
bindingConfiguration="webHttpBindingWithJsonP" contract="ServiceSite.CustomersService"
behaviorConfiguration="webHttpBehavior"/>
</service>
</services>
</system.serviceModel>
<system.web>
<compilation debug="true" targetFramework="4.0" />
</system.web>
<system.webServer>
<modules runAllManagedModulesForAllRequests="true"/>
</system.webServer>
The site must be ntlm/windows secured.
I added the following to the web.config bindings section
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Ntlm"/>
</security>
When browsing the svc file I now get Cross domain javascript callback is not supported in authenticated services
Really? Is this true jsonp is not supported?
This is probably symptomatic of misconfiguration of the web site. Go to Authntication feature of the website on the IIS Manager and make sure it is setup.
I'm pretty sure because of how JSONP cross domain works with today's shortcomings that you always have to implement your own custom security system.
I use SSL and HMAC security for JSONP cross domain authentication. I do the authentication myself on the service.
When doing JSONP you cannot set headers, or anything, on the request because it's done through adding tags, not an actual XMLHTTP request object.
Just to put some context.
ASP.NET MVC2
Web API 5
IIS 7
I am trying to use the WCF Web API and as soon as I enable HTTPS, it stop working.
Things I noticed:
My API call I do through jquery, and I have something like this as the url:
http://www.domain.com/api/serviceApi/SetForeignToken?token=ASDAS-ASDAS-ASDASD-ASDASDAS&foreignToken=AS123ASD
When I use the API test UI I through:
https://www.domain.com/api/serviceApi/Test
I see for the test url:
https://devserver.ad.domain.com/api/serviceapi/SetForeignToken?token=ASDAS-ASDAS-ASDASD-ASDASDAS&foreignToken=AS123ASD
It just seems od the it resolves the DNS to the machine name instead of keeping the normal DNS, as it did before without HTTPS.
Does anyone know how to configure the API to make this work unde HTTPS, or is it even possible?
Thanks,
PS. The Development Enviroment has a self-signed certificate while the production will have a real certificate.
Yes, WCF Web API supports HTTPS. I believe there are a couple of ways to do this (including a code option). I only wanted https enabled on one server so I did this in my web.config:
<system.serviceModel>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true">
<baseAddressPrefixFilters>
<add prefix="https://subdomain.example.com"/>
</baseAddressPrefixFilters>
</serviceHostingEnvironment>
<bindings>
<webHttpBinding>
<binding>
<security mode="Transport" />
</binding>
</webHttpBinding>
</bindings>
</system.serviceModel>
Thanks guys. spent whole day figuring out this. Just added the code in web.config and it worked.
I'm trying to get started with transactions in WCF, using the free Microsoft Visual Web Developer 2010 Express. It gives me the option to create a "WCF Service Application" but it doesn't appear to give me many options for hosting it or configuring different bindings. If I F5 the project I get the error:
At least one operation on the 'Service' contract is configured with the TransactionFlowAttribute attribute set to Mandatory but the channel's binding 'BasicHttpBinding' is not configured with a TransactionFlowBindingElement. The TransactionFlowAttribute attribute set to Mandatory cannot be used without a TransactionFlowBindingElement.
I've tried adding in */services/service/endpoint configuration into the web.config but it appears to just be ignored. I also tried to change the default startup application to WcfSvcHost.exe but this option is greyed out. I'm beginning to suspect the Express edition of some failings but am optimistic that it's just me being a dunce. Is there a trick I need to learn, or will splashing out on the full version of Visual Studio 2010 be enough to get me over this hurdle and onto the next one?
Thanks!
Without knowing your configuration and service contract it is almost impossible to make targeted answer. If you think that your configuration is ignored make sure that names used in service and endpoint/#contract contains CLR namespaces.
WCF 4 uses nice simplified configuration which IMHO made real configuration much bigger pain then it was before. You can switch defaults by adding this to your web config:
<protocolMapping>
<remove scheme="http" />
<add scheme="http" binding="wsHttpBinding" bindingConfiguration="transactionFlowEnabled"/>
</protocolMapping>
<bindings>
<wsHttpBinding>
<binding name="transactionFlowEnabled" transactionFlow="true" />
</wsHttpBinding>
</bindings>
This is workaround which should use defined binding as default instead of basicHttpBinding.
Thanks to Ladislav's suggestion, I was able to solve this by adding the following entries into the Web.config file:
<services>
<service name="WcfService1.Service1">
<endpoint
address=""
binding="wsHttpBinding"
contract="WcfService1.IService1"
/>
</service>
</services>
and:
<bindings>
<wsHttpBinding>
<binding transactionFlow="true"/>
</wsHttpBinding>
</bindings>