Prevent changes to Dependencies on Smart Device Setup CAB

Question

I've a Windows Mobile application that consists of a shell, and several modules. Each module has its own setup project for generating a CAB file to install it, and there is also one for the shell which serves as the base application. The issue that I am having is that every time I open a solution for a module (each module has its own solution, that references the other projects as needed), Visual Studio refreshes the dependencies for the setup project, and in effect breaks the entire setup project.

There are two major problems that I am having in relation to this, the first being that the Setup CAB is pulling in two versions of several DLL's. One from the Compact Framework, and one 'normal' DLL. This inflates the CAB size exponentially and causes warnings because there are two files with the same name.

The second issue that I have is that the setup cab for each module should include only the module DLL, not any depenencies (as they're all part of the shell CAB). However every time the solution is opened I have to manually remove every dependency before building the CAB.

Also of note is that these projects are checked into Team Foundation Server, but somehow manage to change without being checked out.

I'm running Visual Studio 2008, developing against the .NET 3.5 Framework, for Windows Mobile 5.1-6.5.

I would appreciate any insight on this issue, as it's quite time consuming to rework the dependencies every single time I need to do a release.

Answer 1

The Smart Device CAB project is an abomination. It works for only the most simple deployments (and even then it's limiting). The solution we ended up going with for all installations is to manually roll the INF file (you could use the baseline INF file that your current CAB project creates) and then call CABWIZ directly from a batch file/command line to generate the installation CAB. It sounds painful, but it's really not, and it's lends itself to automation through MSBUILD as well, so building deployment packages is easier to automate.