When you install Visual Studio and related content like Windows Kits or some add-ons, most packages that comprise those bundles are reference counted to make sure they are not removed prematurely. Uninstalling Visual Studio and related content should eventually remove those packages (i.e.
Four years ago I published a utility to help perform a clean uninstall of Visual Studio 2010. Before we added package reference counting and related bundles to Visual Studio setup, we couldn’t always be sure which products were still required so not everything was removed.
Requiring source packages during installation, repairs, and even uninstall are common occurrences for some customers. The core issue is that Windows Installer needs the source location of the package and its files to install – and can’t find them automatically –
These days it’s more common to install products composed of more than one installer package. Modern applications are often a loose fitting of localized components and being authored into a single package just isn’t practical.
For example, a localized application will undoubtedly have neutral or single-language binaries while using satellite resources for other languages’
Shared components define shared resources. It might seem obvious, but it’s important to understand that whatever you do to a shared resource during the installation of one product affects those same resources for any other product. For example, when upgrading one product to update files shared with another product,
While we hope you’ll love Visual Studio 2010 for all the application development it enables with powerful features and a robust extension model that enables great extensions like the Productivity Power Tools, if you ever need to uninstall Visual Studio it can be difficult.
Major upgrades are Windows Installer products that can be installed like any other product with the added benefit of removing one ore more related products. For example, version 2 of a product can be installed on a clean machine, or on a machine with version 1 already installed and will remove version 1.
When I announced that Visual Studio 2008 SP1 RTM will install over SP1 beta, we were on track to make that reality. However, when SP1 beta shipped we found that adding new components into existing features was causing a prompt for source for non-default installations of Visual Studio 2008.
The tool msizap.exe that is available in the Windows SDK and elsewhere on the web (remember to always download from a trusted source) is a powerful but dangerous tool that is often used to quickly and casually, and can leave your machine in a corrupted state if not used correctly.
A lot of customers have recently started seeing the following errors, all stating in various ways that Microsoft .NET Framework 2.0 Service Pack 1 failed to install. You may also see this when attempting to install other updates on top of .NET 2.0 SP1.