【问题标题】:Project dependency missing in deployment project部署项目中缺少项目依赖项
【发布时间】:2010-09-13 04:14:00
【问题描述】:

我有一个 VS2008 部署项目,它为几个 Windows 服务构建安装程序。

每个服务引用几个不同的项目:

CustomerName.MailSendingService -> 客户名称.网络 -> 客户名称.数据 -> CustomerName.Security CustomerName.ProductIntegrationService -> 客户名称.Core -> CustomerName.Security

Windows服务项目、它们引用的项目、部署项目都在同一个VS2008解决方案中。

我在部署项目的文件系统编辑器中添加了 Windows 服务项目的主要输出。

我的期望是 Windows 服务项目的主要输出将包括来自引用项目的 DLL。但是,在构建部署项目时,缺少引用项目之一的 DLL。 (CustomerName.ProductIntegrationService 不见了CustomerName.Security

令人发指的是,Windows 服务引用的其他项目的 DLL 都存在;仅缺少一个项目的输出。

(编辑)我已验证在引用属性窗口中将引用设置为复制本地。引用项目的 DLL 放置在 Windows 服务项目的 bin\Release 文件夹中,但未打包在为部署项目构建的 MSI 文件中。

(编辑 2)按照 Joseph Daigle 的建议,我检查了依赖项是否在主输出的依赖项列表中,并且它没有标记为“排除”,因此这似乎不是导致此问题的原因。

为什么只缺少一个项目的输出?

【问题讨论】:

  • 这对我来说仍然是 VS2010 中的一个问题

标签: visual-studio-2008 deployment-project


【解决方案1】:

我还没有使用 Visual Studio 2008,但是在 2005 年,您必须验证项目中缺少的引用是否将 Copy Local 属性设置为 true。

这会将丢失的文件复制到输出目录。

【讨论】:

    【解决方案2】:

    除了 hectorsq 的响应之外,请验证依赖关系是否在部署项目依赖项列表中,并且有问题的 DLL 是否已标记为包含。

    【讨论】:

    • 你能解释一下你所说的“标记为包含”是什么意思吗?我已经验证了依赖项在主输出的依赖项列表中,并且没有标记为“排除”。
    • 对不起,这就是我的意思,它没有被标记为“排除”。不幸的是,它似乎应该被包括在内,所以我很难过。
    【解决方案3】:

    您是否尝试过在反射器中查看您的 dll,看看它是否真的依赖于其他 dll? VS 足够聪明,如果它可以看到您实际上并没有使用它,它不会包含引用的程序集。

    此外,即使你“认为”你正在使用它,VS 也可以优化你的使用 - 这是一个极限情况,但我已经看到了:

    例如,如果您有一个包含以下内容的“常量”程序集:

    public const string LockPanelUrn = "ApplicationRack.LockPanel";
    

    VS 会将字符串直接粘贴到您的引用代码中。

    除此之外,我建议删除并重建您的安装解决方案。

    【讨论】:

      【解决方案4】:

      您是否在最初创建部署项目后添加了此程序集依赖项?如果是这样,您可能需要右键单击 Detected Dependencies 文件夹并选择 Refresh Dependencies。它会拾取自您上次执行此操作以来添加的任何新内容。

      【讨论】:

      • 我已经这样做了,但实际上,在文件系统视图的“主输出...”中,属性“输出”没有列出引用的 dll,这让我认为它不是这样工作的。
      【解决方案5】:

      我可以验证这对我们来说也是一个问题。我怀疑这是部署项目中的一个错误——它只在一个位置添加了依赖项目的输出(也许它认为它是一个 COM dll?)

      为丢失的 dll 手动添加主输出似乎是一种可行的解决方法。

      【讨论】:

        【解决方案6】:

        检查一下 - 也许这不能解释为什么会这样,但至少它提供了一些解决方法:)

        http://lo-sharpdevs.blogspot.com/2009/07/vs-2008-disappearing-dependencies.html

        【讨论】:

          【解决方案7】:

          在重现相同的可疑 msi 缺陷后,我还有一些内容要添加。

          1) 当我添加第二个项目输出共享相同检测到的依赖项到安装程序时,它没有自动添加依赖项。我删除了两个项目输出并以相反的顺序将它们添加回来。添加的第二个项目输出从未添加检测到的依赖项。这不包括项目的任何配置或代码问题以及引用的添加方式。失败的总是第二个。

          2) 在使用“手动添加检测到的程序集”解决方法后,我的团队实际上遇到了第二个问题。最初我们从 '\Program Files\xxx' 中的位置添加依赖项,但在 64 位机器上遇到了构建问题,即使 VS 足够聪明,在 '\Program Files (x86)\xxx' 文件夹中也存在相同的依赖项在获取参考文献时处理这个问题。

          • 手动添加程序集的正确方法是导航到 bin 文件夹并添加在本地复制的程序集。这可确保在 x86 或 x64 机器上存在正确的程序集。

          【讨论】:

            【解决方案8】:

            我在使用 Microsoft SMO 对象时遇到过类似问题。我有一个二进制组件 (X.dll),它使用我自己制作的这些 Microsoft SMO 对象。编译 X.dll 后,我在另一个使用 X.dll(而不是代码)的 EXE 项目中引用它。附加的安装程序项目检测到它需要 Microsoft SMO 对象,并检测到它们是我在机器上安装的 SQL Server 的本地。

            使用 SMO 对象的组件 X.dll 通过我保存在共享驱动器上的本地“外部”文件夹引用 Microsoft SMO 对象。所有模块都是参考这些模块编译的,但是我的 EXE 项目的安装项目会从我的 SQL Server 安装中检测到这些模块。

            因此,我们有另一台机器的“Externals”文件夹中包含 SMO 对象,但安装项目将不再从“检测到的依赖项”中找到 SMO 对象,因为它没有意识到 SMO 对象在外部模块!我不确定它在哪里搜索 Detected Dependancy 文件,但它没有查看 X.dll 最初从哪里获取它们,甚至可能是 EXE 文件夹......

            【讨论】:

              猜你喜欢
              • 1970-01-01
              • 1970-01-01
              • 2011-05-14
              • 1970-01-01
              • 1970-01-01
              • 1970-01-01
              • 2018-07-14
              • 2012-03-30
              相关资源
              最近更新 更多