答案 0 :(得分：13)
在DLL中创建所有internal，然后在Properties \ AssemblyInfo.cs中，将InternalsVisibleTo属性设置为仅指向应用程序的strong name。
答案 1 :(得分：13)
这根本不可能。
整个代码访问安全系统基于以下概念：安全决策来自运行代码的用户，而不是来自代码的作者。作为代码的作者，您无法告诉用户他们的安全决策是什么;你是用户的仆人，而不是用户的主人。
现在，您可以使第三方代码难以使用您的代码。您可以使用文档的各种安全属性，意图是第三方代码，不使用您的代码。这些都是很好的步骤，但在用户对您不利的任何世界中，它们实际上并不能解决您的问题。 在CAS模型中，用户总是赢。
例如：您可以让代码中的方法执行安全性要求，触发堆栈遍历以检查调用堆栈中的每个人是否都有与之关联的某些证据。例如，证据“这个DLL是用Guillaume的强名私钥签名的，它被锁在Guillaume办公室的抽屉里”，这将是检查的好证据。这几乎保证每个调用代码的人都是你的代码。
但这不是强名签名的目的;强名称签名的目的是帮助用户知道他们认为他们运行的代码实际上来自你。正如我们所看到的，将安全工具用于其他目的以外的目的是危险的。它给你一种完全错误的安全感。
假设您的用户想要创建一个不属于您的应用程序而使用您的DLL。用户可以编写完全受信任的代码，完全受信任的代码有权伪造证据。这就是“完全信任”意味着。因此，用户创建一个未经您签名的应用程序，但由于用户可以完全信任该应用程序，因此完全信任的应用程序可以伪造证据来表明代码来自您。
就此而言，没有什么可以阻止用户简单地使用您的代码，删除您的签名，并将其替换为签名。你可以说你的EULA禁止这样做，如果你发现了，你可以起诉他们，但是你无法阻止他们。
哎呀，用户可以根据需要禁用整个安全系统，在这种情况下，任何东西都可以运行。
您应该考虑是否要将DLL发送给客户。如果它包含您不想离开的秘密，那么不要与成千上万的客户分享这些秘密，其中一些客户可能对您不利。如果您将DLL保存在自己的服务器上并通过Web提供服务，那么您不会将DLL发送给客户，因此他们无法在自己的计算机上将其用于非您想要的目的。
答案 2 :(得分：3)
没有单个有效屏障，但是您可以设置一些障碍来阻止人们绑定到您的DLL。
（强名称标识程序集，Publisher标识发布程序集的人员。）
您还需要检查.NET中CAS安全性的禁用情况，这可以在您正在保护的资产中以编程方式执行。
在构建后（但在签名之前）对您的DLL进行模糊处理。
考虑添加某种许可检查最终的程序化检查。
HTH
菲尔'
答案 3 :(得分：1)
请记住，这种保护需要双重保护。如果您只保护DLL，任何黑客都会开始分析您的应用程序以了解它是如何调用DLL的。 此外，如果第三方拥有对您的DLL的完全访问权限，那么无论您的保护有多强大，他们都将成功发现它的内部工作。虽然一些保护方案比其他方案需要更多时间来破解。基本上，DLL的保护应该取决于此DLL的值。如果黑客可以通过黑客入侵你的DLL来节省或赚取数百万美元，他们肯定会这样做。如果你的DLL只是为他们提供了最低的经济收益，那么他们更有可能甚至不愿意破解它。
如果要保护DLL代码的安全，请在某处设置Web服务，并将应用程序设置为调用此服务而不是本地DLL。然后，黑客访问您的图书馆会遇到更多麻烦。不幸的是，它还要求您的用户持续连接互联网。
（基本上，这就是云计算变得越来越流行的原因。用户可以使用云应用程序，但无法访问二进制文件。）
答案 4 :(得分：0)
Obfusc你的代码是补充解决方案