Is dark.exe (from WiX) a reliable way to extract information from an MSI?

... and if yes, why can't I use SelfRegCost="0"?

So this might get a little philosophical ;)

The basic problem is: I have to register a ShellExtension DLL during a setup. When using plain old VS2008 deployment, I had a custom action which ran a regsvr32 on my dll. Then in my WiX setup I did the same, even with an unregister (/u) on uninstall. This works fine.

Until the other day I had a problem with some third-party DLLs loosing their registration after uninstalling a Visual Studio Setup. I found the installation had overwritten the default location of the DLLs. I discovered the possibility to change the Register Property from vsdrfCOMSelfReg to vsdrfDoNotRegister, and now my Setup did not overwrite the default location any more.

This made me thinking that I can use the same Property to register my ShellExtension DLL. So lets use dark on the VS Setup and see what the translation of the vsdrfCOMSelfReg is. And I found the only difference is the attribute SelfRegCost="0" in the File tag.

But according to this article ( How do you register a Win32 COM DLL file in WiX 3?) using SelfRegCost is baaad, lots of things go wrong. Possibly.

Now my reasoning is: either

a) dark.exe is not a realiable way to extract information from an MSI or

b) the use of SelfRegCost="0" is not as bad as开发者_如何学Go everybody pretends, since Visual Studio does it eversince?

Visual Studio is exposing functionality; that doesn't mean it's a good idea to use it. Self-registration is bad and should be avoided by explicitly authoring COM registration using WiX elements like Class and ProgId.

Dark is meant to decompile back to source but it isn't intended to be round tripped back via the compiler. It's meant to be a useful starting point to clean up the code and do any needed refactoring then build it back up.