We have created a WCF service application for a customer. Since the service is used to transmit large amounts of data (which can take a long time), some changes (such as increased timeout limits or message size limits) have been made to the Web.config file to accommodate this.
Everything works fine and there are no technical issues... except the client isn't exactly happy that whenever they create a new application which consumes the WCF service they need to manually add all the changes to the client-side App.config file.
They would like to have the changes to be read from the service automatically.
I've never of WCF having such functionality, so I don't think this is possible. But I would very much like to have this confirmed... or denied, if this is actually possible.
IIRC .. in earlier releases of the stocktrader app.
How to implement Configuration Service 5.0 of the StockTrader 5.0 sample application?
mentioned in the above SOF link
There was a way to get configuration from a service.
However, the stocktrader app looks much different now then it did earlier.
So I don't know which version it become something different.
Greg Leake (Leak) was the name of the dude I met at TechEd one year....talking about this, IIRC.
IT IS NOT TRIVIAL TO IMPLEMENT.
The cost of editing some clientside config files........vs the configuration service.....you'll have to make that call.
But it sounds like you have a case of your client needing some cheese with their whine.
Here is an older video...that might get you on the right path.
http://channel9.msdn.com/Shows/Endpoint/endpointtv-High-Performance-WCF-NET-Stock-Trader-with-Greg-Leake
This PDF
http://download.microsoft.com/download/7/C/9/7C9F7B89-8AF0-4433-AB3A-B615C8EF9484/ConfigServiceVSTemplate.pdf
will give you the hints at it.
It is a lot of work to get a "configuration service" up and running.
We ended up...NOT doing it.......and using xml-manipulation in msbuild tasks.......to tweak the wcf client-side xml sections.
EDIT:
Alternate idea. Put you WCF in separate files..and distribute those.
It will make the "where to edit" much more discernable ..... or go with whole-sale replacement all of the (4) files.
app.config or web.config
<?xml version="1.0"?>
<configuration>
<system.serviceModel>
<behaviors configSource="WCFBehaviors.config">
</behaviors>
<bindings configSource="WCFBindings.config">
</bindings>
<client configSource="WCFClient.config">
</client>
<services configSource="WCFServices.config">
</services>
</system.serviceModel>
Then make the 4 files.
Example WCFServices.config
<services>
<service name="MyApp.MyService">
<endpoint
address = "http://localhost:8001/MyService"
binding = "wsHttpBinding" bindingConfiguration="WSHttpBindingName1"
contract = "MyApp.MyIService" >
</endpoint>
</service>
</services>
Note, these won't be auto-voodoo-included like web.config and app.config.
You'll have to make sure they end up in your build-outputs.
Unless you create a custom method to expose these parameters, or at least the values of them, they are not visible to the consumer.
Config files are supposed to be private which is why you are not able to browse to them in a standard installation.
It sounds to me like your client needs to accept that perhaps when adding a new service, there is a little bit of work that needs to be done. They could in theory cut and paste the servicemodel configuration, or sections of it, from an existing application to save 'some' time.
I don't know if this is a bug/feature but I need to find a way to make it work.
To recreate, use VS2012, open a new SL5 project with RIA services enabled. Create another project, add a simple WCF service (or a SL enabled WCF) and add a method that accepts or returns a simple object (I have an object with one string property in it). Try and add this as a service reference to your SL project. You'll receive this error, among others, in the warnings:
Custom tool warning:
No endpoints compatible with Silverlight 5 were found. The generated client class will not be usable unless endpoint information is provided via the constructor.
and no generated code is actually generated.
I found that if I remove the object from the service method and use a simple string/int/bool instead, the reference is added just fine. Also, if I add the same service to a regular SL app without RIA, everything works like you would expect it to. Once I enable RIA on this app where the service is working, and update the service reference, the generated code is gone again.
I remember this used to work because I had projects that used both RIA and external WCF services. Is this a new VS2012 thing? Is there a way to solve this issue?
Thanks,
Eyal
I can duplicate the problem, and it only seems to happen if the Silverlight client has the 2 System.ServiceModel.DomainServices.Client and System.ServiceModel.DomainServices.Client.Web assemblies in its referenced assemblies. And only if it targets SL 5.
I have found 2 workarounds I recommend you try if your situation permits:
1) Change the Silverlight application to target Silverlight 4, not 5, or
2) Right-click the Service Reference and ask to Configure it.
Click the checkbox to "Reuse types in specified referenced assemblies"
and select all assembles except the 2 mentioned above.
This does appear to be a bug related to either SL 5 or VS2012. I will repost if I find a more satisfactory answer.
The problem is because of silverlight 5 and vs 2012 has some bug. [It can solve itself by restarting the vs2012]
If you look at your ServiceRefrences.ClientConfig will see it is empty. You need to enter your service refrences manually here. I have attached an example of my config page, you need to change the names accordingly
<configuration>
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="BasicHttpBinding_IService2" maxBufferSize="2147483647"
maxReceivedMessageSize="2147483647">
<security mode="None" />
</binding>
</basicHttpBinding>
</bindings>
<client>
<endpoint address="../Service2.svc" binding="basicHttpBinding"
bindingConfiguration="BasicHttpBinding_IService2" contract="ServiceReference1.IService2"
name="BasicHttpBinding_IService2" />
</client>
</system.serviceModel>
(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.
I've added a proxy to a webservice to a VS2008/.NET 3.5 solution. When constructing the client .NET throws this error:
Could not find default endpoint element that references contract 'IMySOAPWebService' in the ServiceModel client configuration section. This might be because no configuaration file was found for your application or because no endpoint element matching this contract could be found in the client element.
Searching for this error tells me to use the full namespace in the contract. Here's my app.config with full namespace:
<client>
<endpoint address="http://192.168.100.87:7001/soap/IMySOAPWebService"
binding="basicHttpBinding" bindingConfiguration="IMySOAPWebServicebinding"
contract="Fusion.DataExchange.Workflows.IMySOAPWebService" name="IMySOAPWebServicePort" />
</client>
I'm running XP local (I mention this because a number of Google hits mention win2k3)
The app.config is copied to app.exe.config, so that is also not the problem.
Any clues?
"This error can arise if you are calling the service in a class library and calling the class library from another project."
In this case you will need to include the WS configuration settings into the main projects app.config if its a winapp or web.config if its a web app. This is the way to go even with PRISM and WPF/Silverlight.
I solved this (I think as others may have suggested) by creating the binding and endpoint address instances myself - because I did not want to add new settings to the config files (this is a replacement for some existing library code which is used widely, and previously used an older Web Service Reference etc.), and so I wanted to be able to drop this in without having add new config settings everywhere.
var remoteAddress = new System.ServiceModel.EndpointAddress(_webServiceUrl);
using (var productService = new ProductClient(new System.ServiceModel.BasicHttpBinding(), remoteAddress))
{
//set timeout
productService.Endpoint.Binding.SendTimeout = new TimeSpan(0,0,0,_webServiceTimeout);
//call web service method
productResponse = productService.GetProducts();
}
Edit
If you are using https then you need to use BasicHttpsBinding rather than BasicHttpBinding.
Having tested several options, I finally solved this by using
contract="IMySOAPWebService"
i.e. without the full namespace in the config. For some reason the full name didn't resolve properly
I've had this same issue. It turns out that for a web REFERENCE, you have to supply the URL as the first parameter to the constructor:
new WebService.WebServiceSoapClient("http://myservice.com/moo.aspx");
For a new style web SERVICE REFERENCE, you have to supply a name that refers to an endpoint entry in the configuration:
new WebService.WebServiceSoapClient("WebServiceEndpoint");
With a corresponding entry in Web.config or App.config:
<client>
<endpoint address="http://myservice.com/moo.aspx"
binding="basicHttpBinding"
bindingConfiguration="WebService"
contract="WebService.WebServiceSoap"
name="WebServiceEndpoint" />
</client>
</system.serviceModel>
Pretty damn hard to remove the tunnel vision on "it worked in an older program"...
I had a situation like this, where i had
WCF Service Hosted somewhere
Main Project
Consumer Project of type 'class Library' which has Service reference to a WCF Service
Main project calls methods from consumer project
Now the Consumer project had all the related configuration setting in <system.serviceModel> Tag of my app.config, its was still throwing the same error as the above.
All i did is added the same tag <system.serviceModel> to my main project's app.config file, and finally we were good to go.
The Real problem, as far as in my case was, it was reading the wrong configuration file. Instead of consumer's app.config, it was referring main proj's config. it took me two hours to figure that out.
"This error can arise if you are calling the service in a class library and calling the class library from another project."
"In this case you will need to include the WS configuration settings into the main projects app.config if its a winapp or web.config if its a web app. This is the way to go even with PRISM and WPF/Silverlight."
Yes, but if you can't change main project (Orchard CMS for example), you can keep WCF service config in your project.
You need to create a service helper with client generation method:
public static class ServiceClientHelper
{
public static T GetClient<T>(string moduleName) where T : IClientChannel
{
var channelType = typeof(T);
var contractType = channelType.GetInterfaces().First(i => i.Namespace == channelType.Namespace);
var contractAttribute = contractType.GetCustomAttributes(typeof(ServiceContractAttribute), false).First() as ServiceContractAttribute;
if (contractAttribute == null)
throw new Exception("contractAttribute not configured");
//path to your lib app.config (mark as "Copy Always" in properties)
var configPath = HostingEnvironment.MapPath(String.Format("~/Modules/{0}/bin/{0}.dll.config", moduleName));
var configuration = ConfigurationManager.OpenMappedExeConfiguration(new ExeConfigurationFileMap { ExeConfigFilename = configPath }, ConfigurationUserLevel.None);
var serviceModelSectionGroup = ServiceModelSectionGroup.GetSectionGroup(configuration);
if (serviceModelSectionGroup == null)
throw new Exception("serviceModelSectionGroup not configured");
var endpoint = serviceModelSectionGroup.Client.Endpoints.OfType<ChannelEndpointElement>().First(e => e.Contract == contractAttribute.ConfigurationName);
var channelFactory = new ConfigurationChannelFactory<T>(endpoint.Name, configuration, null);
var client = channelFactory.CreateChannel();
return client;
}
}
and use it:
using (var client = ServiceClientHelper.GetClient<IDefaultNameServiceChannel>(yourLibName)) {
... get data from service ...
}
See details in this article.
This one drove me crazy.
I'm using Silverlight 3 Prism (CAB) with WCF
When I call a WCF service in a Prism module, I get the same error:
Could not find default endpoint element that references contract
'IMyService' in the service model client configuaration section. This
might be because no configuaration file was found for your application
or because no end point element matching this contract could be found
in the client element
It turns out that its looking in the Shell's .xap file for a ServiceReferences.ClientConfig file, not in the module's ServiceReferences.ClientConfig file. I added my endpoint and binding to the existing ServiceReferences.ClientConfig file in my Silverlight Shell application (it calls it's own WCF services).
Then I had to rebuild the Shell app to generate the new .xap file for my Web project's ClientBin folder.
Now this line of code finally works:
MyServiceClient myService = new MyServiceClient();
Several responses here hit upon the correct solution when you're facing the mind-numbingly obscure error of referencing the service from a class file: copy service config info into your app.config web.config of your console or windows app. None of those answers seem to show you what to copy though. Let's try and correct that.
Here's what I copied out of my class library's config file, into my console app's config file, in order to get around this crazy error for a service I write called "TranslationServiceOutbound".
You basically want everything inside the system.serviceModel section:
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="BasicHttpBinding_ITranslationServiceOutbound" />
</basicHttpBinding>
</bindings>
<client>
<endpoint address="http://MyHostName/TranslationServiceOutbound/TranslationServiceOutbound.svc"
binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_ITranslationServiceOutbound"
contract="TranslationService.ITranslationServiceOutbound" name="BasicHttpBinding_ITranslationServiceOutbound" />
</client>
I was getting this error within an ASP.NET application where the WCF service had been added to a class library which is being added to the ASP.NET application as a referenced .dll file in the bin folder. To resolve the error, the config settings in the app.config file within the class library referencing the WCF service needed to be copied into the web.config settings for the ASP.NET site/app.
I had the same problem, but changing the contract namespace didn't work for me. So I tried a .Net 2 style web reference instead of a .Net 3.5 service reference. That worked.
To use a Web reference in Visual Studio 2008, click on 'Add Service Reference', then click 'Advanced' when the dialog box appears. In that you will find an option that will let you use a Web reference instead of a Service reference.
I found (as well as copying to the client UI's App.config as I was using a Class Library interface) I had to prefix the name of the binding with the name of the Service Reference (mine is ServiceReference in the below).
e.g.:
<endpoint address="http://localhost:4000/ServiceName" binding="basicHttpBinding"
bindingConfiguration="BasicHttpBinding_ISchedulerService"
contract="ServiceReference.ISchedulerService"
name="BasicHttpBinding_ISchedulerService" />
instead of the default generated:
<endpoint address="http://localhost:4000/ServiceName" binding="basicHttpBinding"
bindingConfiguration="BasicHttpBinding_ISchedulerService"
contract="ISchedulerService"
name="BasicHttpBinding_ISchedulerService" />
Unit testing a non-library application that consumes a service can cause this problem.
The information that others have entered addresses the root cause of this. If you are trying to write automated test cases and the unit you are testing will actually invoke the service interface, you need to add the service reference to the test project. This is a flavor of the application using library type of error. I did not immediately realize this though because my code that consumes the interface is not in a library. However, when the test actually runs it will be running from the test assembly, not the assembly under test.
Adding a service reference to the unit test project resolved my issue.
I have a situation which in the Unit test. I copied the app.config file to the unit test project. So the unit test project also contains endpoint information.
I faced this problem once. It was because i was still developing the interface that uses WCF service. I configured test application and continued development. Then in development, i changed some of the services' namespaces. So i double checked "system.serviceModel -> client -> endpoint -> contract" in web.config to match WCF class. Then problem is solved.
The namespace in your config should reflect the rest of the namespace path after your client's default namespace (as configured in the project properties). Based on your posted answer, my guess is that your client is configured to be in the "Fusion.DataExchange.Workflows" namespace. If you moved the client code to another namespace you would need to update the config to match the remaining namespace path.
This error can arise if you are calling the service in a class library and calling the class library from another project.
I Have a same Problem.I'm Used the WCF Service in class library and calling the class library from windows Application project.but I'm Forget Change <system.serviceModel> In Config File of windows application Project same the <system.serviceModel> of Class Library's app.Config file.
solution: change Configuration of outer project same the class library's wcf configuration.
Hi I've encountered the same problem but the best solution is to let the .NET to configure your client side configuration. What I discover is this when I add a service reference with a query string of http:/namespace/service.svc?wsdl=wsdl0 it does NOT create a configuration endpoints at the client side. But when I remove the ?wsdl-wsdl0 and only use the url http:/namespace/service.svc, it create the endpoint configuration at the client configuration file. for short remoe the " ?WSDL=WSDL0" .
Do not put service client declaration line as class field,
instead of this, create instance at each method that used in.
So problem will be fixed. If you create service client instance as class field, then design time error occurs !
In case if you are using WPF application using PRISM framework then configuration should exist in your start up project (i.e. in the project where your bootstrapper resides.)
There seem to be several ways to create/fix this issue. For me, the CRM product I am using was written in native code and is able to call my .NET dll, but I run into the configuration information needing to be at/above the main application. For me, the CRM application isn't .NET, so I ended up having to put it in my machine.config file (not where I want it). In addition, since my company uses Websense I had a hard time even adding the Service Reference due to a 407 Proxy Authentication Required issue, that to required a modification to the machine.cong.
Proxy solution:
To get the WCF Service Reference to work I had to copy the information from the app.config of my DLL to the main application config (but for me that was machine.config). And I also had to copy the endpoint information to that same file. Once I did that it starting working for me.
Ok. My case was a little diffrent but finally i have found the fix for it:
I have a Console.EXE -> DLL -> Invoking WS1 -> DLL -> Invoking WS2
I have had both the configurations of the service model of WS1, and WS2 in the Console.EXE.config as recommended. - didnt solve the issue.
But it still didn't work, until i have added the WebReference of WS2 to WS1 also and not only to the DLL that actually creating and invoking the proxy of WS2.
If you reference the web service in your class library then you have to copy app.config to your windows application or console application
solution: change Configuration of outer project same the class library's wcf configuration.
Worked for me
I had the same Issue
I was using desktop app and using Global Weather Web service
I deleted the service reference and added the web reference and problem solved
Thanks
Solution for me was to remove the endpoint name from the Endpoint Name attribute in client web.config
this allowed the proxy to use
ChannelFactory<TService> _channelFactory = new ChannelFactory<TService>("");
only took all day to work out.
Also the contract name was wrong once this fix was in place although it had been wrong when the initial error appear.
Double then triple check for contract name strings people !!
attrib: Ian
Allow me to add one more thing to look for. (Tom Haigh's answer already alludes to it, but I want to be explicit)
My web.config file had the following defined:
<protocolMapping>
<add binding="basicHttpsBinding" scheme="https" />
</protocolMapping>
I was already using basicHttpsBinding for one reference, but then I added a new reference which required basicHttpBinding (no s). All I had to do was add that to my protocolMapping as follows:
<protocolMapping>
<add binding="basicHttpBinding" scheme="http" />
<add binding="basicHttpsBinding" scheme="https" />
</protocolMapping>
As L.R. correctly points out, this needs to be defined in the right places. For me, that meant one in my Unit Test project's app.config as well as one in the main service project's web.config.
I had this error when I was referencing the Contract in the configuration file element without the global scope operator.
i.e.
<endpoint contract="global::MyNamepsace.IMyContract" .../>
works, but
<endpoint contract="MyNamepsace.IMyContract" .../>
gives the "Could not find default endpoint element that references contract" error.
The assembly containing MyNamepsace.IMyContract is in a different assembly to the main application, so this may explain the need to use the global scope resolution.
When you are adding a service reference
beware of namespace you are typing in:
You should append it to the name of your interface:
<client>
<endpoint address="http://192.168.100.87:7001/soap/IMySOAPWebService"
binding="basicHttpBinding"
contract="MyNamespace.IMySOAPWebService" />
</client>
I got same error and I have tried many things but didn't work, than I noticed that my "contract" was not same at all projects, I changed the contract as would be same for all projects inside solution and than it worked.
This is project A
<client>
<endpoint address="https://xxxxxxxx" binding="basicHttpBinding" bindingConfiguration="basic" contract="ServiceReference.IIntegrationService" name="basic" />
</client>
Project B :
<client>
<endpoint address="xxxxxxxxxxxxx" binding="basicHttpBinding" bindingConfiguration="basic" contract="ServiceReference1.IIntegrationService" name="basic" />
</client>
Finally I changed for both as :
<client>
<endpoint address="https://xxxxxxxxxxx" binding="basicHttpBinding" bindingConfiguration="basic" contract="MyServiceReferrence.IIntegrationService" name="basic" />
</client>
I had the same issue and it was solved only when the host application and the dll that used that endpoint had the same service reference name.