Client from outside of the network
- Hi
I've a strange problem... I've deployed a wcf-service to the production-system.
Now I wanna try to create a test-client - and it failed, 'cause it tried to connect local computername:
The error message from each known type may help you fix the problem:
- Report from 'DISCO Document' is 'There was an error downloading 'http://frontend0/ums2/UserManagementService.svc?disco'.'.
- The remote name could not be resolved: 'frontend0'
- Report from 'http://111.111.111.111/ums2/usermanagementservice.svc' is 'The document format is not recognized (the content type is 'text/html; charset=UTF-8').'.
- Report from 'WSDL Document' is 'The document format is not recognized (the content type is 'text/html; charset=UTF-8').'.
- Report from 'XML Schema' is 'The document format is not recognized (the content type is 'text/html; charset=UTF-8').'.
I configured a host-address on the server like this:
<host>
<baseAddresses>
<add baseAddress="http://111.111.111.111/ums2/usermanagementservice.svc" />
</baseAddresses>
</host>
The server is not directly reachable from the internet, it's behind a loadbalancer. Don't know if this affects it in a way...
Any idea?
Dani
Answers
If this is a self-hosted service, then I think you should put the 'frontend' name in the <baseAddresses>, rather than the backend machine. Can you try that to see if it resolves it?
See also http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1095396&SiteID=1 for IIS-hosting.
- If the service has to run with ssl because, e.g., that is your goal, then yes, the change of the SecurityMode on the Binding to a mode that includes Transport security is indeed the real 'fix'.
All Replies
If this is a self-hosted service, then I think you should put the 'frontend' name in the <baseAddresses>, rather than the backend machine. Can you try that to see if it resolves it?
See also http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1095396&SiteID=1 for IIS-hosting.
- I'm using IIS-Hosting... so the solution would be to define a hostheader...
Is there a way to achieve this without setting a host-header? E.g. directly with the IP? - OK, I solved the problem with the hostname by using host headers...
But now I got one more problem, svcutil tries to get the DISCO-File from http://... but it should take it from https://... - I am unclear about this, can you describe the svcutil problem in more detail? What command-line do you run, what error do you get?
- The command I run:
****
svcutil https://myhost/myservice.svc /r:"C:\Windows\Microsoft.NET\Framework64\v2.0.50727\System.dll" /ct
ystem.Collections.Generic.List`1 /async /n:*,connvision.CvSystem.Applications.BTAG.ServiceAccess.UserManagement /mergeconfig /config
utput.config
The error I get:
****
Error: Cannot obtain Metadata from https://myhost/myservice.svc
If this is a Windows (R) Communication Foundation service to which you have acce
ss, please check that you have enabled metadata publishing at the specified addr
ess. For help enabling metadata publishing, please refer to the MSDN documentat
ion at http://go.microsoft.com/fwlink/?LinkId=65455.
WS-Metadata Exchange Error
URI: https://myhost/myservice.svc
Metadata contains a reference that cannot be resolved: 'https://myhost/myservice.svc'.
There was no endpoint listening at https://ws.beetagg.com/1.0/rms/rangemanag
ementservice.svc that could accept the message. This is often caused by an incor
rect address or SOAP action. See InnerException, if present, for more details.
The remote server returned an error: (404) Not Found.
HTTP GET Error
URI: https://myhost/myservice.svc
The document at the url https://ws.beetagg.com/1.0/rms/rangemanagementservic
e.svc was not recognized as a known document type.
The error message from each known type may help you fix the problem:
- Report from 'DISCO Document' is 'There was an error downloading 'https://myhost/myservice.svc?disco'.'.
- Unable to connect to the remote server
- No connection could be made because the target machine actively refused it
- Report from 'https://myhost/myservice.svc' is 'Th
e document format is not recognized (the content type is 'text/html; charset=UTF
-8').'.
- Report from 'WSDL Document' is 'The document format is not recognized (the con
tent type is 'text/html; charset=UTF-8').'.
- Report from 'XML Schema' is 'The document format is not recognized (the conten
t type is 'text/html; charset=UTF-8').'.
MetaDataPublishing is enabled, the service is available and working.
Also when I open the service in the browser, a message appears that tells me, I can generate a proxy by using
svcutil http://...
(but not https://...) Does it work when you point svcutil at http (not https)?
Do you want the metadata to be secure (only https)?
Can you share your config for metadata publishing?
Brian McNamara - MSFT wrote: Does it work when you point svcutil at http (not https)?
No, 'cause access is only allowed through ssl.
Brian McNamara - MSFT wrote: Do you want the metadata to be secure (only https)?
Mh... that's not a must. But the usual way to add a service reference should work ("Add service reference..." in VS).
Brian McNamara - MSFT wrote: Can you share your config for metadata publishing?
Yes, I post the whole service-config:
<
system.serviceModel><
services><
service behaviorConfiguration="SecureBehavior" name="connvision.CvSystem.Core.Services.RangeManagerService.RangeManagementService"><
endpoint binding="wsHttpBinding" bindingConfiguration="WsHttp" name="WsHttp" contract="connvision.CvSystem.Core.Services.RangeManagerService.ServiceContracts.IRangeManagementService" /></
service></
services><
bindings><
wsHttpBinding><
binding name="WsHttp" maxReceivedMessageSize="999999"><
security mode="Message"><
message clientCredentialType="UserName" establishSecurityContext="false" /></
security></
binding></
wsHttpBinding></
bindings><
behaviors><
serviceBehaviors><
behavior name="SecureBehavior"><
serviceMetadata httpGetEnabled="true" /><
serviceDebug includeExceptionDetailInFaults="true" /><
serviceCredentials type="connvision.CvSystem.Core.Services.Common.ProviderServiceCredentials, Services.Common.ServiceImplementation"><
serviceCertificate findValue="Plexi2" storeLocation="LocalMachine" storeName="My" x509FindType="FindBySubjectName" /><
userNameAuthentication userNamePasswordValidationMode="Custom" customUserNamePasswordValidatorType="connvision.CvSystem.Core.Services.Common.ProviderCredentialsValidator, Services.Common.ServiceImplementation" /></
serviceCredentials></
behavior><
behavior name="StandardBehavior"><
serviceMetadata httpGetEnabled="true" /><
serviceDebug includeExceptionDetailInFaults="true" /></
behavior></
serviceBehaviors></
behaviors></
system.serviceModel><serviceMetadata httpGetEnabled="true" />
Please add httpsGetEnabled="true" and try again, I think that is the issue.
- Unfortunately this didn't changed anything... (but it's a shame that I didn't saw that by myself)
But the error is still the same... it's still trying to access over http 
Dani-CH wrote: Unfortunately this didn't changed anything... Hmm... what happens when you hit the https .svc file in a browser?
Dani-CH wrote: But the error is still the same... it's still trying to access over http What do you mean by still trying to access over http? I didn't see anything in the previous error message you posted that suggested that svcutil was using http rather than https.
- After restarting IIS it worked... sorry. So now I can generate my service proxy... but it doesn't work!

When I run the client I got the following exception:
The provided URI scheme 'https' is invalid; expected 'http'.
Parameter name: via
The strange thing is, that in the generated config file, the url is there as 'http://...' . Of course I cannot connect like that, but when I change to 'https://...' I got the exception above... - Are there multiple <client> entries in the generated config? I think that maybe svcutil appends (rather than overwrites) config, which means you still might have a previous version in there too. Can you try deleting the generated files and starting over to ensure that's not the issue?
- No, I've deleted the config first - there's only one client-section.
Oh, oops, I just looked at your server config, and you are using http (not https) for the app endpoint (wsHttp with Message security (not Transport security)).
So the generated client should have http.
You're saying that the generated client does not work?
- Hmm... Now I'm confused

Yes I'm using MessageSecurity - but the service is although only reachable through https.
So I'm adding the reference with svcutil to:
https://myhost/myservice.svc
But in the generated config-file is
http://myhost/myservice.svc
If I'm using the client with the http-url in the conrfig, I'm getting the exception, that the url is not reachable (and that's true... )
If I'm using the client with the https-url, I'm getting the invalid URI-Scheme exception. - 'Cause of your answer, I tried with the following server-config:
<security mode="TransportWithMessageCredential">
<message clientCredentialType="UserName" establishSecurityContext="false" />
<transport />
</security>
And it worked... is this the issue I'm doing wrong? I think what's happening is
- you have IIS set up to only serve https
- metadata is enabled over http or https, so svcutil can read the https stuff (which IIS is hosting)
- your app endpoint uses http. IIS doesn't like that, so you get unreachable
- (and of course if you try to tell the client https, you get invalid scheme, because the binding doesn't use that scheme)
I think this begs the question where did 'https' come in? I think the thread started with IIS/ssl headers, but maybe you started down that road because you thought you needed it for your 'secure' binding, when in fact you don't (because you are using Message security)?
- Reading back over the whole thread, I think you introduced the IIS host header in order to fix the frontend/backend problem, but in the process you also made it an https host header when in fact you just want an http host header.
- Mmh - a lot of confusing here... :-)
- The service is running with ssl (only, http is not available)
- I used the host-header in the ssl-bindings, 'cause svcutil always tried to access the disco-file with the local computername, instead of the ip.
- And then the problem switched to, that it was always using http but I needed https
So I think you have 'worked around' the problem.
I think the 'fix' would be to have service not run with ssl, use a non-ssl http host header to deal with localcomputername problem, everything is just http.
- I think you missunderstood me... the service was always with ssl. The host-header-thing was only a minor issue, 'cause I had this thing with the local computername.
The service has to run with ssl. - If the service has to run with ssl because, e.g., that is your goal, then yes, the change of the SecurityMode on the Binding to a mode that includes Transport security is indeed the real 'fix'.


