The situation:

  • My company delivers an installed Windows Forms application to our clients.
  • This client application comes bundled with an object binary (let's call it Objects.dll)
  • Objects.dll contains the object properties, fields, method signatures, etc.
  • Objects.dll also contains the Service Contracts (interfaces), used by the object to communicate to a remote web service
  • The remote web service (let's call it Service.dll) is hosted remotely, along with Objects.dll. It implements the Service Contracts in Objects.dll

The problem:

  • When the Objects.dll changes in any way (including the Service Contracts), an update must be sent out to the client application. Updates like these require 48+ hour notice, and a pretty hefty middle of the night maintenance window. This is painful, and it goes against our internal development credo of having low-impact deployments.

The hope:

  • There exists a tool/product/service that allows some level of decoupling of the object tier from the client application. I'm envisioning some service/object discovery service for the client application to communicate with in order to get the object tier.

It's possible that a solution doesn't necessarily exist. While that would be less than ideal, I'm fully anticipating this solution.

  • When you say "updates like these," don't you have to change the client anyway, if the Service Contract changes? Or is your intention to push updates to the client without ever changing any classes? Aug 1, 2016 at 21:55
  • @RobertHarvey - Yes. When I said "updates like these," I meant "updates that are pushed out to clients." This includes when the Objects.dll changes in any way, which includes Service Contracts changes. In my "perfect world" scenario, which may not be realistic, I would like to have the application "self-aware" of the implementation of the Objects.dll, so it doesn't need an application update, but can just update its internal implementation. Aug 1, 2016 at 21:57
  • How do you update the Winforms application? Aug 1, 2016 at 21:57
  • @RoberHarvey - It checks against a homegrown update web service that, upon version increase at the web service layer, downloads the updated binaries in a separate process. Aug 1, 2016 at 21:58
  • And the Objects.DLL is not part of this feed? Aug 1, 2016 at 21:59

1 Answer 1


You need another layer

When you see problems like these, it is an indication that your solution is missing a layer of abstraction. There ought to be something that has a fixed, public interface and a private implementation which isolates the caller from underlying changes. There are three places you can put it: where you add it can depend on project concerns such as who is going to do the work and whose budget will pay for it.

At the service end

Ideally, the folks developing the service would provide a layer of abstraction between the API and the business logic, e.g. an interface, which is generic enough to avoid frequent changes. If a data type or parameter name changes in the underlying infrastructure, the service would isolate the caller from those changes by mapping existing interface elements onto the new structures or delegates. A new interface should only be needed when there is significant change in functionality (in which case you'd need to revise the Windows application anyway).

At the client end

If they are not willing to do that, you can add an adapter layer on the client side which would have a fixed public interface and a private implementation that deals with the raw service APIs. You'd need this adapter to be distributed in the same package that contains updates to objects.dll. And ideally it would be built as part of the continuous integration build for objects.dll to ensure compatibility.

In the protocol

If you use a RESTful protocol, the client can dynamically discover any new interface elements using the Uniform Interface.

If you use a JSON sort of protocol, the server and client can support new interface elements via duck typing.

If you are using WCF, you can use lax versioning to alleviate the problem. Under this pattern, removal of existing interface elements will still break the solution, but you can add new elements without breaking it.

  • +1 for the lax WCF versioning. It really should be the default and I believe OP is using WCF, even though they didn't state it explicitly.
    – RubberDuck
    Apr 18, 2017 at 16:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.