访问不同程序集中的私有方法c#
这可能是一个愚蠢的问题,因为我可以看到它以这种方式发生的安全原因...
我有一个许可 c# 项目,它有一个类,其中有一个生成我的许可证密钥的方法。 我已将此方法设为私有,因为我不希望其他任何人能够出于明显的原因调用我的方法。
我想做的下一件事是拥有我的用户界面,该界面位于另一个 c# 项目中,该项目正在引用许可 dll是唯一可以在其自身之外访问此方法的其他“事物”,这可能吗?还是我需要将其移至同一个项目中,以便它全部编译到同一个 dll 中,并且我可以访问其成员?
许可项目
-许可类
--私有MethodX(生成许可证密钥)LicensingProject.UI
-LicensingUiClass
--我希望能够成为唯一能够访问 MethodX 的类
许可证密钥生成器不仅仅出现在 UI 中是有原因的,那是因为许可通过在自身上生成哈希并将其与由许可证生成器生成的许可证。
我不希望全部编译为 dll,因为我的最终用户不需要 UI 代码。
我知道根据常识,私有方法就是这样。 我很困惑。
This may be a daft question as I can see the security reason for it to happen the way it does...
I have a licensing c# project, this has a class which has a method which generates my license keys. I have made this method private as I do not want anybody else to be able to call my method for obvious reasons
The next thing I want to do is to have my user interface, which is in another c# project which is referencing the licensing dll to be the only other 'thing' which can access this method outside of itself, is this possible or do i need to move it into the same project so that it all compiles to the same dll and I can access its members?
LicensingProject
-LicensingClass
--Private MethodX (GeneratesLicenseKeys)LicensingProject.UI
-LicensingUiClass
--I want to be able to be the only class to be able to access MethodX
There is a reason why the license Key Generator is not just in the UI, that is because the licensing works by generating a hash on itself and compares it to the one generated by the License Generator.
I would prefer not to all compile to the dll as my end users do not need the UI code.
I know that by common sense a private method, is just that. I am stumped.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
您可以将其设为内部方法,并使用
InternalsVisibleToAttribute
为 LicensingProject.UI 提供对 LicensingProject 的额外访问权限。默赫达德关于执法的观点既正确又错误。 如果您没有 ReflectionPermission, CLR 将阻止您调用不应调用的内容 - 但如果您使用来自完全受信任的程序集的反射,则可以调用任何内容。 您应该假设潜在的黑客能够在自己的计算机上运行完全受信任的程序集:)
所有这些都不会阻止某人使用 Reflector 来反编译你的代码。 换句话说,将其设为私有并不能真正为您的许可方案增加大量安全性。 如果有人真正付出努力来打破它,他们很可能能够做到。
You could make it an internal method, and use
InternalsVisibleToAttribute
to give LicensingProject.UI extra access to LicensingProject.Merhdad's point about enforcement is right and wrong at the same time. If you don't have ReflectionPermission, the CLR will stop you from calling things you shouldn't - but if you're using reflection from a fully trusted assembly, you can call anything. You should assume that a potential hacker is able to run a fully trusted assembly on his own machine :)
None of this will stop someone from using Reflector to decompile your code. In other words, making it private isn't really adding a significant amount of security to your licensing scheme. If anyone actually puts any effort into breaking it, they'll probably be able to.
这确实是一条评论,是为了回应 Mehrdad 关于运行时不执行访问检查的观点; 在这里,您可以看到 JIT(它发生)执行访问检查 - 不是反射,也不是 C# 编译器。
要修复该代码,请将
Foo.Bar
公开。 有趣的是,它还验证Foo
是否可访问 - 因此将Foo
设为内部以查看更多烟花:This is really a comment, in response to Mehrdad's point about the runtime not performing access checks; here, you can see the JIT (it transpires) performing the access check - not reflection, and not the C# compiler.
To fix the code, make
Foo.Bar
public. Interestingly, it also verifies thatFoo
is accessible - so makeFoo
internal to see more fireworks:public
、private
、...这些东西只是由编译器强制执行的。 您可以使用反射非常轻松地访问它们(假设代码具有所需的权限,这是一个合理的假设,因为他对机器具有完全控制权)。 不要依赖假设没有人可以调用它。public
,private
, ... stuff are just enforced by the compiler. You can use reflection to access them pretty easily (assuming the code has required permissions, which is a reasonable assumption as he has complete control on the machine). Don't rely on that assuming nobody can call it.Foo.Bar 可能会保持私有状态...
要修复上述代码,请在 DynamicMethod 构造函数末尾添加一个参数:
添加 true 以跳过对动态方法的 MSIL 访问的类型和成员的 JIT 可见性检查。
Foo.Bar may stay private...
To fix the code above, add one parameter at end of DynamicMethod constructor:
Add true to skip JIT visibility checks on types and members accessed by the MSIL of the dynamic method.