关于混淆：我应该担心混淆我的.NET代码吗？

我敢肯定，许多SO的读者都使用过Lutz Roeder的.NET反射器来反编译他们的.NET代码。
我很惊讶我们的源代码可以从编译后的程序集中重新构建。

我想听听你们中有多少人使用混淆技术，以及使用哪种产品？

我敢肯定，对于您提供的可通过Internet下载的.NET应用程序而言，这是一个更为重要的问题，而不是针对特定客户端定制的内容。

---

我不会为此担心太多。我宁愿专注于推出出色的产品，获得良好的用户基础并正确对待客户，而不必担心与窃取代码或查看源代码有关的用户比例最小。

---

请记住，混淆不是加密。恕我直言，如果有人意识到反向工程代码的价值，他们会做到的。对于托管代码或本机代码，无论是否混淆，都是如此。当然，混淆会阻止偶然的观察者，但是您的业务实际上受到这种人的威胁吗？我见过的每种.NET混淆方法都会使您作为开发人员的生活更加艰难。

有提供真正加密的服务，例如Microsoft的SLPS。请参阅http://www.microsoft.com/slps/default.aspx

---

尽管我们是一家小公司，向少数客户出售专业软件，但我们目前仍在混淆所有输出。

我们做出此决定的原因很简单-我们发现一位心怀不满的前雇员正在积极地向要求二进制文件的客户求助-他出于某种目的而打算对新功能进行逆向工程以提供具有竞争性的功能。

当然，如果他使用该软件，他仍然可以做到这一点，但是没有理由让他轻松。

---

没有新的混淆，但是自1.1以来有很多编译器技巧

例如，每次您使用匿名类型时，都会得到IL，该IL会以非常晦涩的名称进行编译。每次使用yield时，都会得到一个全新的类，该类同时实现IEnumerable和IEnumerator(智能优化，不可读的代码)。每次使用匿名委托时，您都会得到一个新方法，该方法的名称在我所知道的每种.Net语言中都是无效的，但在IL中就可以了。

---

罗伯·库珀

Having had some discussions with my
manager at work, he said he doesn't
obfuscate, but does NGEN on install,
apparantly that should be enough to
stop Reflector working on your
assemblies, but I have no idea if this
is true and to what extent, so please
don't take it as gospel :)

这不能提供任何防止拆卸的保护措施。首先，我想从任何安装包(例如MSI或CAB文件)中提取原始文件都是有可能的。

但是更重要的是，Ngen在安装了程序集之后便在客户端计算机上运行。 Ngen只是强制程序集立即编译，而不是以后使用JIT。原始程序集将保留并且未被修改，并且必须保留，因为Ngen可能无法编译整个程序集。

Ngen是为了性能而不是安全性，它不会阻止反汇编或使其变得更加困难。

---

对我来说很容易-如果您需要保护知识产权-令人困惑-否则就不会。

使用正确的工具即可轻松完成。

---

对于"非公共"应用程序，我们不使用混淆处理，但对于公共可用的应用程序，则使用混淆处理。混淆后的应用程序包含大量高度复杂的代码，这使我们花费了大量时间来编写代码，这就是让我认为必须进行混淆的原因-至少在这种情况下。

---

我认为在某种程度上我们都应该担心我们的IP :)

尽管这是一个很好的问题，但我希望对此有更多的了解(我目前还不太了解)。

在与我的经理进行了一些讨论之后，他说他并没有混淆，但是NGEN确实在安装上，显然足以阻止Reflector在您的组件上工作，但是我不知道这是否正确以及在多大程度上适用，所以请不要把它当作福音:)

好问题:) +1

---

同意，大多数懂一点代码的人都不需要窃取您的代码！

---

混淆的有效性受到限制，它可能会使随便的人远离。最有效的混淆方法是使用户只能使用最少的代码。如果可以，请确保您的应用程序在很大程度上依赖胖服务器。

---