Don’t Rename Vendor-Provided .MSI Files…

When packaging an application for deployment in the enterprise, you must also identify it’s dependencies — additional software required for the application to successfully install and function.  Often times these dependencies are redistributable run-times for Microsoft Visual Studio.  These redistributables are so common, they are often packaged separately and “chained” to the dependent application.

This method of installing dependencies usually works pretty well; the deployment tool determines whether to install the package, based on it’s previous installation history.  If, however, the dependency was installed outside the deployment tool’s domain — by an application a user downloaded, for example  — you may encounter errors when the dependency is re-run; this could fail your entire application package chain.

Fortunately, many (but not all — always test!) Microsoft redistributables, like “Visual C++ 2008 SP1 Redistributable Package (x86)“,  are authored so that they can install over an existing install — without actually modifying anything or going into “maintenance mode”.  The screen shot below illustrates that the Windows Installer services runs the .MSI package, and verifies that it’s already installed with the same product code, package code, component IDs, etc., and simply exits without modifying the existing install.  This can be a packager’s saving grace in an unpredictable enterprise environment.

 

Wise Compatibility Key

 

Recently, however, I came across an issue with my philosophy of simply letting the redistributable re-run over an existing install. 

A package I had developed started failing.  After checking the logs, I noticed the failure occurred during the install of the dependent runtime  “Visual C++ 2008 SP1 Redistributable Package (x86)”.  The runtime install was exiting with a Windows Installer general failure code of “1603”. 

A look at the detailed installation log shows a more confusing error: “Error 1316.  A network error occurred while attempting to read from the file: C:Userspopper1Desktopvcredist_x86vc_red_x86.msi”.

With some help from my co-worker (Windows Installer guru Urb Bernier) we were able to find the issue: the .MSI that originally installed the Visual C++ runtime was extracted from the vendor’s .EXE bootstrap and…RENAMED!  A grievous offense in the application packaging world!  Well, that may be a bit dramatic, but it certainly violates all “best practices”.  When extracted from the vendor provided setup file “vcredist_x86.exe”, the .MSI is named “vc_red.msi”.  Perhaps the packager may have renamed the file in order to distinguish the 32-bit setup file from the 64-bit setup? 

The error “1316.  A network error occurred while attempting to read from the file: C:Userspopper1Desktopvcredist_x86vc_red_x86.msi” is Windows Installer’s way of saying it can’t access the file in the path; the “cached” path to the .MSI that originally installed the Visual C++ runtime.

You see, the issue is that you can rename the .MSI, install it successfully, re-run it successfully, and uninstall it successfully; provided you do all of these actions using the renamed .MSI.  If, however, the actual vendor install runs on that same machine, whether from the bootstrap .exe or from the extracted .MSI, it will exit with a Windows Installer general error code “1603”.

Packaging applications can sometimes be a frustrating task; because no matter how much forethought and care you put into your package, it can always be thwarted.  To be fair, I guess the same could be said for just about any other job.  

However, I hope this example illustrates why you should not rename vendor provided .MSI files!

 

2017-07-27T00:01:04+00:00 December 5th, 2012|Uncategorized|

About the Author:


Fatal error: Uncaught exception 'GuzzleHttp\Exception\ClientException' with message 'Client error: `POST https://dc.services.visualstudio.com/v2/track` resulted in a `400 Invalid instrumentation key` response: {"itemsReceived":1,"itemsAccepted":0,"errors":[{"index":0,"statusCode":400,"message":"Invalid instrumentation key"}]} ' in /home/coretek/public_html/wp-content/plugins/application-insights/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php:113 Stack trace: #0 /home/coretek/public_html/wp-content/plugins/application-insights/vendor/guzzlehttp/guzzle/src/Middleware.php(66): GuzzleHttp\Exception\RequestException::create(Object(GuzzleHttp\Psr7\Request), Object(GuzzleHttp\Psr7\Response)) #1 /home/coretek/public_html/wp-content/plugins/application-insights/vendor/guzzlehttp/promises/src/Promise.php(203): GuzzleHttp\Middleware::GuzzleHttp\{closure}(Object(GuzzleHttp\Psr7\Response)) #2 /home/coretek/public_html/wp-content/plugins/application-insights/vendor/guzzlehttp/promises/src/Promise.php(156): GuzzleHttp\Promi in /home/coretek/public_html/wp-content/plugins/application-insights/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php on line 113