I was going through new WCF 4.5 features http://msdn.microsoft.com/en-us/library/dd456789.aspx and was trying out Simplified Generated Configuration Files. When i generate the config files in 4.0 and 4.5 both of them are same. They do not have default values.
Am i missing something here ?
Although I can't find anything specifically on 4.0 vs 4.5, the link you referenced shows a config file first for 3.0 and then one for 4.5.
Beginning with 4.0, simplified config files were introduced that had the concepts of default bindings and default endpoints - meaning that you could create an out-of-the-box WCF service application in 4.0 or 4.5 and there would be no binding or endpoint defined - you can verify this by looking at the web.config files for your 4.0 and 4.5 service.
When you add a service reference, you most likely used an "http://" URI - by default, "http" maps to basicHttpBinding. So let's look at the snippet you posted in the comments:
<endpoint address="localhost:36275/Service1.svc"
binding="basicHttpBinding"
bindingConfiguration="BasicHttpBinding_IService1"
contract="ServiceReference1.IService1"
name="BasicHttpBinding_IService1" />
Everything the client needs to communicate with the service is there - the address, the binding to use, the binding configuration to use and the contract.
If you look in the client config file, you should see the following as well:
<bindings>
<basicHttpBinding>
<binding name="BasicHttpBinding_IService1" />
</basicHttpBinding>
</bindings>
Which corresponds to the binding specified by the endpoint's bindingConfiguration attribute. Since the defaults are being used, the other properties for the binding are not specified.
In 3.0 and 3.5, the binding section would have had all the properties of the binding specified with default values - in 4.0 and later it does not.
You're not missing anything - other than the documentation being a little misleading in that it implies this is a 4.5 feature, when it reality it's a 4.0 and 4.5 feature.
Related
note: A github repo has been constructed to demonstrate the issue causing these questions.
In creating a WIF secured WCF service, the MSDN documentation recommends using the Identity and Access Tool for visual studio. Upon running the tool on the service project, the following node is added to the web.config [commit 0472287]:
<ws2007FederationHttpBinding>
<binding name="">
<security mode="Message">
<message>
<issuerMetadata address="https://localhost/adfs/services/trust/mex" />
</message>
</security>
</binding>
</ws2007FederationHttpBinding>
The identity tool adds an incorrect issuerMetadata address and does not include the issure node at all. All of the nodes which reference certificate thumbprints are, thankfully, created correctly. Adding a service reference to a client project for this service results in an invalid configuration on the client. Upon changing the content of the message node as follows, creating a service reference to the service leaves a nearly usable client (see second question) [commit 758052d].
<message>
<issuer address="https://localhost:44300/issue/wstrust/mixed/username" binding="ws2007HttpBinding" bindingConfiguration="" />
<issuerMetadata address="https://localhost:44300/issue/wstrust/mex" />
</message>
First Question Is there something I am doing wrong in setting up the identity tool that is causing the binding to not be configured properly? The address that is generated does not exist in the STS FederationMetadata.xml file so I am not sure where it is coming from.
After properly configuring the service, the service reference for the client is nearly plug and play. For some reason, it doesn't specify a binding configuration for the issuer in the WS2007FederationHttpBinding. Adding a binding and creating a binding configuration for the WIF client to get a token from will cause the client to be in a working state [commit 39a4cbc].
Second Question Updating the service web.config allowed the rest of the client configuration to be generated automatically. Am I missing something for the client to also get the binding auto configured?
All of these missing elements are able to be looked up in the FederationMetadata.xml file the identity tool requires as well as on the FederationMetadata service which both projects become aware of. It seems that there should be something to cause these to be configured correctly without need of manual intervention.
note: A github repo has been constructed to demonstrate the issue causing these questions.
Still finding my way with Castle.Windsor and the WcfFacility, but this ones got my head scratching. I'm want Windsor to inject the WCF client where it sees that dependency in my repository.
I've added a service reference in Visual Studio and added the following into my bootstrapping code:
container.AddFacility<WcfFacility>();
container.Register(
Component.For<IServiceContract>()
.AsWcfClient(
DefaultClientModel.On(
WcfEndpoint.FromConfiguration("MyEndpoint")
)
)
);
My web.config contains a <client> section with a endpoint named accordingly:
<client>
<endpoint address="http://localhost:63988/MyService.svc"
binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_IServiceContract"
contract="IServiceContract"
name="MyEndpoint" />
</client>
When I run my app, I get a YSOD:
Could not find endpoint element with name 'service' and contract
'IServiceContract' in
the ServiceModel client configuration section. This might be because
no configuration file was found for your application, or because no
endpoint element matching this name could be found in the client
element.
Pretty self explanatory but why is it looking for an element with name "service", my element is named "MyEndpoint" which I've correctly passed to the FromConfiguration method?
If I update my web.config to change the name attribute from "MyEndpoint" to "service" - the YSOD is gone and my page works!
<client>
<!-- Changing the name attribute to "service" works? -->
<endpoint address="http://localhost:63988/MyService.svc"
binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_IServiceContract"
contract="IServiceContract"
name="service" />
</client>
It seems like the facility is ignoring the endpoint name I've given it?
Or (more likely) I'm not registering my service correctly and the facility is using some naming fallback.
EDIT
It seems that my endpoint name attribute has to be "service"! In every test I've tried I always get the same error if the attribute is any other value - is this a bug?
Cheers
OK - I've managed to get past this problem.
I wrote a simple test harness of one MVC and one WCF and used the WcfFacility with no problems - this gave me the confidence that it does work ;o).
I was using an existing codebase and refactoring to use the WcfFacility so I binned my original changes and started again. This time round, I had no problems.
I suspect I must have missed some duplication in the web.config within the <system.serviceModel> elements - although I swear it was OK!
Cheers
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 am writing a WCF Service Application in Visual Studio 2010 using .NET Framework 4.0.
I am trying to implement BasicHttpBinding with HTTPS. I read in some example that I need to create a custom binding as follow and to set it as "bindingConfiguration" attribute while setting up an endpoint.
<bindings>
<basicHttpBinding>
<binding
configurationName="UsingHttps"
securityMode="Https"/>
</basicHttpBinding>
</bindings>
However, when I try to write similar in my web.config, the intellisense is not showing "configurationName" and "securityMode" attributes. What can be the reason here? Do I need to change any setting in Visual Studio IDE?
Any help on this, much appreciated.
Thanks
Nirman
You have got the attribute names wrong, and tried to set the security mode in the wrong place:
<binding name="myBindingName">
<security mode="Transport">
...etc...
</security>
</binding>
This old (July 2007!!) MSDN article has plenty of examples of both programmatic and static configuration of bindings, transport security, etc: WCF Bindings In Depth (the whole magazine is now packaged as a CHM download, but you can see the specified article directly online on wayback machine).
I'm developing a Winforms Client application with a WCF Service in C # 3.5 and Visual Studio 2010.
Every time I use "Update Service Reference" in the IDE, considering I have already a working binding in app.config, an additional binding entry is generated with the same name and a trailing "1".
My app.config on the client side is :
<bindings>
<wsHttpBinding>
<binding name="WSHttpBinding_IIssueTracker" closeTimeout="00:01:00"...
After a "Update Service Reference", I have :
<bindings>
<wsHttpBinding>
<binding name="WSHttpBinding_IIssueTracker" closeTimeout="00:01:00"...
<binding name="WSHttpBinding_IIssueTracker1" closeTimeout="00:01:00"...
So I need to remove this unused binding all the time.
This is driving me nut. Is there a way to disable this behaviour ?
The way we solved this was to move the Service Reference to a separate library, and delete the (newly generated) app.config from the library project after executing Update Service Reference.