Content download from within a Windows client - Best Practices

Our application is a Windows client (C++/MFC migrating to C#) that uses SQL Server Express as its data store. We release regular updates to the data the application works with. (Our users use the content data we provide as a basis for their own projects built using the client; the database stores their projects as well, to enable collaboration across a network).

F开发者_StackOverflow社区or a while we've used the archaic method of providing huge "update packages" containing all of the latest data. The updater would have to be run on the server, and would swap out the database files with the ones included in the package. Yes, horrible practice for many reasons. We want to do away with it.

Specifically, we will provide an update dialog wherein the user checks off the items they want updated, then clicks Update. A background process then pulls the selected items from the content server and inserts it into the user's database.

What's a secure way to pull this data from inside a Windows client, given that they may opt in or out of potentially hundreds of separate items?

I have considered:

• Remote connection to a SQL server. Query for the data directly. Easy to implement, but not secure. Searching for better ways to do this turned up suggestions to use VPN or SSH, neither of which seems particularly convenient for our customers to set up on their client machines.
• HTTP content service that provides zip files of each separate content item. Or it builds then dynamically per the user's request. (e.g., we submit an XML file listing the desired items, then a server-side process exports the data from the sql server and zips it up into one package).

How do other apps featuring in-program content updates do it? Any suggestions for heading in the right direction (or at least a good one)?

Thanks, D

Edit: We aren't necessarily concerned about whether the data transmission is secure (the content is not sensitive data); by "security" in this case I mean "is there a better way than exposing a remote SQL server to slammers in China".

Exposing SQL Server directly is generally a bad idea. Use webservice, WCF instead.