In a WCF application we have a servicecontract with attributes:
namespace We.Work {
[ServiceContract(Namespace = "We", Name = "IWork", SessionMode = SessionMode.NotAllowed)]
public interface IWork
an implementation of the servicecontract with attributes:
namespace We.Work {
[ServiceBehavior(Name = "Work", Namespace = "We",
IncludeExceptionDetailInFaults = true,
InstanceContextMode = InstanceContextMode.PerCall,
ConcurrencyMode = ConcurrencyMode.Multiple,
ReleaseServiceInstanceOnTransactionComplete = false
)]
public class WorkImplementation : IWork
a servicehost (windows service or console application for development)
namespace We.Host {
// ....
workServiceHost = new ServiceHost(typeof(We.Work.WorkImplementation));
workServiceHost.Faulted += new EventHandler(Host_Faulted);
workServiceHost.Open();
and last but not least an app.config:
<service behaviorConfiguration="WorkServiceBehaviour" name="We.Work.WorkImplementation">
<endpoint behaviorConfiguration="WorkEndPointBehaviour" binding="wsHttpBinding" bindingConfiguration="WorkWsHttpBindingConfig" name="WorkEndPoint" contract="We.Work.IWork"/>
<host> <baseAddresses> <add baseAddress="http://.../Work.svc"/> </baseAddresses> </host>
</service>
<behaviors>
<endpointBehaviors>
<behavior name="WorkEndPointBehaviour">
<dataContractSerializer maxItemsInObjectGraph="2147483647"/>
</behavior>
</endpointBehaviors>
<serviceBehaviors>
<behavior name="WorkServiceBehaviour">
<serviceDebug httpHelpPageEnabled="true" httpsHelpPageEnabled="true" includeExceptionDetailInFaults="true"/>
<dataContractSerializer maxItemsInObjectGraph="2147483647"/>
<serviceMetadata/>
<serviceThrottling maxConcurrentCalls="25" maxConcurrentSessions="25" maxConcurrentInstances="25"/>
</behavior>
</serviceBehaviors>
</behaviors>
Questions: Is it possible to mix app.config and attributes, which configuration has precendence, what is a good practice?
E.g. does ServiceContract(SessionMode = SessionMode.NotAllowed) prevent wsHttpBinding from using sessions?
[Answered: how can I be sure the settings in app.config are really applied -- the fully qualified name works.]
The service name attribute in the config file must be the fully-qualified name of the service class for WCF to pick up the configuration automatically.
It is possible to mix config and code. However, there is no precedence as such. WCF will read the config file when you instantiate the
ServiceHost
. If you want to set additional properties in code, they will overwrite what's already there.Best practice is entirely up to you. The purpose of the config file elements is to decouple the service configuration and implementation, which may or may not be a consideration in your deployment.
UPDATE
Attributes on the service class code are a different story. The purpose of some attributes are to let the developer say "I demand config that is consistent with this attribute, or my service won't run as designed". Therefore, although attributes won't actually override config, WCF will check that config is consistent with attributes and refuse to start the service if they are not consistent.