【问题标题】:Reference another project with Copy Local on it's reference在其参考上使用 Copy Local 参考另一个项目
【发布时间】:2012-10-26 04:36:34
【问题描述】:

我有一个项目“ProjA”,它包含了对其他几个项目和一些“插件”程序集的引用。所有这些引用都将 Copy Local 设置为“True”。请注意,插件程序集中的代码(它们是项目引用)不是直接在“ProjA”中引用的,而是通过 DI/Ninject 加载和定位的。 (所以我使用这些项目引用作为将插件程序集放入输出文件夹的一种方式,原因见下文)

我还有一个项目“ProjB”,它引用了 ProjA。它使用引用的插件程序集调用应该执行此操作的 ProjA 代码。

问题是,它不起作用。插件程序集不会从 ProjA 输出文件夹(它们被“复制到本地”)复制到 ProjB 输出文件夹中。所以 Ninject 没有加载它们,事情就失败了。

所以我的两个问题:

  • 如果我已向 VS/msbuild 指示 ProjA 引用项目 P1、P2、P3、P4,并将本地复制设置为 true - 为什么它会假设只需要主输出程序集来使 ProjA 工作?我可以让它有不同的想法吗?
  • 我猜想添加对插件程序集的复制本地引用作为让 VS 识别插件和使用它们的项目之间的构建依赖关系的一种方式(当前是一组固定的插件,因此这条路线) - 不是理想的。然后我认为将插件程序集作为“内容”添加到项目中会起作用,但是我有两个问题:1)TFS 源代码控制;插件项目需要一个可写的目标来构建,大概 - 内容文件将被“签入”并且 2)一些插件有自己的内容:有了引用,我不必担心会丢失一些东西。走内容路线,我需要参考另一个项目的构建输出文件夹,包括它的所有内容,但不包括 PDB .. 似乎更 hacky!

我还考虑并使用了任何一个插件项目的构建后步骤(不理想:我将它们从另一个解决方案中拉入这个新解决方案,如果我添加构建后步骤,它可能会搞砸另一个解决方案)或依赖于它们的项目(这没关系,但是具有相对路径的 XCopy,并且必须手动设置项目依赖关系.. 似乎又更老套了)。

我有什么遗漏吗,有什么想法吗?如果将复制本地链接到项目引用中,它将非常适合..

【问题讨论】:

  • 做更多研究,似乎构建到单个输出文件夹是关键。我这样做是为了“其他”解决方案,即插件主要驻留的解决方案。那么对于这个解决方案,我如何让项目构建到 new 'single' 输出文件夹?

标签: c# .net visual-studio msbuild visual-studio-2012


【解决方案1】:

Visual Studio 或 msbuild 似乎不可能。

【讨论】:

    【解决方案2】:

    Copy local = true 是 VS 万恶之源。 好吧,至少是。

    我只想说 - 不要使用它。拥有一个不错的输出目录,例如 T:\Bin,然后使用构建后脚本将所需的所有内容复制到该目录。并从那里跑。 不要只相信VS,像瞎老鼠一样四处走动。

    您也可以考虑使用 GAC。

    【讨论】:

    • 错过了关于为什么我不能使用单个输出文件夹的评论?
    • ..由于项目位于多个解决方案中,因此项目的构建后脚本不起作用?
    • 两个 cmets 对我来说都不清楚。后期构建只是在成功构建时执行的脚本。他们可能会也可能不会使用项目特定的参数 S.A ${ProjectDir}。
    • 插件项目的输出目录已经设置好了 - 我在另一个解决方案中使用它们,因此无法更改它们以适应。构建后步骤也是每个项目的,如果我在这里添加它们,它会弄乱我的其他解决方案.. 不是吗?
    • 不,它不会“搞砸”任何东西...只需在最后一个要构建的项目中为所有二进制文件(.exe、.dll、.whatever 你需要运行)添加一个 xcopy,仅此而已.或者将它们全部放在同一个解决方案下 - 毕竟它们确实相互依赖。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2015-09-03
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2016-09-20
    • 1970-01-01
    相关资源
    最近更新 更多