C# 单独运行子进程时，原始DLL会受到影响

我正在开发一个用vb设计的Windows应用程序，它有相当多的模块通过反射连接到它。每个模块还附带了一个嵌入式sql文件，用户登录时将执行该文件

我试图使用一个单独的控制台执行这些嵌入式sql文件。因此，我提取了代码并构建了一个控制台应用程序。一些模块的应用程序执行失败，我想我可能错过了一些东西。 问题是，当我在控制台应用程序执行后选择实际应用程序时，失败的模块在实际应用程序中也会失败

我不知道为什么？在干净的设置中，原始应用程序没有问题。

---

我没有引用任何东西，从我的控制台应用程序到原始窗口应用程序，反之亦然。应用程序正在特定于版本的DLL上运行。有人能帮我指出正确的方向吗？

谢谢你的回答，我认为这是缓存/分页问题。早些时候，我尝试将原始代码中的一些dll文件使用到我的代码库中，但在执行过程中，由于原始dll被我的代码库中的dll覆盖，引用变得混乱。我拿了一份原始版本的副本，在控制台执行后重新应用，一切都很好。

我们能为您提供什么帮助？这毫无意义。没有密码。没有错误。没有。有两种类型的绑定1）早期绑定：在编译时定义类型2）晚期绑定：在运行时解析类型。后期类型并不总是与c#一起工作。您可能正在处理使用ActiveX组件的旧代码，Microsoft现在认为这些组件已过时（来自VB 4、5和6）。我在执行过程中遇到的一个错误是“依赖项解析失败，type=“IDummyInterface”，name=”“。异常消息是：当前生成操作（build key build key）[IDummyInterface，null]）失败：当前类型IDummyInterface是接口，无法构造。是否缺少类型映射？（Microsoft.Practices.Unity.UnityContainer.DoBuildUp上的策略类型BuildPlanStrategy，索引3）（类型t，对象存在，字符串名称）错误源于我的控制台应用程序，并一直存在于原始应用程序中。@jdweng:即使这是一个后期绑定场景，错误怎么能传递到最初正常的原始执行中。VB对对象的检查比c#少。c#被管理，并且为了最大限度地减少蓝屏异常，c#对对象进行检查确保内存地址在范围内；c#在强制转换时验证类型。在您的情况下，c#检测到一个异常，然后抛出另一个异常，该异常被传递到下一级代码。