3

Our application uses ClickOnce for admin-less deployment by the user to their computer. The app has a SqlServerCE database that contains sensitive data. A requirement is that the db password be changed at deployment and every 20 days afterwards (configurable). We are handling the db password change, connstring change and encrypting the connString section of the app.config file ok.

The problem is with a subsequent ClickOnce deployment. If the newly deployed database is different from the initial deployment (hash value in manifest is changed), there is no problem. The new db replaces the old one and has the initial default password that is updated immediately.

When the newly deployed database is the same as the initial deployment (hash value in manifest is the same) there is a problem. ClickOnce rolls the old database into the new deployment, but the application no longer has access to the password. It's in the old app.config file and this is not rolled forward. You would think that at least the connection string section would be rolled forward when the db is, but I guess that’s asking too much.

So okay, not a problem. We added code to copy the current password into a user.config file. Now at deployment, if the app cannot open the db, it grabs the password from user.config and updates the connstrings in app.config. ClickOnce appears to automatically copy the contents of the old user.config and creates the new user.config without the app having to do something like call settings.default.upgrade() and .Save().

But this doesn't work if user.config is encrypted. Seems like ClickOnce attempts to copy data from the old u.config file to the new one but fails because of the encryption. So it simply contains whatever data is deployed in userSettings of app.config.

Is there any mechanism to access the old user.config file, decrypt and fetch the data it contains? Both the old and new user.config are available in the ClickOnce data folder set, but I don’t want to write code that attempts to locate the old file manually.

ClickOnce is a beast when it comes to the security of local data. It just isn’t helpful. If I can’t get user.config to work, I will have to place a file in some user accessible area that is outside of ClickOnce’s grasp and manage password data from there. The contents would be encrypted of course.

shawn
  • 31
  • 1

0 Answers0