Hi guys,

I have been going crazy trying to solve the problem Mike Caito points out in this brief post:

http://geekswithblogs.net/thibbard/archive/2006/02/22/70375.aspx

We are trying to run a web deployment with an 'install from CD' option. Generally our users install from CD and recieve updates from our website. However, the first update after the CD install, doesnt copy data files into the new version’s DataDirectory. Any data previously entered is lost. Argh.

If we install from the web initially, it all works fine.

Note: Our DB is created and updated dynamically by running sql scripts. It is not published with the app, which is a common cause of the ‘data being lost after update�problem.

Has anyone got around this one before?

My solution was to store the database in a static location in the Application Data directory, then change the UserInstance Connection String (stored in My.Settings) to point to that static location. The only downside is that the custom location is not deleted during uninstall, but I don't see that as a huge problem. Here is a code example; note that the sub is placed within the MySettings class:


I hope that gets you started.

By the way, I also create and update my app's database using scripts. Make sure you create the database in the UserDBDir directory by referencing the value you created (My.Settings.UserDBDir). That means you have to create the reference in My.Settings before you create your database. To do so, make a call to get a setting value in My.Settings (any one will do), which will in turn trigger the SettingsLoaded event.

I think I will replace the entire ConnectionString programmatically, instead of just the |DataDirectory|, just in case I need to change the UserDBConStr value again.

Unfortunately this behavior is by design in Whidbey ClickOnce. Data is not migrated when a change in url happens.

To get around this you can do following:

- Have your app version 1.0 in CD.

- Do not mark the file(s) as data in CD (although you ultimately want them to be in data directory).

- Have an update version 1.1 in web, which is exactly same as version 1.0 bitwise (target file hashes must be same), except deployment and application manifest version is incremented to 1.1.

- In 1.1 mark your target files as data (writable type)(same fileswere non-data in 1.0). May be 1.1 is a required update.

- In that case when your user runs the application it will detect an update (1.1) and install it, but due to file level patching that ClickOnce have, no real download will happen (since you kept the file hashes same), and it should be quick.

- But this step will move your files to data directory andattach your update url with the data.

- Later when you release real update 2.0, you will see data being migrated (originally from CD).