Take the 2-minute tour ×

today i have a question regarding style of WCF communication.

I sometimes refuse a bit so use things programmatically (want to have control myself) and I don't like huge. Sometimes communication between 2 program parts are needed, sometimes on the same machine, sometimes on network.

So I tried to use WCF programmatically instead of using configuration files, svcutil and so on.

If I use the following:

a) Define a contract

    public interface IMyContract
        bool DoSomething(string something_in);

b) programm some code

public class MySomething: IMyContract
            public bool DoSomething(string something_in)
                      return false;
                return true;

and then programmaticly host it

Uri baseAddress = new Uri("net.tcp://localhost:48080/MySimpleService");

            using (ServiceHost host = new ServiceHost(typeof(MyContract), baseAddress))
                host.AddServiceEndpoint(typeof(IMyContract), new NetTcpBinding(), "");

                Console.WriteLine("<Enter> to stop the service.");


and later just consume it from another program:

var binding = new NetTcpBinding();
            var endpoint = new EndpointAddress("net.tcp://localhost:48080/MySimpleService");
            var channelFactory = new ChannelFactory<IMyContract>(binding, endpoint);

            IMyContract client = null;

                client = channelFactory.CreateChannel();
                bool test = client.DoSomething();
            catch (Exception ex)
                if (client != null)

what would be the drawback?

Wouldn't it be easier to understand?

Could such a thing cause other problems?

(I'm mostly interested in this, because I think it is quite annoying to use svcutil and so one just because of a class change, which can simple handled manually, if the wcf service is only used for cumminication of own programs) So what am I missing?

Is it just a bad style to do things manually instead with large unread XML files?

share|improve this question
If it's for your own consumption and doesn't require external network hosts/addresses then I don't see a problem. If you want to redistribute to 3rd parties/different machines with the service available over a network, separate config might be desirable. –  spender Jan 9 '13 at 13:08
I think your apporach is just fine. It depends on how often you think that the endpoint addresses and bindings might change etc. If it does so often and you have to recomplie and publish a new program every time they change this may be a hassle... –  mortb Jan 9 '13 at 13:10
one thing comes in mind. you can change configuration without recompiling the code. –  Nahum Litvin Jan 9 '13 at 13:12
We use exactly the same approach when writing code for a program to communicate with another instance of itself. We have never needed to change any of the endpoint names, in more than 5 years. –  Matthew Watson Jan 9 '13 at 13:16
add comment

closed as not constructive by bryanmac, mathieu, Jon B, stusmith, Obalix Jan 9 '13 at 14:19


2 Answers

up vote 3 down vote accepted

Your question can be divided into multiple parts:

Is it OK to hard code address?

NO. In the same way we don't hard code connection strings we also don't hard code paths to resources or services (at least not absolute paths). You never know when you would need to change it for any reason - for example to test a new version of the service. Use at least simple app settings if you don't want to use full endpoint configuration.

Is it OK to hard code binding and configuration?

If you don't expect to change it very often and if you are happy with recompiling and redeploying server and client every time you change it you can hard code it. The API provides this because it is valid use case.

Is it OK to share service contracts and data contracts between client and server?

Again it depends on the way how you expect the application will grow and how you expect complexity of deployment. Sharing assembly is valid use case if you have full control over both client and server code but you must remember that it introduces tight coupling between your server and client application. Svcutil is tool which helps you generating clients from SOAP services you don't have control over (you don't have their code or they are not written in .NET) or for clients where you want to follow loose coupling with a server.

I very often use configuration with shared contract assembly myself = no svcutil.


Anyway there is no technical drawback in coded configuration over XML configuration (some advanced configuration are even not available in XML). If a developer knows WCF he would understand both XML and code. If developer doesn't know WCF he would probably be more satisfied with the code because XML configuration may be hidden from him for a while.

share|improve this answer
With the address part itself i would agree (that is from example and would later come from database). Even given the fact that for the last larger program I was developing connection strings haven't changed for 5 years. Sometimes I also think it would be easier to hard code them and then change them once instead of having to much overhead... The second point: I have so far never seen that such configurations was changed before in several projects. compiling and deploying is done far more often for other reasons. –  Offler Jan 9 '13 at 13:41
But what I don't understand: how would it change something for contract. If the contract is changed for some reasons, I also would need to change the client. Sometimes a client can work on without change, but there errors could just be hidden. And yes: it is a tight coupling, but server and client application is in this use case... the same application. Just some communication between different machines (therefore later on there will only be a lot of configuration data (dif. machines) from a database - but it should not work over dif. versions (connected machines need same db ver and so on ) –  Offler Jan 9 '13 at 13:46
In such case you are fine with sharing those contracts. –  Ladislav Mrnka Jan 9 '13 at 13:51
add comment

It should work fine to do this programmatically. The main issue arises when you want to change something, or if an end user is required to change something. If the endpoint address or other config will change, it will be much easier to not have to recompile the code.

I would say that it would work out better to use a config file, that way the setup is kept in a separate place, and is easy to find when it's needed.

I would only opt to hardcode the config if you have good reason to want to hide it from the user (eg, you don't want them to see it/mess with it).

share|improve this answer
the only things which should change are hostname + port. They should come later from db. Clients then should be flexible created (only one computer in a config file won't fit at all). Therefore i do not wan't it in App.Config like in ms examples. (I was also mainly focussing on behaviour tags, automatic generated clients (i have never then anyone making a real audit on autogenerated tools, only on self written code - so everything which is not autogenerated is checked more carefully) and so on) –  Offler Jan 9 '13 at 13:52
@Offler You do have the option of reading in the config, and then choosing in code to either accept the config, or override it with a hardcoded value. This may allow you to offer some flexibility while also not being forced to setup one config file per machine. Equally, you can create a config file where there are blank fields, which are later filled in by your program. –  HaemEternal Jan 9 '13 at 14:21
add comment
