There are 2 teams working on a product. One team is working on a server-side logic, exposed as a WCF service, the other team is working on implementing a front end (ASP.NET MVC web-site). What is a proper solution for sharing service API between those 2 teams? By API I mean a web-service interface + a bunch of DTO classes. We're using git and TeamCity for continuous integration. Service and front-end are developed and deployed independently. Based on this, options I see are: Put all "interfacing" stuff into a separate project and share it via git modules. Both client and server will share the code. Put all "interfacing" stuff into a separate project and publish it to private NuGet repository. Both client and server will reference the only common assembly. Put both client and server to the single VS solution and literally share the assembly. Option 3 feels like the most trivial approach, easy to implement and understand, but I'm not really excited with the entire idea of getting a larger solution. Options 1 and 2 feel pretty the same, though I just like option 2 better. What do you think is a better approach here? Any other solutions?

Reputation: 7694

Sharing WCF contracts for client and server

There are 2 teams working on a product. One team is working on a server-side logic, exposed as a WCF service, the other team is working on implementing a front end (ASP.NET MVC web-site). What is a proper solution for sharing service API between those 2 teams? By API I mean a web-service interface + a bunch of DTO classes. We're using git and TeamCity for continuous integration. Service and front-end are developed and deployed independently.

Based on this, options I see are:

Put all "interfacing" stuff into a separate project and share it via git modules. Both client and server will share the code.
Put all "interfacing" stuff into a separate project and publish it to private NuGet repository. Both client and server will reference the only common assembly.
Put both client and server to the single VS solution and literally share the assembly.

Option 3 feels like the most trivial approach, easy to implement and understand, but I'm not really excited with the entire idea of getting a larger solution. Options 1 and 2 feel pretty the same, though I just like option 2 better.

What do you think is a better approach here? Any other solutions?

Upvotes: 3

Answers (3)

Christian Hayter

Reputation: 31071

We use option 4 - client and server are in separate solutions, but both solutions contain the same WCF contract project (containing only [DataContract] and [ServiceContract] definitions) and reference it with a project reference rather than an assembly reference. It may sound funny but it works just fine.

Both solutions can be built separately and they both get the same DLL, because whichever order they are built in, the second build will not recompile the DLL because it is already up to date.

The major advantage of this as I see it is, when someone makes a source code change to the contract project, the change is instantly available to both client and server code without having to "refresh" anything. This cuts out arguments like "I did make that change", "no you didn't", "yes I did", "well I can't see it", etc.

Upvotes: 6

Grzegorz Sławecki

Reputation: 1797

We do store our common code in a separate solution. It produces .dll's which are added as a simple assembly references to multiple other projects which depend on them.

All builds are defined in nant files, and we do got some .bat files which run the builds in appropriate order.

When You just want to build the project from VS, the dependent .dll most probably is already built. If You want to be 100% You got everything is built with latest changes, You run those bat scripts which will trigger nant builds and rebuild everything.

Upvotes: 2

Denny

Reputation: 129

In my project we used the similar way as you described in option 1 sharing codes

Upvotes: 1

Sharing WCF contracts for client and server

Answers (3)

Related Questions