我有几个解决方案。
在第一个解决方案中，我有很多项目。其中一个名为“A”的项目具有同一解决方案的另一个项目“B”的项目引用。
在第二个解决方案中，项目“A”已添加，但项目“B”未添加。
两种解决方案都能成功构建。
然而，在第二个解决方案中，参考 在项目A中添加的B，出现 碎。
为什么？
现在，在第一个解决方案中，我只是将B的DLL（在为所有项目创建的公共输出目录中复制）的“文件引用”添加到A中，而不是将B的Project引用添加到A中。在解决方案和第一个解决方案都没有成功构建时，引用似乎已断开。
我可以知道我应该怎么做 有这样的场景吗？
编辑：我查看了项目A的项目文件，发现B的项目引用的路径（<ProjectReference Include = "..\B\B.csproj" />属性）是相对路径。 （比如“.. \ B \ B.csproj”）。
我想这就是为什么这个引用在第二个程序集中出现故障的原因，因为程序集B不是第二个解决方案的一部分，显然在使用相对路径解析引用时“B.csproj”不可用。
答案 0 :(得分：1)
在第一个解决方案中，您将“B”添加为项目“A”的“项目参考”。现在，当您将项目“A”添加到第二个解决方案时，它在第二个解决方案中查找“项目B”（因为它是“项目参考”），它显然无法找到它，因此它显示了警告。
然而，在运行时，项目“A”知道在哪里找到项目B的输出，因此引用将被重新获得，并且在运行时不应该有问题。 （这就是两个解决方案成功构建的原因）
对于第二种情况（直接添加对B的DLL的引用），它对我来说效果很好。当您说“添加文件引用”时，我假设您的意思是直接添加对DLL的引用（右键单击References-＆gt; Add Reference-＆gt; Assemblies-＆gt; browse-＆gt; B.dll），还是有另一种我不知道的方式？ ：■
希望这有助于：）
答案 1 :(得分：1)
有两种方法可以引用项目的输出：
当您没有将该程序集作为解决方案的一部分创建的项目时，将使用第一个方案。通常，这用于引用来自第三方的程序集，或者不会经常更改的程序集。
第二种情况要求您引用的项目出现在解决方案中。
听起来你混合了引用，创建了一个不属于解决方案的项目的项目引用。这不起作用。