DLL 反射？
这样的事情可能吗？如果是这样，您能给我指出正确的学习方向吗？
applicationx tries to run the method start() in dll_one.dll
dll_one.dll runs the command
applicationx tries to run the method run() in dll_one.dll
dll_one.dll doesn't have a method run() and hasn't prepared for such an occurance.
dll_one.dll asks dll_two.dll if it has a run()
dll_two runs run()
基本上，我想要它，所以如果 dllA 没有应用程序正在寻找的方法，它会询问 dllB。这也假设 ApplicationX 和 dllB 对 dllA 和 dllA 不了解，它们只是突然出现（我希望 dll 像我的应用程序的补丁一样动态地出现，而不必重写所有方法、属性等. 在 dll 中，并将其他所有内容都路由到旧的 dll）。
有什么想法吗？请记住，我使用的是 vb.net，因此 .net 参考值得赞赏。
Is something like this possible? If so, could you point me in the right direction for learning how?
applicationx tries to run the method start() in dll_one.dll
dll_one.dll runs the command
applicationx tries to run the method run() in dll_one.dll
dll_one.dll doesn't have a method run() and hasn't prepared for such an occurance.
dll_one.dll asks dll_two.dll if it has a run()
dll_two runs run()
Basically, I want it so if dllA doesn't have a method that the application is looking for, it asks dllB. This is assuming, as well, that ApplicationX and dllB don't know anything about dllA and dllA kind of just appeared out of nowhere (I want dlls dynamically like a patch to my applications without having to rewrite ALL of the methods, properties, etc. in the dll and have everything else just routed to the old dll).
Any ideas? Keep in mind, I'm using vb.net so a .net reference is appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
看来您正在为您的应用程序要求一个插件架构（除了“补丁”部分让我烦恼）。如果是这样，您可以尝试 MEF，它可以解决这个问题。
It seems like you're asking for a plug-in architecture for your app (except that "patch" part is bothering me). If so, you can try MEF, which solves this exact problem.
你要求的具体事情是不可能的。您不能将不存在的方法调用自动重新路由到不同的 dll。除非您编译了该代码，否则您无法“运行 dll_one.dll 中的 run() 方法”，并且如果该方法不存在，则该代码也不会编译。您也不能针对 dllB 编译代码，然后放入 dllA 并让它拦截方法调用。可以想象，反射可以解决您的部分问题，但您不希望您的代码基于通过反射调用所有方法 - 这会导致性能非常低下，并且不太可维护。
正如安东建议的那样，插件方法可能会起作用。然而，这将依赖于您能够预先指定插件的接口，这听起来似乎与您最初的要求相矛盾。
另一个问题：如果您稍后才部署 dllA，那么您的 ApplicationX 如何知道调用 dll_one.dll 中的 start() 方法？您肯定需要至少重新部署基本应用程序才能使该部分正常工作。
解决此类问题的最佳方法通常是制定一组更具体的要求：您将来可能想要扩展或更改哪些功能？您是否可以支持一组允许通过插件进行扩展的通用接口，或者您是否需要使用新功能重新部署应用程序的封装块？是否涉及 UI 或者这只是为了改变后端逻辑？诸如此类的问题有助于提出更可行的解决方案。
The specific thing you ask for isn't possible. You can't have a non-existent method call automatically re-routed to a different dll. You can't "run the method run() in dll_one.dll" unless you've compiled that code, and it won't compile if the method doesn't exist. You also can't compile code against dllB and then drop dllA in and have it intercept method calls. Reflection could conceivably solve part of your problem, but you'd not want to base your code around calling all methods by reflection - it'd be horrendously unperformant and not very maintainable.
As Anton suggests, a plugin approach might work. However, this would rely on you being able to specify up-front the interface for your plugin, which sounds like it would contradict your original requirement.
Another problem: if you'd not deployed dllA until later, how would your ApplicationX know to call method start() in dll_one.dll anyway? You'd surely need to re-deploy at least the base application for that part to work.
These kinds of problem are often best solved by having a more specific set of requirements to work to: what functionality are you likely to want to extend or change in the future? Could you support a common set of interfaces that allow extensibility via plugins, or can you need to redeploy encapsulated chunks of your application with new functionality? Is there UI involved or is this just to change back-end logic? Questions like this could help to suggest more viable solutions.