And I’m starting to feel why.
Apart from MSI custom actions with their immediate/deferred idiosyncrasy being not only a pit-of-despair but rather an abyss, there is something much more fundamentally but subtly wrong about them.
Rob and others are pointing out that it’s JScript or VBScript as well as managed code that you probably can’t ever get run successfully in a custom action.
But actually, it is every dependency on some kind of framework or runtime library that can and will cause your custom action to fail.
What I’m saying is, if you’re using Visual Studio 2005 to write a custom action dll, better not use the C-runtime or link to it statically. The same is true for MFC, ATL and whatever else you might think you need that does not come with the operating system. MSVCRT8 is not a Windows component.
Even with "/lvx*" does MSIEXEC not log loader failures, so you might be debugging for a while before you find out why it works on your machine but not at your customer’s.
Sure, you can install MSVCRT8 as a pre-requisite.
Just make sure it fits the target operating system. And it’s successor. Plays nice with SxS. And doesn’t conflict with hotfixes, patches, updates, service packs, language packs and the next version of Windows, Office, Visual Studio and whatnot, including but not limited to every other software package from anybody else who too think merging in some version of the C-library into the installation was a clever idea.
Good luck with that.