Visual Studio Installer Complaints and Feature Requests

Below is a list of feature requests for the Visual Studio Installer Tool.  Frankly, this took currently deserves an F.  The list below was contributed to by our Alameda office and the Itron Framework team.  (How about Microsoft eating some of their own dogfood with this tool?)

  1. Ability to add not only files, but also folders and subdirectories also to the file system. (i.e) If we pass the folder it should package all the files dynamically.  (Currently much of our help documentation includes generated files and adding these all manually rather than adding all the files in a particular directory (perhaps with a mask) is an absolute pain. We need the ability to “include all files in subdirectories {x} with filename filter mask {y}”.
  2. Facility to install at many networks machines/servers at a time. One click installation at many target machines at a time. Remote deploy to multiple machines.
  3. Facility to add custom dialogs to ‘Add Dialog’ dialog list view and ability to include custom dialogs in between the existing UI sequence.
  4. A means for customizing the existing VS.NET install wizard.
  5. Ability to add custom actions before copying (installing) the files to the target m/c. It is not possible now. (i.e. Facility to add custom actions before the splash screen starts to initialize our installer or target m/c to a particular state – before actually installing anything into the target m/c)
  6. Facility to add custom actions before/after execution of each dialog
    Integrate a new Design UI for Windows Installer where, we could attach events for tasks carried out before, after and during Install, Uninstall, Rollback and Commit
  7. Ability to register the components to registry automatically like a “COM DLLs” folder in the file system with properties to auto-register the components.
  8. Ability to install other applications (other .msi files) before/after/during the installation.
  9. Creating shortcuts for an .exe at Desktop/Programs Files folder is not working properly.
  10. A UI to access the MSI database and tables.
  11. Ability to do selective installation (to add our own component tree where the user would be able to select the components that they want).  Preferably this should be hierarchical like in Microsoft Office and Visual Studio.NET.
  12. A pie chart representation for the disc cost.
  13. In the existing UI dialog boxes, provide facility to control the size, location and other properties of the controlsÂ…, like ability to put the bitmaps vertically or horizontally or wherever we want. We need to be able to customize the UI screens.
  14. Ability to create our own dialogs using windows forms.  Perhaps requiring a deriving from an existing install dialog form.
  15. Ability to specify parameters (such as defaults) on the command line of the install that are then passed to dialogs within the install.
  16. Silent install support (this would require the ability to default any options on the install).
  17. Localization: Ability to change UI culture at runtime. One installer should be enough instead of having to build different installers for different languages. Like, choosing the language of install at the beginning of installation
  18. Package multi-tired applications in multiple installers. Ability to be able to split install into multiple machines like database server, business server etc at the same time. (for example: an UI which captures multiple install locations to install portions of a single installation).
  19. Dialogs for creating or using existing databases, schema and tables.  Running DML commands (such as a TSQL script).  This should be transacted.
  20. Unattended Installation/Silent install support.
  21. Ability to pass command line parameters to install or sub components of the install.
  22. Facility to show the files being copied to the user when Progress dialog is being shown
  23. ‘Register User’ is not working properly, throws an exception when we pass executable for custom actions.
  24. Current VDPROJ files offer no control over whether DLL dependencies should be included or not.  We have a “Core” library of DLLs that are placed in the GAC, and then multiple modules for each subsystem.  Maintaining these to keep core DLLs from showing up in subsystem directories is a continual burden.
  25. Current VDProj file is proprietary format, not XML, and there is not any public API for modifying the files.
  26. Our GAC merge module (~90 DLLs) causes VS.NET to crash without any trace when we try to build a setup project that contains only this module.
  27. Documentation for merge modules could be improved, especially documentation for “Custom tasks” written in C# installer classes.
  28. Forced double-deployment of core DLLs
    1. We are forced to deploy some DLLs in both a web/bin directory and in the GAC, since some inclusion references made from ASPX files sometimes require the presence of a core DLL in the web/bin directory.
    2. Our installer classes sometimes rely on our core product DLLs to get their work done.  But the GAC is not available at the time they run, so we are forced to deploy these dependent DLLs into the application directory as well as the GAC.
  29. Integration into the VS.NET IDE is sometimes awkward – you could close the IDE and changes would not always be saved.
    VDPROJ files take far too long to load into the VS.NET IDE.  They should load immediately, and do their dependency-checking work at build time.
  30. Need to make VDPROJ projects better at detecting to support incremental re-builds.  At present, even if I change no files at all, a full re-build occurs.
  31. In building merge modules, need to detach the need of WEB projects to be referenced by the local WEB URL.  This has proved painful in our build environment, where we have to build several code lines of the product.
  32. There’s no way to set the default of “install for me only/for everyone” without resorting to editing MSIs with ORCA, or use InstallShield.
  33. There’s no way to set the version string at build time, without using a tool like PERL to update the version string in a VDPROJ file before a build.
  34. The UI editor is limited and awkward.
  35. Integration with source control still is less than ideal.  Sometimes I can overwrite a checked-in file without a prompt, other times I am warned to check a file out first (instead of this causing an automatic check-out, as happens with most other files)
  36. VDPROJ references tend to be saved internally as absolute paths, so a module created on one machine won’t work on another -> forces use to use subst to normalize drives. (This may be fixed in 2003?)
  37. Performing textual DIFFs for different versions of VDPROJ files is practically impossible because the order of items in the file shifts every time you re-save it. This makes it difficult to see whether a file you are checking in has problems or not.  As mentioned already these files should be XML.
  38. Need a more reliable way to update DLLs that are deployed in the GAC with the same AssemblyVersion.  The version-numbering scheme does not work well for strongly-typed DLLs, since you cannot bind to an updated DLL without having to modify the app.config file to make it compatible.  This is too onerous in a system with > 10 distinct applications.
  39. Need to include GACUTIL with the .NET framework distribution.  In 1.1, we now have to use a DOS command prompt to copy DLLs that have the same AssemblyVersion into the GAC, since the drag and drop does not always work to do this.  This is a common task for manually applying hotfixes.
    Hotfix support: We currently need to use InstallShield for issuing Windows Installer-integrated hotfixes.  It would be nice if this was built into VS.NET.
  40. The code build system is less than ideal.  We build about 30 MSM and MSI files, and build system integration is pretty bad.  We use a batch file to call DEVENV To build these in series.  In future, we’d like to see stronger support for command-line, automated build tools for all VS.NET projects.  We build a large number of projects into our product now, and the partitioned solution approach advocated in MSDN is not sufficient for our needs.  Build tools that look like NANT and NMAKE get us part of the way there, but a build system that could operate directly on the VS.NET project file types would be optimal.  The ability of a solution to control the build order is helpful, but maintenance becomes impossible when using many projects.

Perhaps many of the above features are somewhat possible via workarounds with the current product.  In that case I would love to know the best practices for dealing with these issues and I request that you make it easier in the future.  At a minimum documentation on how to do any of the above tasks would be great.

Leave a comment

Your email address will not be published. Required fields are marked *