将编译类型转换为当前命名空间类型
我目前正在 C#/Silverlight 中构建一个模拟器。因为我们正在模拟特定的软件域，所以我们必须在模拟器的范围内实现域级类（Cube、CubeSet、BaseApp 等）。此外，这些域级类必须可供应用程序开发人员使用，因为它们可供将要模拟的应用程序访问。
因此，我们拥有的是一个 .dll，它只是域级类的编译，然后在模拟器实现本身中，我们有一个相同域级类的包。
目标是动态实例化应用程序对象（这是可行的），然后调用该应用程序的一系列方法来执行模拟。然而，在调用其中一个方法时，我们必须传入一个在模拟器实现中实例化的域级对象。我们必须在动态实例化的应用程序上调用 AssociateCubes（它采用 CubeSet 参数）。当我尝试动态执行此操作时，我收到一个 InvalidCastException 异常（很有趣），它表示“CubeSet”对象无法转换为“CubeSet”对象。用于动态访问应用程序的代码示例如下：
Object o = Activator.CreateInstance(appType);
MethodInfo AssocCubes = o.GetType().GetMethod("AssociateCubes");
AssocCubes.Invoke(o, new object[] { Cubes });
其中 Cubes 是模拟器中的 CubeSet 类型，appType 由用户指定。
有没有什么方法可以强制两者之间建立某种联系，以便编译器识别实际上是同一个类，或者这两个类是完全不同的并且不能以允许一种类型的对象的方式关联被扮演另一个。
我考虑过的一种解决方案是简单地定义一种方法来手动将一个对象的内容复制到模拟器中的实例，但其中的问题是应用程序开发人员可以为应用程序类定义自己的方法以用作辅助方法。
我可能没有完全解释所有内容，因此我可以提供任何可能有助于揭示潜在解决方案的澄清。
I am currently building an emulator in C#/Silverlight. Because we are emulating a particular software domain, we have domain-level classes (Cube, CubeSet, BaseApp, etc.) that we have to implement within the scope of our emulator. Additionally, these domain-level classes have to be available to the application developer because they are accessible to applications which will be emulated.
So what we have is a .dll which is a compilation of just the domain-level classes, and then within the emulator implementation itself we have a package of the same domain-level classes.
The goal is to dynamically instantiate the application object, which is doable, and then call a sequence of that application's methods to carry out the emulation. However, in calling one of the methods, we have to pass in a domain-level object which is instantiated within the emulator implementation. We have to call AssociateCubes (which takes a CubeSet parameter) on the dynamically instantiated application. When I try to do that dynamically, I'm getting an InvalidCastException which (amusingly enough) says that a "CubeSet" object cannot be cast as a "CubeSet" object. An example of the code being used to dynamically access the application is:
Object o = Activator.CreateInstance(appType);
MethodInfo AssocCubes = o.GetType().GetMethod("AssociateCubes");
AssocCubes.Invoke(o, new object[] { Cubes });
where Cubes is of type CubeSet in the emulator, and the appType is as given by the user.
Is there any way to force some sort of link between the two so that the compiler recognizes that in reality the same class, or is it that the two classes are completely distinct and cannot be associated in such a way to allow an object of one type to be cast as the other.
One solution I have considered is simply defining a method to manually copy the contents of one object to an instance in the emulator, but the problem therein is that the application developer can define their own methods for the application class to be used as helper methods.
I may not have explained everything completely, so I can offer any clarifications that may help expose a potential solution.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
为了方便起见，InvalidCastException 仅显示完整类名的最后部分，但类型会根据完整标识进行比较：全名（包括命名空间）及其来自的程序集（如果签名，则可能具有强名称）。
考虑使用单元测试框架来“模拟”对象。或者至少了解此类框架如何包装类。
真正的解决方法是使用可测试的类层次结构。通常使用接口代替具体类有助于解决此类问题。
The InvalidCastException only shows last portion of full class name for convinience, but types are compared on full identity: Full Name (including namespaces) and assembly it is coming from (which may have strong name if signed).
Consider using Unit Testing framework for "mocking" objects. Or at least read on how such frameworks wrap classes.
The real fix is to use testable class hierarchies. Often using interfaces instaed of concreate classes help to solve this type if issues.
我不想低估之前给出的答案，但我已经找到了我在评论中描述的解决方案。
相反，我所做的是将域层从模拟器项目中拉出，并将其单独编译为 DLL。现在，DLL 在模拟器和单独的应用程序中被引用，因此当动态加载类型时，它们毕竟被认为是相同的类型。
I don't want to discount the previous answer given, but I have found a solution as I described in the comment I wrote.
What I do instead is pull the domain layer out of the emulator project and compile it separately as a DLL. Now that DLL is referenced in the emulator and the separate applications, so when the types are loaded dynamically they are considered to be the same type after all.