Client-server app: auto-update from local server or versioned interface?

I have a client/server application and I'm looking for some advice about how to handle the interface between the two. The Server/clients will be deployed over a LAN (potentially WAN, but definitely customer-managed, not centralized server). I'm considering these two options:

1. Client and Server can be different versions. This way, the WCF interface between them has to support versioning - if one has been updated and not the other, app still needs to work.
2. Server pushes updates to client, client auto-installs update before communicating. No versioning required, as the server won't communicate with an out-of-date client.

The client is a Window service that's running as LocalSystem, so there are no permissions concerns with an auto-update. #2 seems cleaner, as there's no interface versioning to keep track of, but I'm afraid I'm missing a really obvious reason to not do this in favor of #1. The client app is small - under 500K - so the bandwidth of pushing out updates (which I don开发者_Python百科't expect to be frequent) isn't really a concern either.

---

I might recommend a combination of the two. First off, set a baseline for what version of the WCF libs, you wish to use, which includes System.Serialization since it includes the DataContract attributes.

Define these versions explicitly in your references so that if you upgrade the .NET version, it will continue to use the old version and not the new. Then, you should be free to upgrade all other referenced libraries without concern over the upgrades affecting your interface.

As far as implementing the second option, I would almost recommend setting up a second service on the client that deals solely with getting upgrade information from the server. If it is necessary to upgrade the WCF libs, then those updates could be pushed (however, this probably won't happen very often).

---

Go for auto update. Versioning brings in a complexitiy that you simply can do without in this scenario.