【问题标题】:GAC reference broken when Project moved from one machine to another项目从一台机器移动到另一台机器时 GAC 参考中断
【发布时间】:2015-10-26 12:22:41
【问题描述】:

我有一个 BizTalk 项目,它引用了 GAC 的 dll。当我将此项目从一台机器移动到另一台机器时,引用已损坏,我需要再次添加这些引用。

有没有办法避免这种情况,因为我有 50 多个项目都引用了 GAC,并且要转移到另一台机器上。

【问题讨论】:

  • 添加对存储在 GAC 中的 DLL 的引用是非常错误的。现在你知道为什么了。您需要将它们的副本存储在某个地方,如果您不自己构建它们,则需要将其签入源代码管理,这样您就可以始终确保您可以在任何地方和任何时间重新构建解决方案。
  • @HansPassant,对于这种情况,我不得不不同意你的观点 - 这个 DLL 很可能最终必须被 GACed 以供 BizTalk 使用,并且引用本地副本可以结束与在 GAC 中引用 BizTalk 将在运行时实际使用的问题相比,很难追踪问题。完整答案如下。

标签: visual-studio biztalk gac


【解决方案1】:

是的,您可以通过在迁移项目之前在新机器上对所有引用的程序集进行 GAC 处理来避免此问题。就像它们在当前机器上一样。这确实没有什么问题。

在引用 GAC 程序集时,Visual Studio 的行为有所不同。我不知道确切的规则是什么,但通常情况下,即使选择 GAC 之外的程序集作为参考目标,Visual Studio 也会显示对 GAC 的引用。我说显示 GAC 的参考,因为如果您检查项目文件,只会列出程序集的字符串名称列表,而不是完整路径。 Visual Studio 首先会探测 GAC,如果找到匹配项,就会使用它。

这都是 Visual Studio 行为,与 BizTalk 没有直接关系。

【讨论】:

    【解决方案2】:

    对于 BizTalk 项目,这是一个不错的做法 - BizTalk 将从 GAC 中提取库(而不是从您的程序集在构建时认为它所在的位置)。引用本地 DLL 或解决方案可能会导致非常具有挑战性的场景,其中 DLL 的本地副本从未获得 GACed,并且在单元测试中有效的行为在 BizTalk 中无效。解决方法很简单:GAC 在新机器上组装。

    这里有两种可能的情况 - 您正在尝试引用您自己构建的程序集(如 C# 实用程序库),或者您正在引用第 3 方 DLL。

    如果是第一个,那么在该 C# 库的 Post Build 事件中,在构建程序集后向 GAC 添加一些逻辑。例如,

    call "$(DevEnvDir)..\Tools\vsvars32.bat"
    gacutil /if "$(TargetPath)"
    

    然后,请确保您先构建该项目。

    否则,如果您要引用预构建的库,请将类似的逻辑添加到依赖项目的 prebuild 阶段 - 并将库作为资源包含在您的解决方案中(在源代码管理中) .

    【讨论】:

    • 您是在 BizTalk 服务器上安装 VS 吗?很难想象这是一种常见的做法。
    • 在开发环境中是必需的。您首先安装 VS,然后安装 BizTalk Server - 通常是开发人员版本。当你去部署你的程序集时,参考的是 GAC,无论如何,程序集都必须用于 BTS。
    猜你喜欢
    • 2021-10-15
    • 2016-10-29
    • 2023-03-27
    • 1970-01-01
    • 2019-02-15
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多