rickgaribay.net

Space shuttles aren't built for rocket scientists, they're built for astronauts. The goal isn't the ship, its the moon.
posts - 303, comments - 180, trackbacks - 35

My Links

News

Where's Rick?


AgileAlliance deliver:Agile 2019- 4/29
Desert Code Camp, PHX - 10/11
VS Live Austin, TX - 6/3
VS Live SF - 6/17


About Me
Hands on leader, developer, architect specializing in the design and delivery of distributed systems in lean, agile environments with an emphasis in continuous improvement across people, process and technology. Speaker and published author with 18 years' experience leading the delivery of large and/or complex, high-impact distributed solutions in Retail, Intelligent Transportation, and Gaming & Hospitality.

I'm currently a Principal Engineer at Amazon, within the North America Consumer organization leading our global listings strategy that enable bulk and non-bulk listing experiences for our WW Selling Partners via apps, devices and APIs.

Full bio

Note: All postings on this site are my own and don’t necessarily represent the views of my employer.



Check out my publications on Amazon Kindle!





Archives

Post Categories

Published Works

When All Else Fails, Try MSIEXEC

If anyone has had the misfortune of installing the Whidbey (VS.NET 2005) bits along with .NET FX 2.0 or any of the Express betas, you may find that you cannot uninstall using 'Add Remove Programs'.

In my case, I installed .NET FX 2.0 along with C# and Web Express side by side with VS.NET 2003, and when I tried to uninstall it, I found that I couldn't.

This pales in comparison to other posts I've seen where installing the beta bits hosed current installs of VS.NET 2003, but more common is an issue when trying to install newer builds of Whidbey ontop of an existing build. Microsoft recommends uninstalling all old versions before installing a new version, but many, like me, found that uninstallation is not trivial.

When trying to uninstall any of the above, I was getting error messages indicating that the action was prohibited by group policy. Since there are no GPO on my machine that care what gets uninstalled, this message is bogus. That said, the problem of getting rid of the installs remained.

The solution:

The solution comes down to two very useful utilities, msiexec and msiinv (sorry, you'll actually have to keep reading to find out how to get this). The former comes with the Microsoft Platform SDK, but the latter, unfortunately is only distributed on a case-by-case basis by Microsoft.

Msiexec simply calls the uninstaller, passes it an MSI package name or a product code, which is a GUID that uniquely identifies the product. All products have this GUID, but as I found out, determining the GUID for each product is not trivial.

Anyway, the syntax for msiexec is:

Msiexec /x {GUID} | PackageName.msi

Note the pipe "|" above is used to specify OR.

So, if I were to uninstall the Whidbey bits, per Sam Gentile's blog, you would issue the following command:

msiexec.exe /x {B3A02601-8FE9-4108-8E95-D94171A2F8C8}

Why that works, but 'Add/Remove Programs' doesn't, or using the PackageName.msi option does not, I don't know. If anyone does, please let me know.

BUT, what if you need to uninstall a product for which you do not know the GUID/Product Code? Enter msiinv.exe.

As the name impiles, msiinv does an inventory of all msi packages on your machine, and reports them to a txt file of your choosing. So, to pipe the results from your machine, simply issue the following command and the command prompt:

Msiinv.exe > MyTextFile.txt

You now will have a GUID for every product on your machine, and you *should* be able to remove it.

As I mentioned before, msiinv.exe is only distributed by Microsoft on a case by case basis, meaning that you actually have to open up an email dialogue with a Microsoft rep. Some very dedicated searching on the boards finally got me this little gem.

To save you the time and effort, I am providing the link here, although I can't guarantee that it will always be available, nor do I make any guarantees that the file is safe although I did download it and have used it without issue.

 

Note: My intention was to provide the utility for download, but after following up with a contact at Microsoft, I thought better.Why the hell don't you just host the file yourself you ask? Well, from my a moral gray area, I believe it is one thing to actually host the binaries and quite another to merely provide a shortcut to freely accessible information.

 

Happy Programming!

** There is another utility called msizap that is supposed to perform a rudimentary removal if msiexec fails. Fortunately, I never had to use it.

Print | posted on Saturday, February 17, 2007 9:11 AM | Filed Under [ Misc. Visual Studio ]

Comments have been closed on this topic.

Powered by: