Package up a WCF client into an assembly for consumers

Question

I'm hosting a WCF service within an organisation, and I was hoping to build a client into an assembly DLL to package up and give to anyone who wants to consume the service.

I could create a class library and simply add a service reference, build that, and distribute that. Any recommendations on an alternative approach?

score 1 · Answer 1 · answered May 26 '11 at 06:52

1

I did something similar in my previous organization. I also had the additional requirement that the library should be COM visible so that a legacy C++ application could consume the API.

I went so far as not requesting the client to provide any WCF configuration, beside passing a bunch of parameters through the API (service URL, timeouts, etc...). The WCF was configured programmatically. I was in a very tightly controlled environment, where I exactly knew the clients of the library and could influence their design. This approach worked for me, but as they say your mileage may vary.

answered May 26 '11 at 06:52

Stefano Ricciardi

2,923
3
33
40

I'm intesterested to know how I can set the WCF configuration in code. Can you provider any pointers on how to do this? – TesterTurnedDeveloper May 26 '11 at 07:07
You should be able to google it. Try starting here: http://stackoverflow.com/questions/2943148/how-to-programmatically-connect-a-client-to-a-wcf-service – Stefano Ricciardi May 26 '11 at 07:39

Paul · Answer 2 · 2011-05-26T04:36:57.330

0

What's the service host going to be? If it's going to be an HTTP based one, putting it into an ASP.NET app makes a lot of sense. Otherwise, yeah, fire up the class library.

UPDATE based on comment

The client packaging really depends on what the receiver is going to do with it. If you're targeting developers, or existing in-house apps, then the library is a great option (though I'd probably wrap it in an .msi to make the experience familiar for users). If there needs to be UI then obviously you'll want to think about an appropriate UI framework (WPF, Silverlight, WinForms, etc)

edited May 26 '11 at 04:36

answered May 26 '11 at 04:23

Paul

35,689
11
93
122

sorry, my question was vague. i actually want to package up the client, not the service – TesterTurnedDeveloper May 26 '11 at 04:27

score 0 · Answer 3 · answered May 26 '11 at 04:31

At my prior job we always did this. We'd have a library project that contained nothing but a SVCUTIL proxy generation and the config file to go with it.

This way our other projects could utilize this library and we'd only ever have one proxy generation. Great in a SOA model.

In your case you could then distribute this assembly if you wanted. Personally, I find the benefit greater for internal cases you control, but I suppose if you really felt charitable, distributing a .NET version for clients to use would be beneficial.

score 0 · Answer 4 · answered May 27 '11 at 01:18

I would simply provide a library that contains all the required contracts. That's it - they can write their own client proxy.

Do your users know how to use WCF? If not, include a proxy class that instantiates a channel and calls the service.

I don't really see any point in providing an assembly that just includes code generated by svcutil. Why not just give your users a WSDL and then they can generate that code themselves? Distributing boilerplate doesn't seem like a great idea.

Package up a WCF client into an assembly for consumers

4 Answers4