I think my question is rather simple, so I'll stick to the point:
Is it by any means possible to expose a service without specifying the services element and only the serviceHostingEnvironment element? I.e. would the below configuration be enough to host a WCF service? I'm asking because i've seen applications that - as far as I can tell - lack the services element, and I thought that was mandatory.
<serviceHostingEnvironment multipleSiteBindingsEnabled="true">
<serviceActivations>
<add relativeAddress="Service.svc" service="Namespace.To.My.Service" />
</serviceActivations>
</serviceHostingEnvironment>
With WCF 4.0 you don't need explicit service configuration as opposed to prior versions. It automatically adds default endpoints if no endpoints are defined explicitly.
Whatever configuration you mentioned in question is called File-less activation and you can activate service without even having physical .svc file. In WCF 4 you can define virtual service activation endpoints like one you have defined.
WCF detects what contracts are implemented by service and then method AddDefaultEndpoints adds one default endpoint per base address for each service contract implemented by the service. Note that this behavior is only when no explicit endpoints are added (either programmatically or through configuration). Should you add one explicit endpoint WCF stops adding default endpoints and it gives control to developer to customize it further.
Related
I have a single service, one backing binary, that I want to configure to have two different endpoints. The problem is, I want a different serviceBehavior for each endpoint, to specify different security requirements.
E.G:
<service behaviorConfiguration="behavior1" name="MyServiceClass">
<endpoint address="endpoint1" bindingConfiguration="binding1" contract="IMyServiceContract"/>
</service>
<service behaviorConfiguration="behavior2" name="MyServiceClass">
<endpoint address="endpoint2" bindingConfiguration="binding2" contract="IMyServiceContract"/>
</service>
Is such a WCF configuration valid, or attainable in another format?
I'm not sure you can do it from config only, but there exists a code and config solution based around the extensibility point exposed by the IEndpointBehavior interface. This allows you to define behaviors at the endpoint level.
It's not particularly well documented as I don't think it's used very often. According to MSDN:
Endpoint behaviors, which implement IEndpointBehavior, are the primary
mechanism by which you modify the entire service or client run time
for a specific endpoint.
There are two mechanisms for adding endpoint behaviors to a service.
Add the behavior to the Behaviors property.
Implement a custom BehaviorExtensionElement that extends
configuration.
Specific examples of the first option exist here, and here, but I can't find anything about the second.
What is the difference between the Service node/section and the Client node/section in the configuration section? Why configure endpoints in one section over the other? Which is best for interoperability?
I'm currently building a service that talks to another service. I have endpoints for my clients and endpoints for the other service. Visual Studio seems to lump all the endpoints into the Client section.
I thought that client node was for your consumption and service node was for producing. But when you create a new wcf service visual studio puts your new service endpoint settings under the client node. I have moved my endpoint between both sections trying to figure out what the difference is.
When should I use service over client?
<system.serviceModel>
<services>
<service> <!--I noticed some tutorials and using wcf config edit tool
puts producer endpoint settings here -->
<endpoint blah settings/>
<endpoint blah settings/>
</service>
</services>
<client> <!--Visual Studio puts both producer and consumer endpoint
settings here -->
<endpoint blah settings />
<endpoint blah settings />
<endpoint blah settings />
</client>
<bindings>.....
</system.serviceModel>
Many settings in the WCF web.config (or app.config for that matter) can be shared for both consumers of a service as well as publishers of a service including:
Bindings
Endpoint Behaviors
Diagnostics
However as you have discovered, some config is specific to a service. A well-written service usually specifies:
It's base address. This is a convenience when defining a service as it allows your to define endpoints using relative addresses. Clients however don't use this particular setting as they need an absolute path. For this reason it makes no sense to specify in the section
Services can also be clients. If the client and server endpoints were all plonked together, WCF would not be able to know which should utilise the base address for one thing
Service behavior
By dividing up config between client and server, WCF is better able to know where to look for endpoints.
Which is best for interoperability?
I don't think that has anything to do with it. WCF is a means to achieve interopability but just by using WCF does not imply you will achieve it. Interopability is established when both parties agree on say a particular service contract; canonical data model; data transformation; message version or many of the other patterns as defined by SOA Patterns.org So there are various patterns you must follow. e.g. If you change a method on service contract but have not updated the clients then you have broken interopability by breaking the schema of the service.
Visual Studio seems to lump all the endpoints into the Client section
If your WCF process is both a consumer and producer of WCF services then it should not be putting all the endpoints under
I'm able to run the WCF-SecureProfile sample that comes with the MSFT WCF samples download (http://msdn.microsoft.com/en-us/library/ee818238.aspx)
However I can't port this server component to IIS. I get the error that
<MakeConnectionBindingElement/> can't be loaded. Considering that I have the behavior extensions loaded I don't know why IIS can't see the extension, however the self-host version of my app can.
I uploaded the sourcecode of the project into codeplex for easy browsing. Here is a direct link to web.config and all other files.
2
I got the sample and set it up to run on IIS local. I didn't get the same issue as the one in this question but I did run into a big gotcha. Accessing the service in IIS gave me this error message:
Contract requires Duplex, but Binding 'BasicHttpBinding' doesn't support it or isn't configured properly to support it.
After some head scratching, I found the cause of this issue. WCF 4 now assigns default bindings to each transport (I'm liking this feature less & less). For the HTTP transport, the default binding is basicHttpBinding. The problem is the customBinding config does not override any default binding. This causes WCF to attempt to configure duplex over basicHttpBinding which of course isn't supported. The fix is to turn off the default transport mapping for HTTP and assign it to your custom binding as shown below for this service:
<protocolMapping>
<clear/> <!-- removes all defaults which you may or may not want. -->
<!-- If not, use <remove scheme="http" /> -->
<add scheme="http" binding="customBinding" bindingConfiguration="rspBinding"/>
</protocolMapping>
Once I added this to the serviceModel element, the IIS based service worked just fine.
Is there a way to do this globally, automatically for all my WCF services via configuration in WCF 4.0?
That is, I know WCF 4.0 exposes new configuration techniques that applies certain behaviors by default to all hosted endpoints, and that you don't need to explicitly specify individual endpoints by config anymore...but can I do something in the config that says to automatically host all services with both a BasicHttpBinding and a WebHttpBinding (using a /web relative address for the WebHttpBinding)? Or do I still need to use a custom ServiceHostFactory for this?
Thanks.
See the Developer's Introduction to WCF 4 for lots of interesting stuff in WCF 4.
One of the new features is called default protocol mapping, and this combined with the default endpoints provided by WCF 4 might solve your problem.
Default endpoints means that WCF 4 will provide one endpoint for each contract your service class implements (typically only 1), and for each base address defined in your config (or code for the ServiceHost).
In order to make sure a http:// endpoint gets exposed automagically with the webHttpBinding, you also need to override the system default (which is basicHttpBinding) - which you can do thanks to the protocol mappings.
<configuration>
<system.serviceModel>
<protocolMapping>
<add scheme="http" binding="webHttpBinding"/>
</protocolMapping>
</system.serviceModel>
</configuration>
How can I share my asp.net session with wcf session .
Say I have a Session["UserId"] in my asp.net application . I want to access this inside the WCF Signature .
I enabled aspNetCompatibilityEnabled="true" in Webconfig & [ServiceContract(SessionMode=SessionMode.Required)] in WCF.
I don't want to pass this session as an argument .
How can I achieve this?
You can't share an ASP.NET Session with WCF instance since they are in different Application Domains and could well be on different machines.
Here's a good article on Instance Context Sharing which will get you some way with "persistence session" in WCF. Then it's a question of passing shared data over the wire (or by using a common resource/database etc)
If you add this under <serviceModel> in your Web.config, it will work.
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
It probably decreases performance a bit.