Windows Installer（.msi）。 自定义动作。 我是否需要混淆/保护用C＃编写的自定义操作代码？ 有没有办法拆解它？

Question

We are developing desktop application and we use Wix toolset to create .msi installer.

We use ".Net Reactor" to obfuscate and protect C# code. But we also have several Custom Actions (in the .msi) that we would like to protect as well.

So the question is if we need to worry about protecting these and if so what would be the best way to protect them? do we need to obfuscate all dlls that Custom Actions project depends on?

Answer 1

No Sensitivity, No Problem : I second what Klaus said: does this code contain anything sensitive? Usually the sensitive aspects would revolve around licensing or keys of some sort that you want to protect. Be sure to compile Release mode binaries (would be nuts not to - runtime requirements would also not be met on normal machines).

Protecting Sensitive Information : I wrote a whole check list some time ago on the issue of avoiding the distribution of sensitive information with your deployment solution: How do I avoid distributing sensitive information in my MSI by accident? (one of those sprawling answers that go off the rails while you write - might still be worth a skim).

Native Code : If you have major concerns for sensitivity, I would compile a C++ custom action instead of a managed code custom action to make things more " down to the metal ". This is also great for ensuring minimal runtime dependencies (static linking).

Open Source : Quite frankly I would consider open sourcing my whole setup code if no sensitivity is present. Is users have a problem the can debug themselves - though the benefit of that in many cases can be pie-in-the-sky. You can close-source single custom actions that need sensitivity. I would use open source as a sales argument - yes, you can see our setup source to tweak to your environment if need be.

A setup is like a resume: it is only there as a vehicle to deliver something else of value? It has no value in and of itself. You want a sale of your software first and foremost? And security of course. Allowing users to compile their own setup from your sources could also lead to problems - of course. Do you want to support a self-compiled setup?