This page describes bugs and issues that I have encountered while using the deployment projects in Visual Studio .NET 2003. In general, Visual Studio .NET's deployment projects are a good tool to use when creating simple setups, but there are a few problems that affect developers using the tool.
All of the issues on this page have been reported to Microsoft. Hopefully they will fix them in time for the release of Visual Studio .NET 2005.
.vdproj files are diff-hostile
.vdproj files are
diff-hostileSeverity: nuiscance
When you edit a .vdproj file, by adding and removing files to a merge module for instance, Visual Studio .NET reorders the nodes in the file when it saves out the project. This causes source code control systems to become confused abou the "real change" because the nodes end up being reordered around within the file, creating lots of false additions and removals when looking at a context diff on the project file. This, in turn, makes the context diff useless for determining the nature of the change made by a developer.
Severity: nuiscance
Automatic dependency checking finds dependent DLLs and other files for executable code modules. In theory this sounds like a convenience, but the dependency checking happens every time you load a project in Visual Studio .NET and silently removes previously detected (and possibly excluded) dependencies if they are not present on a developer's machine.
This can result in a scenario where a previous automatically detected dependency that was manually excluded can become revived because the developer making the change to the project doesn't have the dependency on their machine. The developer loads the project, the dependency isn't found and is therefore completely removed from the project file. The developer makes the change they wanted to make, oblivious that they have also accidentally removed a manually excluded automatically detected dependency. They check in their change, noting that the context diff is worthless so that they cannot tell if their change is doing something harmful. Later, an automated build process opens the project to build the setup. The automated build contains the previously excluded automatically detected dependency and Visual Studio .NET add the automatically detected dependency back to the project at the time the automated build machine opens the project. When the detected dependency is automatically added back (again, this happens silently, so it is not obvious it is happening), it is no longer excluded and is included in the output of the project.
Severity: critical
If you add too many files with long file names that have an identical prefix, Visual Studio .NET will generate short filenames that are duplicates. This will cause ICE30 to fail and make it impossible to install the product on a filesystem that uses short filenames.
ClashingShortFilenames.zip
contains a project that reproduces the issue.
Severity: nuiscance
The Windows Installer documentation describes a naming convention for primary keys in merge module tables. This naming convention ensures that no two merge modules will have primary keys that conflict with each other. Visual Studio .NET does not follow the naming convention in all respects, but does generate keys that are unique enough that they should not clash with primary keys in any install or in another merge module.
The resulting primary keys are not humanly readable and make it difficult to debug installations that contain files and components from multiple merge modules.
Severity: critical
The component GUIDs for files in a merge module are apparently created by hashing the install path of the file relative to the module retargetable folder. This means that if two distinct merge modules install a file of the same name relative to module retargetable folder, then each of these files will be in a component with the same GUID. This will cause ICE08 to fail and cause problems for patching and upgrades.
ClashingComponents.zip
contains a project that reproduces the issue.