根据this,应该可以引用解决方案之外的项目,并让它在VS和命令行中工作,但不能在TFS中工作。
不幸的是,当我尝试以这种方式对我的解决方案进行分区时,它在VS2010 / devenv和msbuild中都不起作用。
在这两种情况下,错误都是:
未为项目“Common.csproj”设置OutputPath属性。 请检查以确保您指定了有效组合 该项目的配置和平台。配置=“调试” 平台= 'AnyCPU'。如果某些其他项目也可能出现此错误 正试图遵循该项目的项目到项目参考, 此项目已卸载或未包含在解决方案中,并且 引用项目不使用相同或等效的构建 配置或平台。
但是,当前的平台是“x86”,无论我在VS或msbuild中设置哪个平台和配置,它总是尝试Debug|AnyCPU
。在msbuild的情况下如果我设置/p:OutputPath=bin\x86\Debug
它会正确地传播到子项目。
这是一个错误,我可以解决它吗?
更新
找到bug in MS Connect。不幸的是因为无法修复而关闭:(
更新2
找到解决方法:设置ShouldUnsetParentConfigurationAndPlatform=false
。在msbuild的命令行和项目文件中(在任何导入之前)都修复Visual Studio。
答案 0 :(得分:0)
如果我正确理解了问题,那实际上是因为AssignProjectConfiguration目标未正确设置这些项目的配置/平台属性。
如果你知道它们的配置和平台应该是什么,你可以随时注入一个目标,在AssignProjectConfiguration目标之后立即运行,并覆盖表示未解析的每个项目的SetConfiguration和SetPlatform属性(意味着不是解决方案配置的一部分)项目间参考。
由于某些愚蠢的原因,Microsoft提供的目标将未解析的项目引用列表存储在与已解析的项目相同的集合中(但不是其他地方),这为您提供了2个选项:
无论哪种方式,一旦获得正确配置的项目引用列表,就可以简单地将ProjectReferenceWithConfiguration项目组中未解析的项目替换为手动修改的对应项目(使用另一个带有Remove的动态ItemGroup元素,然后是Include)。 / p>
请注意,我不会按照你这样做的方式做事。如果您想将产品拆分为多个解决方案,那么我只需让每个解决方案将共享输出发布到一个公共暂存区域,并使用.proj脚本将它们链接在一起。我已经学会了命令行风格的MSBuild和内部VS风格的MSBuild不混合的困难方式(他们做了一些奇怪的妥协以确保与非MSBuild项目系统的互操作性,其中整个AssignProjectConfiguration-with-VS -provided-solution-config-XML过程就是一个。
答案 1 :(得分:0)
我在VS2012中遇到过类似的东西。对我而言,它与构建期间ShouldUnsetParentConfigurationAndPlatform目标设置为 true 的AssignProjectConfiguration属性相关。这导致“ GlobalPropertiesToRemove = Configuration; Platform ”导致清除Configuration和Platform属性以进行项目引用。
我能够通过在设置工具后查看构建输出窗口来看到这种情况 - >选项 - >项目和解决方案 - >构建和运行 - > MSBuild项目构建输出详细程度 - >诊断
使用空白配置/平台,这导致我的一些项目中的以下行匹配,导致项目输出中的调试程序集即使在发布版本中也是如此:
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
解决方案是修改那些csproj文件以指定Release作为配置变量为空/空白时使用的配置:
<Configuration Condition=" '$(Configuration)' == '' ">Release</Configuration>