Wcf: System.ServiceModel.Configuration option for .Net Standard 2.0

[jannavarro]

2236 says that System.ServiceModel.Configuration is not in the .Net Core version. I have a project targeting .Net Standard 2.0. Are there any options for me to be able to use System.ServiceModel.Configuration?

Is there any .Net Standard version available?

[TPucke]

Upvote for this issue, especially class BehaviorExtensionElement

[DanielLaberge]

All we require is BehaviorExtensionElement so we can implement IClientMessageInspector.

[mconnew]

There are a couple of reasons why we won't be bringing the Configuration api's to WCF.
The Configuration api's aren't a part of netstandard
WCF can't use any API's which aren't a part of netstandard on our public surface area. While there are some configuration api's as part of .Net Core, if we were to reference those, you wouldn't be able to use our nuget packages on anything except .Net Core. This would exclude UWP, Xamarin and the full framework.

Configuration in WCF is messy/confusing
The Configuration story with WCF on the full framework can be very confusing. There are two sets of classes for configuring WCF, those used in config which are derived from System.ServiceModel.Configuration.ServiceModelConfigurationElement and those used in code derived from System.ServiceModel.Channels.BindingElement and System.ServiceModel.Channel.Binding. Trying to work out how to convert from one to the other can be difficult. This can cause problems when trying to find a solution to a particular problem. If you find a blog post or documentation which looks like it might solve your issue but it's using Configuration and you aren't (or the other way around), then it can be difficult to see if it solves your problem and to create a prototype to test the solution.

So what's the answer as hard coding everything will get even more annoying when you need different behavior in different environments? E.g. a different endpoint in development and production. Ideally there should be one set of classes to handle configuration. This should be achievable using the new Asp.Net Core configuration mechanisms. I was going to put together an example with how to use asp.net core configuration with WCF but other priorities haven't left me with the time. The idea is to use the configuration classes to deserialize the configuration to POCO, which would be the same types used for configuring WCF in code. For example, you would ideally be able to deserialize from your config an instance of BasicHttpBinding which you can pass to a ChannelFactory. I suspect there may be some issues with this initially where some properties/settings will fail to deserialize. If this is the case, let me know and I will either find a work around or come up with a product change which supports that scenario.

[ssashok10]

Here is an example which works for us,

    // Initialize configuration
    public static IConfigurationRoot config = new ConfigurationBuilder()
            .SetBasePath(Directory.GetCurrentDirectory())
            .AddJsonFile("config.json", optional: true, reloadOnChange: true)
            .AddEnvironmentVariables() // remove this line if you are not working with Azure Functions
            .Build();

          // Read configuration value
            config.GetSection("YourKey");

This code works for any local JSON configuration file as well as for function app "AppSettings".

[mconnew]

@DanielLaberge, you don't need BehaviorExtensionElement to implement IClientMessageInspector. Take a look at this example of a behavior which is used in one of our scenario tests. Immediately below it is the implementation of IClientMessageInspector which the behavior installs. You can see how the behavior is added to a class derived from ClientBase<TChannel> (such as is generated by WCF connected services) here. Alternatively if you are instantiating a ChannelFactory<TChannel> yourself, then the code is very similar as ChannelFactory has an Endpoint property too.

[mconnew]

@ssashok10, that is great if it's a single value you wish to switch between such as the remote endpoint. If your situation is more complex, or you want to be able to change arbitrary values after an app has been deployed such as MaxMessageSize without having to make a code change, then I was thinking something more along the lines of this where you can bind to a whole object graph. The ideal would be to be able to do something like this:

var binding = config.GetSection("Production:Binding").Get<BasicHttpBinding>();
var endpoint = config.GetSection("Production:RemoteAddress").Get<EndpointAddress>();
var factory = new ChannelFactory<IMyService>(binding, endpoint);

[StephenBonikowsky]

@mconnew Has explained why we cannot bring config to Core.