单独运行子进程时会影响原始dll

Posted 2023-04-13

【中文标题】单独运行子进程时会影响原始dll

【英文标题】：Original dlls are affected when running a sub process separately

【发布时间】：2020-03-27 03:39:36

【问题描述】：

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

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

我不知道为什么？在干净的设置中，原始应用程序没有问题。 我没有引用从我的控制台应用程序到原始窗口应用程序的任何内容，反之亦然。该应用程序在特定于版本的 dll 上运行。有人可以帮我指出正确的方向吗？

【问题讨论】：

我们有什么可以帮助您的吗？这没有任何意义。没有代码。没有错误。什么都没有。

有两种类型的绑定 1) 早期绑定：类型在编译时定义 2) 后期绑定：类型在运行时解析。后期类型并不总是适用于 c#。您可能正在处理使用 Microsoft 已过时的 ActiveX 组件的旧代码（从 VB 4、5 和 6 开始）。

我在执行过程中遇到的一个错误是“依赖项解析失败，类型 = “IDummyInterface”，名称 = “”。异常消息是：当前构建操作（构建密钥 Build Key [IDummyInterface, null]) 失败：当前类型 IDummyInterface 是一个接口，无法构造。您是否缺少类型映射？（策略类型 BuildPlanStrategy，索引 3）在 Microsoft.Practices.Unity.UnityContainer.DoBuildUp(Type t , Object existing, String name)" 错误源自我的控制台应用程序并持续存在于原始应用程序中。

@jdweng：即使这是一个后期绑定场景，错误如何传递到最初没问题的原始执行。

VB 对对象的检查比 c# 少。 c# 被管理并最小化蓝屏异常 c# 会检查对象以确保内存地址在范围内；并且 c# 在强制转换时验证类型。在您的情况下，c# 正在检测一个异常，然后抛出另一个异常，该异常被传递给下一级代码。

【参考方案1】：

感谢您的回复，我认为这是缓存/分页问题。早些时候，我尝试将原始代码中的一些 dll 文件使用到我的代码库中，但是在执行时，引用变得混乱，原始 dll 被我的代码库拥有的 dll 覆盖。我复制了一份原件并在控制台执行后重新应用它们，一切正常。