Windows Mobile Application Development
There are several ways to deploy a Windows Mobile Application. The core of the deployment is creating, delivering, and running the .cab file. Visual Studio has the function to create the .cab file in a few easy steps, but delivering the .cab file to the Windows Mobile device and running the .cab file still requires a few manual steps. The most friendly way to deploy a Windows Mobile application is to utilize ActiveSync and run an executable on a PC connected to the Windows Mobile device, and install the application in one step for the user. The steps to create such an executable is described as follows:
1. Create the .cab file by
I haven't done handheld development in years, so I can't speak to the accuracy of the process. Still, if you want to use an installation program, then you'll have to resort to a custom action after installation. Whether you can accomplish what you want through the built-in setup project, I don't know.
Still, I would lean toward a more elegant solution (at least to me). It really depends on how often you intend to update the CAB, I guess. In the best case, I'd write a self-installing EXE instead. The EXE would/could have the CAB and INI file embedded as a resource. When running the EXE, it would extract the CAB and INI file, locate and run the CE App Mgr to download the app, and then remove the CAB and INI. All this would be handled by a single file.
Pushing a little harder, it is easy to see that embedding the CAB/INI just to download it would be a nuisance during development, so I would probably add support for command line arguments such that you could point the EXE at a CAB/INI pair. Rather than extracting the resources, it would simply use the arguments instead. The consequences are the same. This allows you to do quick dev tests yet still ship a simple, standalone app to customers that handles all the gory work. Additionally, you could add a nice little UI letting the user know how the download is going and whatnot.
The CAB/INI would be added to the EXE as static resources during compilation. Whatever build process you used to generate the CAB/INI would ensure that the name was pre-defined so the EXE could find it during the build. You could even get fancy and allow multiple CAB/INI pairs to be embedded. Now a single EXE can install multiple programs to a mobile device. Of course, I'm getting away from the original question now.