Reputation: 33944
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:
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't expect to be frequent) isn't really a concern either.
Upvotes: 1
Views: 556
Reputation: 3601
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).
Upvotes: 1
Reputation: 62157
Go for auto update. Versioning brings in a complexitiy that you simply can do without in this scenario.
Upvotes: 0