Microsoft.WindowsInstaller.dll is a complete .NET wrapper for the Windows Installer APIs. It provides a convenient object model that is comfortable to .NET developers and still familiar to anyone who has used the MSI scripting object model.
All published MSI APIs are wrapped, with the exception of four: MsiGetFileSignatureInformation (because I don't know of a .NET analog for the returned certificate structure), and three APIs for previewing UI dialogs. Other than that, you should be able to do everything that you can do via the C APIs or the COM automation interface.
Some parts of this code have never had a formal test pass, so use at your own risk. But much of the code is exercised daily, used by the Developer Division Sustaining Engineering team's BRIQS system to build and test patches. And it has been in use by many other teams for over two years now with only a few minor fixes, so it can be considered very stable.
Despite its official-sounding namespace, this assembly is not officially sanctioned by the Windows Installer team. But currently there are not any plans for an official set of managed even in Longhorn, so I don't see a conflict for now.
It is possible to access MSI's COM Automation interfaces via C# and VB.NET. So why create yet another wrapper? Here are some of my reasons:
One of the primary things I wanted to be able to do was write custom actions in C#. The automation interface was not usable in that case, because there is no way to convert the integer session handle (received as a parameter to the type 1 custom action function) into a Session automation object.
The automation interface does not provide a way to specify an external UI handler. Besides external UI, this is also needed to do validation.
The automation interface does not provide a way to explicitly close handles (other than Views). I ran into this problem when I wanted to programmatically delete a database that I'd just finished using, but couldn't because it was still open!
Finally, COM Automation is somewhat slower than invoking the APIs directly.
See also: