Client Library Split

Topics: Developer Forum
Jun 10, 2009 at 9:29 PM

Hi there,

I'm trying to code some stuff with SharedCache (from SVN truck) but the Server/Client library mix is stepping on my foot.

Apparently is that the only 3.0 requirement really used is the DataContract serialization option. Does the client use it?

I'd like to propose for the more experienced SharedCache commiters to split the WinServiceCommon project into a client only project and a server one.

The idea is to mantain the client with 2.0 framework support while the server could evolve freely. As I said earlier, I'd like to see the client requirements being more restrictive.

This way more persons could code for the client library (the simpler entry point for any contributor) faster.

What are your thoughts on this?



Jun 11, 2009 at 5:41 PM

Hi Samuel,

to be honest i'm not sure if what would be the better way:

 - as you said to split it up into 2 libraries

 - usage of #ifdef regions

it would be intersting to know how much people would vote for something like this.



Jun 18, 2009 at 2:14 PM
Edited Jun 19, 2009 at 3:44 PM

I agree with Samuel.  Can be a good thing have two libraries; one for the server and one for the client.

Jun 18, 2009 at 5:26 PM

 i would like to point out also that we will have code dublication.

Jul 31, 2009 at 6:25 PM

What about generating a client stub from the existing common library? I can see benefits to a client only config/library, but I am not sure I follow keeping the client at a 2.0 vs 3.x runtime level. With 3.x being extensions to the 2.0 runtime, where would the issues be with having the required 3.x MS/.Net libraries on the box also?