Using Visual Studio 2010 / .NET 4.0
I've been at this for hours but I'll try to be specific.
I'm deploying a WCF 4.0 Service to IIS 7. It works fine under http. I can add a service reference from Visual Studio against the WCF service and code against it no problem.
Of course the problem is that the service needs to run under https.
I've managed to manhandle the web.config file so it will run under https (at least I can see the .svc and ?wsdl display in the browser).
But of course IIS is returning the machine name, not the domain name throughout the wsdl.
So when I try to add the service reference I get somehting like this.
The document was understood, but it could not be processed.
- The WSDL document contains links that could not be resolved.
- There was an error downloading 'https://machinename/MyServiceName.svc?xsd=xsd0'.
- The remote name could not be resolved: 'machinename'
I know the problem is that IIS is not returning host headers so WCF is guessing and handing back the machine name.
Of course IIS7 won't allow me to add host headers to a site that is using SSL. I've Googled and seen others set host headers with using appcmd something like this
appcmd set site /site.name: /+bindings.[protocol='https',bindingInformation='*:443:']
Tried it and it tells me that the site has been modified
But instead of modifiying the existing SSL binding I get an additional binding that has a host name, but no certificate attached to it. Any attempt to select a SSL through the IIS UI wipes out the hostname. I'm using a wildcard certificate from GoDaddy
1) Anyone see this problem with appcmd? Have any ideas on how to solve.
2) Can I set the domain name in the webconfig. All my attempts to do so to date have produced various IIS Yellow Screens of Death complaining about one parameter or another. I include a copy for your entertainment and suggestions.
<services>
<service name ="NameThisService" behaviorConfiguration="TheDefaultBehaviour">
<endpoint address="" binding="wsHttpBinding" bindingConfiguration="webBinding" contract="IService" >
</endpoint>
</service>
</services>
<bindings>
<wsHttpBinding>
<binding name="webBinding">
<security mode="Transport">
<transport clientCredentialType="None"/>
</security>
</binding>
</wsHttpBinding>
</bindings >
<behaviors>
<serviceBehaviors>
<behavior name="TheDefaultBehaviour">
<!-- To avoid disclosing metadata information, set the value below to false and remove the metadata endpoint above before deployment -->
<serviceMetadata httpsGetEnabled="true" />
<!-- To receive exception details in faults for debugging purposes, set the value below to true. Set to false before deployment to avoid disclosing exception information -->
<serviceDebug includeExceptionDetailInFaults="false"/>
</behavior>
</serviceBehaviors>
</behaviors>
<serviceHostingEnvironment multipleSiteBindingsEnabled="false"/>
If the command line doesn't work you CAN do it in the UI. You will need to play around with the Friendly name of the certificate. Link below.
http://blog.armgasys.com/?p=80
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 am self hosting a REST WCF service in Windows service. The service exposes a method which returns a boolean and I am able to get the REST webservice to work on WinXp. I also generated a development certificate using makecert and assigned it to the port(1443) that the service listens on. Https also works well on WinXp. But When I use the same in Win2003, and type the URL in IE, it says "The page cannot be displayed". There were no errors in hosting the service, the service listens on the port(the ServiceHost.Open didnt have any errors and its successful). Is there an settings that has to be done in Win2003 for this? Win2003 is the production environment and https has to work on that.
Here is the config file I used,
<system.serviceModel>
<bindings>
<webHttpBinding>
<binding name="httpBinding">
<security mode="Transport">
<transport clientCredentialType="None"/>
</security>
</binding>
</webHttpBinding>
</bindings>
<services>
<service behaviorConfiguration="spectrumServiceBehavior" name="MyApp.TestService">
<host>
<baseAddresses>
<add baseAddress="https://localhost:1443/" />
</baseAddresses>
</host>
<endpoint address=""
binding="webHttpBinding"
bindingConfiguration ="httpBinding"
contract="MyApp.ITestService" />
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="spectrumServiceBehavior">
<!-- To receive exception details in faults for debugging purposes,
set the value below to true. Set to false before deployment
to avoid disclosing exception information -->
<serviceDebug includeExceptionDetailInFaults="true" />
<serviceMetadata httpsGetEnabled ="true"/>
</behavior>
</serviceBehaviors>
</behaviors>
Any ideas?
I've experienced the same problem. WinXP development environment working with HTTPS, certificate created locally and assigned to a custom port with httpcfg.
Production environment on Windows 2003 with the imported certificate and the same httpcfg configuration giving "interrupted connection" while trying to obtain the WSDL of the service.
Looking at the Windows log I finally found this error:
Event Source: Schannel
A fatal error occurred when attempting to access the SSL server credential private key. The error code returned from the cryptographic module is 0x80090016.
My problem was that I imported the certificate in the user-account store, and then copied in the local store. In this way the private-key is left behind... http://support.microsoft.com/kb/939616 (without even a warning!!!)
despite, opening the certificate in the new location, shows the presence of a private-key!
I expect that on Windows 2003 you must allow application to listen on port (unless it runs as admin) and you must assign SSL certificate to the port - both is performed by httpcfg.exe. Also check that there is no firewall blocking the communication on the port.
I have a simple WCF service (hosted as its own site in IIS). It was originally developed targeting .NET 4 but I have recently discovered that it needs to be downgraded to .NET 3.5.
I never touched the web.config file and it Just Worked. Now that I've changed the project from .NET 4 back to 3.5 I'm getting config errors. The first one was about multipleSiteBindingsEnabled not being recognised - a quick search tells me this is new in .NET 4 so I just deleted it. Now the error I'm getting is:
Service 'MyService' 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.
I just want to get the service responding so I can test firing things at it. The system that will be consuming the service doesn't exist yet (it's currently being developed by a government department) so once that's closer to completion we'll be worrying about the config that will be needed for it to go into production etc. What's the minimum config I need in the web.config to make it work for testing?
You need these basic nodes in your service's web.config files usually.
Of Course the binding types / dedub config / etc is all just for testing.
You need to fine tune it as per your needs
<system.serviceModel>
<services>
<service name="A.B.C.D" behaviorConfiguration="returnFaults">
<endpoint contract="A.B.C.ID" binding="basicHttpBinding" address=""/>
</service>
</services>
<bindings>
<basicHttpBinding>
<binding name="HttpBinding" maxReceivedMessageSize="2097152">
</binding>
</basicHttpBinding>
</bindings>
<behaviors>
<serviceBehaviors>
<behavior name="returnFaults">
<serviceDebug includeExceptionDetailInFaults="true"/>
<serviceMetadata httpGetEnabled="true"/>
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
I'm trying to get a WCF web service to work with SSL, as you can imagine it works on my machine, however when I run it on the production environments I get this instead:
Could not find a base address that matches scheme http for the endpoint with binding BasicHttpBinding. Registered base address schemes are [https].
Despite many hours of wrestling with this problem I still have very little idea what this error message actually means - googling for this error message finds loads of people saying that I should either specify an address in my endpoint configuration or add a base address to my service, however:
My service worked perfectly fine without specifying either with SSL disabled
In fact, my service works perfectly fine with SSL with the exact same configuration on another machine
Besides, I've found a post which reliably informs me that when hosting under IIS the base address is ignored anyway.
As you can probably tell, I'm currently feeling a very fustrated at my utter failure to achieve what I believed to be a relatively simple task, so:
What does this error message actually mean?
How are base addresses determined when hosting under IIS?
Where can I find reliable, understandable documentation about what all of my copy-pasted configuration actually means?
What do I need to do to get my service to actually work?
The interesting bits of my web.config are:
<system.serviceModel>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true"/>
<services>
<service name="MyService" behaviorConfiguration="MyBehavior">
<endpoint binding="basicHttpBinding" bindingConfiguration="SecureTransport"
bindingNamespace="http://MyNamespace/Service" name="Basic"
contract="MyContract" />
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="MyBehavior">
<serviceMetadata httpsGetEnabled="true"/>
<serviceDebug includeExceptionDetailInFaults="true"/>
</behavior>
</serviceBehaviors>
</behaviors>
<bindings>
<basicHttpBinding>
<binding name="SecureTransport">
<security mode="Transport" />
</binding>
</basicHttpBinding>
</bindings>
</system.serviceModel>
One thing that is off field but can cause this message is if the SSL certificate on the server is expired or not set up correctly.
I've never deployed a WCF service to IIS 6 before. I've got a service that I'm deploying to IIS 6 by using the default configuration as part of the WCF project. I since simplified the configuration thinking that might have been the issue. Here is the error I'm getting if I browse to the service in a browser:
HTTP Error 403.1 - Forbidden: Execute
access is denied.
My configuration now looks like this:
<system.serviceModel>
<services>
<service name="MyCompany.WebServices.MyService">
<endpoint address="" binding="basicHttpBinding" contract="MyCompany.WebServices.IMyService" />
</service>
</services>
</system.serviceModel>
If I try adding it as a reference in ASP.NET MVC, I get the following:
There was an error downloading
'http://ws.mycompany.com/MyService.svc'.
The request failed with HTTP status
403: Forbidden. Metadata contains a
reference that cannot be resolved:
'http://ws.mycompany.com/MyService.svc'.
The HTTP request was forbidden with
client authentication scheme
'Anonymous'. The remote server
returned an error: (403) Forbidden. If
the service is defined in the current
solution, try building the solution
and adding the service reference
again.
Any ideas what might be going on?
UPDATED:
It appears to be a configuration issue on my IIS 6 box. I'd assume this because I've created a brand new ASP.NET 3.5 WCF Application and deployed it to a new URL at http://ws.unitedoneresources.com/Service1.svc. If I try to call that service, I get the same HTTP Error listed above. The entire service configuration is the following:
<system.serviceModel>
<services>
<service name="WcfService1.Service1" behaviorConfiguration="WcfService1.Service1Behavior">
<!-- Service Endpoints -->
<endpoint address="" binding="wsHttpBinding" contract="WcfService1.IService1">
<!--
Upon deployment, the following identity element should be removed or replaced to reflect the
identity under which the deployed service runs. If removed, WCF will infer an appropriate identity
automatically.
-->
<identity>
<dns value="localhost"/>
</identity>
</endpoint>
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="WcfService1.Service1Behavior">
<!-- To avoid disclosing metadata information, set the value below to false and remove the metadata endpoint above before deployment -->
<serviceMetadata httpGetEnabled="true"/>
<!-- To receive exception details in faults for debugging purposes, set the value below to true. Set to false before deployment to avoid disclosing exception information -->
<serviceDebug includeExceptionDetailInFaults="false"/>
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
Again, this is a brand new ASP.NET 3.5 WCF Application so I haven't modified anything on the project itself.
I wacked the I wacked the website, installed WCF on IIS 6 (using ServiceModelReg.exe /i /x at a command prompt), and redeployed. It worked!
Thanks!
Found this question searching for a solution to the same problem. I had forgotten to changes permissions to 'Scripts and Executables' on the services directory. I was on II7
You don't really give us a lot to go on here - what's missing are the server side configuration bits that show us how you set up security - can you please update your question and show us everything inside the <system.serviceModel> tag on your server side config and on your client calling the server??
Just guessing from the system defaults, using the basicHttpBinding would result in a default security setting of nothing - and it would appear as if your server-side config requires some form of security. It almost seems as if your security settings are out of sync, thus resulting in this error.
Another point is: how did you set up the IIS side? Did you create a virtual directory for your service? Basically, when hosting in IIS, your service URL is determined by server name (plus possibly the port), the virtual directory your *.svc file lives in, and the name and extension of the svc file itself.
We had similar symptoms, but only with PUT and DELETE verbs under IIS 6.0.
By default, the .svc extension within our IIS application was only allowing GET, POST verbs.
Adding the verbs (or allowing all verbs) for the .svc extension for the application fixed the issue.