CUdev-Bob

Hi all,

I just finished my first WM 5.0 smart device application. I'm now ready to deploy it to devices, but first I am trying to address where the files get put by the CAB file that is generated by my Smart Device CAB project. I do not know how to handle the database file however, as I would like it to go in a non-volatile directory on the device, whereas the executable itself can go in volatile, as the CAB will be in non-volatile and can just re-install.

For my application, I know I can put it in the executable in the Program Files directory (%CE1% in the .inf file). But depending on how the device is set up that the user will be using, it may or may not have a storage card. If it does, I want to put the the .sdf there. Otherwise in the IPSM directory if the OEM implements it, or lastly in the My Documents as a last resort.

Does anyone have any ideas on how I can do this, or a better idea of how this should be handled Thanks in advance for any support.

Regards,

Bob




Re: Smart Devices General Deploying *sdf database files via a CAB Builder project

Christopher Fairbairn

Hi Bob,

I am not aware of a way to specify in a Smart Device CAB project (the .inf file) that you want a file to be installed to a Storage Card, apart from the obvious way of hardcoding a file path (i.e. don't use a %CExx% prefix). However if you go this route, obivously the installation is highly device specific due to the different names and paths the storage card could have on different device types.

I think this is not supported by CAB deployment projects due to the ambiguity it might cause, for example where would you install the files, if I a device had two storage cards inserted

Three alternative approaches come to mind.

  • Do you need to implement this at all, if you are only wanting to do this for recovery in case of accidental hard resets perhaps with the advent of persistant storage in Windows Mobile 5.0 you need will be reduced. If you leave the SDF file in your program folder, the user will need to explictly perform a hardreset in order to loose the database, and simple things (which in the past would have lost the SDF) such as the battery going flat will not cause the SDF to be lost.
  • You could deploy the default SDF file into the program folder, and on initial startup enumerate a list of storage cards (look on the forums for posts on how to detect storage cards). You could then copy the SDF file to the selected storage card, and perhaps provide a user configuration option to allow them to select which storage card they want the database to be stored on. This will give the user the flexiability to change the location whenever they need to.
  • Extending from the second option, if you are comfortable writing native C or C++ code you could write a setup.dll for your cab file. A setup.dll is invoked immediatly after installation has occurred, you could write a setup.dll which will display a window allowing the user to select where the database should be stored, and writing the users choice into the registry etc. This way the user would get prompted during installation to make the choice.

Hope it helps,

Christopher Fairbairn






Re: Smart Devices General Deploying *sdf database files via a CAB Builder project

Ilya Tumanov

See this.




Re: Smart Devices General Deploying *sdf database files via a CAB Builder project

cu-blenge

Thanks Chris and Ilya for your responses...

In reading your suggestions, I think I've determined a new approach that may better suit my needs for the application in the field. Rather than figuring out where the database should be installed when the CAB installer is ran, I think I'm going to just install the database in the same directory as the executing assembly. And then when the application is ran for the first time, I can move the file programmatically where I need, based on some underlying logic I already have in place to access directories and sub-directories. This seems more straightforward to me, especially since I have little experience with native C++ and the wceload basics. Thanks again!

Regards,

Bob