是否可以“剥离”？ .NET DLL？
我使用模块化方法用 C# 构建了一个简单的演示应用程序，因此它由一个可执行文件和几个 DLL 组成。假设我将其放入 zip 文件中并将其交给某人，其唯一目的是他们只需解压文件并双击 exe 即可试用演示应用程序。
现在，据我了解，每个获得应用程序和 DLL 的人都可以在 Visual Studio 项目中添加对 DLL 的引用，然后开始使用它们拥有的任何函数/类，只要它们被声明为公共即可。因此，他们可以访问的内容比我希望他们访问的内容多得多。
有没有办法禁用它，并获得一个类似于 C++ DLL 的系统（例如，我可以给任何人很多 C++ DLL，如果他们不这样做，他们将很难使用其中的函数/类）有头文件）？我是否可以以某种方式剥离 DLL，以便它们仍然可供 exe 使用，但不公开引用？或者是否有属性或以便我可以在代码中使用“此类只能由我构建的 DLL/exe 使用”？
I built a simple demo application in C# using a modular approach so it consists of one executable and a couple of DLLs. Suppose I put it in a zip file and hand it over to somebody, with the sole purpose they can try out the demo application simply by extracting the file and doubleclicking the exe.
Now, to my understanding everybody that gets the application and the DLLs, can just add a reference to the DLLs in a Visual Studio project, and then start using whatever functions/classes they have as long as they are declared public. And hence, they can get access to a lot more than what I want them to access.
Is there a way to disable this, and get a system that is somehwat like with C++ DLLs (e.g. I can give anyone a lot of C++ DLLs and they'll have a rather hard time using the functions/classes in it if they do not have the header files)? Can I somehow strip the DLLs so that they are still usable by the exe, but do not expose references? Or are there attributes or so that I can use in the code that say "this class is usable only be DLLs/exes built by me"?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您可以使用
InternalsVisibleToAttribute并且不公开任何内容，但是...如果您认为有任何事情可以阻止某人使用 DLL 中的非公共类，那么您就错了。完全信任的应用程序可以毫无问题地访问私有和内部内容，或者他们可以使用公开的所有内容反编译和重建 DLL。
人们会建议进行混淆处理，但这并没有什么作用。
您应该阅读这个答案（和问题，但主要是答案）： C#：如何让黑客/黑客更难绕过或绕过许可证许可检查？
You could use the
InternalsVisibleToAttributeand not make anything public, but...You're mistaken if you think that anything stops someone from using non-public classes from your DLL. An application with full-trust can access private and internal content no problem, or they can decompile and rebuild the DLL with everything public.
People will suggest obfuscation, but that doesn't do much more.
You should read this answer (and question, but mostly answer): C#: How to Make it Harder for Hacker/Cracker to Get Around or Bypass the Licensing Check?
一种可能的解决方案是仅将应该从可执行文件中调用的方法公开。其他一切都可以是私人的或内部的。您还可以混淆程序集。但请记住，无论您做什么，总是有可能使用反射来调用程序集中的任何方法。当然，如果混淆的话会有点困难，但并非不可能。
One possible solution is to leave public only the method that is supposed to be called from the executable. Everything else could be private or internal. You could also obfuscate the assembly. But remember that no matter what you do, there is always the possibility of using Reflection to invoke any method inside the assembly. Of course if it is obfuscated it will be a little harder but not impossible.
我认为您可以使用 Friend 程序集 来实现这一点。
您还可以混淆 dll 的内部结构，从而使逆向工程和反编译程序集变得非常困难。 Dotfuscator 会将编译后的 dll 中的所有函数/变量名称重命名为 a0002345 之类的名称，因此阅读它会非常详尽。
请注意，没有一种方法可以为您提供 100% 的保护，因为仍然可以使用 .NET 反射例程来访问和使用您的私有类和内部类。然而，将内容设为内部或私有将阻止大多数开发人员使用这些类。使用混淆来阻止试图挖掘您编译的源代码的高级工程师。理论上，如果反编译工作量大于从头开始编写类似工具的工作量，则认为保护足够安全。如果有人无法读取您的 dll，那么就无法知道如何使用它。
I think you can use Friend assemblies for that.
You may also obfuscate internals of your dlls so it become really hard to do reverse engineering and decompile your assemblies. Tools like Dotfuscator will rename all function/variable names inside your compiled dll to something like a0002345 so reading it will be really exhaustive.
Please notice that none of methods gives you 100% protection as still it is possible to use .NET reflection routines to access and use your private and internal classes. However making stuff internal or private will stop majority developers using those classes. Use obfuscation to stop advanced engineers who tries to dig into your compiled sources. In theory protection is considered safe enough if decompiling effort is greater than effort for writing similar tool from scratch. If somebody can't read your dlls the one won't be able to know how to use it.
不，抱歉，不是。
您可以对类似的东西进行 ilmerge 然后进行混淆（我不确定是什么工具）。
No, sorry, not.
You could do ilmerge followed by obfuscation (I'm not sure what tool) for something similar.