I have created a wcf service, successfully deployed to a development server(not behind an ISA Server) and was able to add a service reference to to the service in a test web app. My network administrators deployed the same service to our staging box which is behind an ISA server, when I try to add a service reference through vs2008 or use the svcutil utility I get the following:
Metadata contains a reference that cannot be resolved:
'http://tstsrvr.Testdmz.staging:5910/myService/TestService.svc?wsdl'.
There was an error downloading 'http://tstsrvr.Testdmz.staging:5910/myService/TestService.svc?wsdl'.
The remote name could not be resolved: 'tstsrvr.Testdmz.staging'
Metadata contains a reference that cannot be resolved:
'https://stg-ww2.Test.com/myservice/Testservice.svc'.
Metadata contains a reference that cannot be resolved:
'https://stg-ww2.Test.com/myservice/Testservice.svc'.
If the service is defined in the current solution, try building the solution and
adding the service reference again.
I am able to hit the .svc link through a web browser and then able to click the link
svcutil.exe https://stg-ww2.myserver.com/TestService/TestService.svc?wsdl
which seems to work fine, I am pretty new to wcf so any help is appreciated.
Thanks
Mark
svcutil.exe uses IE's proxy settings.
Uncheck "use a proxy server" from IE > Tools > Internet Options > Connections > LAN Settings and see if that solves your problem.
If you still have a problem, consider adding the system.net section in your configuration file.
<system.net>
<defaultProxy >
<proxy autoDetect ="True" />
</defaultProxy>
</system.net>
and set
<transport proxyCredentialType="Windows"/>
Related
I'm attempting to add a service reference to a WCF app hosted on our local intranet and VS2012 is automatically replacing the IP address I'm giving it with a resolved DNS name.
I would like to see:
http://10.1.0.96/CrmTunnel.svc
but VS is populating all of the disco/svcinfo/wsdl files with:
http://mlapp01.domain.com/CrmTunnel.svc
Is there a way to disable this behavior?
Found that I needed to add this to my web.config in the behavior section:
<useRequestHeadersForMetadataAddress />
I have the wcf service package, waiting to be put in IIS. Everything goes fine when I create a virtual directory on the default website and etc. But when I try to access the path in Chrome I get an error:
It is an error to use a section registered as allowDefinition='MachineToApplication' beyond application level. This error can be caused by a virtual directory not being configured as an application in IIS.
When I comment this section:
<serviceHostingEnvironment aspNetCompatibilityEnabled="true"
multipleSiteBindingsEnabled="true" />
I can access the directory but not the service. Any idea?
I tried a little more and figured out what I was doing wrong. I can't create an virtual path under the Default Website. I had to create my own site, which appoint to the folder where my WCF files are storage. Something like this:
appcmd add site /name:WcfService1 /id:2 /physicalPath:C:\WcfService1 /bindings:http/*:8080
This way the virtual directory will be marked as an applicattion and everything will work just fine.
I have a .NET 3.5 WCF service hosted in IIS. The project service library has an app.config file with some configuration settings (Database connection strings, etc.). I deploy the project via a website project in Visual Studio, which generates a web.config to manage the endpoints. Is there a way I can put the app.config settings from my service library in to the web.config? The IIS hosted service seems to be using default values from the settings designer, and ignoring even an expliclty copied in app.config. I'm guessing this has something to do with the fact that a DLL can not utliize an app.config.
My service application is set up to pull the settings settings from the [MyAssembly].Properties.Settings.Default namespace.
Can you use external configuration files?
Your web.config:
<config>
...
<connectionStrings configSource="myConnections.config"></connectionStrings>
</config>
And then your external myConnections.config file:
<connectionStrings>
<add ... />
</connectionStrings>
You can have multiple external configuration files referenced from your main web.config file. See see this blog post for a nice explanation of how/why to do this.
I hope this helps!
(I see several questions related to my problem but none of the solutions work for me as I am encountering this problem in production, not during local development, and I've already tried all of the proposed fixes.)
I have a Silverlight 4 application that uses WCF services hosted by IIS. In production these services are accessed over HTTPS. Despite having a valid crossdomain.xml file I still get the famous "Security error" when accessing the service:
An error occurred while trying to make a request to URI
'https://MYDOMAIN/MYSERVICE.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. --->
System.Security.SecurityException --->
System.Security.SecurityException: Security error...
Using Fiddler I can see that no request is made to crossdomain.xml or clientaccesspolicy.xml. There is a CONNECT request to the server but that is all.
I've read that this error, though it indicates a problem with crossdomain.xml/clientaccesspolicy.xml, can also be raised when the server issues an invalid certificate. This does not seem to be the case in my scenario.
I am certain the following is set up correctly:
1. crossdomain.xml is valid and hosted in the root of the site
2. The services do work (We have other clients in various technologies that use them, including Adobe Flex which relies on crossdomain.xml.)
3. The Silverlight app does work (It works just fine with local services and services on a shared development server***)
4. The Silverlight app does not even try to request crossdomain.xml or clientaccesspolicy.xml (as confirmed by Fiddler)
5. The Silverlight app uses the proper config for accessing WCF over https. Below is the configuration:
<configuration>
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="BasicHttpBinding_IMyServices" maxBufferSize="2147483647" maxReceivedMessageSize="2147483647">
<security mode="Transport" />
</binding>
</basicHttpBinding>
</bindings>
<client>
<endpoint address="https://MYDOMAIN/MYSERVICE.svc" binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_IMyServices" contract="Services.IMyServices" name="BasicHttpBinding_IMyServices" />
</client>
</system.serviceModel>
</configuration>
What else can cause this kind of problem? Could it be because the web servers are load balanced? Or is there a problem with the certificate that I haven't noticed? If you can at least point me in the right direction that would be much appreciated.
(***Something worth pointing out: I came upon a similar problem in our development environment. The Silverlight app was unable to access WCF services on a shared development server, despite having a proper crossdomain.xml and not using HTTPS. I worked around it by adding the development server as a trusted site in IE. However this same workaround does not work for production, and even then it wouldn't be an acceptable workaround. But the fact that I had to do this in the development environment makes me worried that I've missed something along the way...)
The problem was that I was missing clientaccesspolicy.xml. Having crossdomain.xml was not sufficient in this case. I think this is because the WCF invocation was not just cross-browser but also cross-protocol (the Silverlight app was served via http but the services were served via https).
In addition, my clientaccesspolicy.xml had to explicitly allow access for http as follows:
<?xml version="1.0" encoding="utf-8"?>
<access-policy>
<cross-domain-access>
<policy>
<allow-from http-request-headers="SOAPAction">
<!-- IMPORTANT! Include these lines -->
<domain uri="http://*"/>
<domain uri="https://*"/>
</allow-from>
<grant-to>
<resource path="/" include-subpaths="true"/>
</grant-to>
</policy>
</cross-domain-access>
</access-policy>
It now works like a charm.
A couple of things that tripped me up along the way:
My browser was caching clientaccesspolicy.xml and crossdomain.xml. I would have to clear my cache every time I changed one of those files or it wouldn't recognize the newer version, despite the fact that IIS is configured to prevent client caching of this file.
The requests to clientaccesspolicy.xml and crossdomain.xml were not always showing up in Fiddler. I would often see CONNECT requests instead. I don't understand the reason for this but I've learned not to rely on Fiddler to confirm these requests are being made. Perhaps I have some rogue setting somewhere (it's not the "Decrypt HTTPS traffic" setting because I already disabled it).
I have the same error, when I try to make a call to my site over http and my service was over https it failed. This error occured because my ISS had no certificate, so, when the app tried to download the clientaccesspolicy, it failed.
Take a look in any debug tool on your browser and look for clientacccesspolicy file, then check that if it is being downloaded.
We are experimenting with hosting a silverlight application on Amazons EC2.
I can get it to serve up the .xap file, but I'm having some trouble with using the webservices that the silverlight application requires.
Usually I would add a service reference in visual studio and enter the URL for the webservice, something like http://url.com/ServiceName.svc and a proxy would be generated for me.
However with the Amazon Elastic Cloud instance entering the url
http://ec2-174-129-139-48.compute-1.amazonaws.com/AuthService.svc
Gives the error "is not recognised as a known document type"
And if I enter
http://ec2-174-129-139-48.compute-1.amazonaws.com/AuthService.svc?wsdl
Into the internet explorer address bar I get a wsdl description - but it has this part in the config which seems a bit odd
<wsdl:types>
<xsd:schema targetNamespace="http://asp.net/ApplicationServices/v200/Imports">
<xsd:import schemaLocation="http://ip-0af8db15/AuthService.svc?xsd=xsd0" namespace="http://asp.net/ApplicationServices/v200" />
<xsd:import schemaLocation="http://ip-0af8db15/AuthService.svc?xsd=xsd1" namespace="http://schemas.microsoft.com/2003/10/Serialization/" />
</xsd:schema>
</wsdl:types>
The schemaLocation http://ip-0af8db15/AuthService.svc? doesn't look like the right address to me?
Anyone know if I need to configure something or change something to access WCF webservices on Amazon EC2?
Edit: Should note : Windows Server 2003, IIS 6.0
Edit: Looks like ip-0af8db15 is the machine name
Just in case someone went into the same problem:
on proxy generation try remove the http:// at the beginning of the EC2 Address and then in the Service Config replace the part "ip-0af8db15" with the EC2 Address.
Hope it helped.
I have the same scenario deployed with no issues. Why don't you try using the IP address instead of the dynamic hostname:
http://174.129.139.48/AuthService.svc
Edit:
If an unreachable server name is being put into the VS.Net generated proxy then you can adjust it manually in the automatically generated configuration.svcinfo. Alternatively you can set the URL programatically, this is a better option since it won't get over written if you need to re-generate the proxy.
BasicHttpBinding binding = new BasicHttpBinding();
EndpointAddress address = new EndpointAddress("http://174.129.139.48/AuthService.svc");
YourProxy yourProxy = new YourProxy(binding, address);
This thread (particularly the last two posts) helped me to solve this problem.
http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/c7fd51a2-773e-41d4-95a0-244e925597fe/