我知道这是踢死马，但我有这个错误和框架在哪里好。我的问题基本上是声明无法找到接口，但它构建和访问都很好。所以我开始思考:“为什么只有这个界面，而其他人都工作得很好?”

最终，我使用WCF的端点接口访问了一个服务，该端点接口使用的是实体版本6，而其余的项目使用的是版本5。我没有使用NuGet，而是简单地将NuGet包复制到本地存储库以供重用，并以不同的方式列出它们。

例如，EntityFramework6.dll vs . EntityFramework.dll。

然后，我将引用添加到客户端项目，噗的一声，我的错误消失了。我意识到这是一个边缘情况，因为大多数人不会混合实体框架的版本。

我知道这个线程是旧的，但无论如何我共享，我必须安装导入程序集的所有第三方依赖项-因为导入的程序集不包括在Nuget包中，因此它的依赖项丢失了。

跳这个帮助:)

我在试图以代理的身份在本地机器上运行Visual Studio Team Services构建时遇到此错误。

它在我的常规工作空间中工作得很好，我能够在本地代理文件夹中打开SLN文件，一切都编译好了。

有问题的DLL存储在项目中Lib/MyDLL.DLL，并在csproj文件中引用此DLL:

<Reference Include="MYDLL, Version=2009.0.0.0, Culture=neutral, PublicKeyToken=b734e31dca085caa">
  <SpecificVersion>False</SpecificVersion>
  <HintPath>Lib\MYDLL.dll</HintPath>
</Reference>

结果是，尽管有提示路径，它还是找不到文件。我认为msbuild可能是相对于SLN文件而不是项目文件。

在任何情况下，如果您得到的消息是无法解析此引用。无法定位程序集，请确保DLL位于msbuild可访问的位置。

我有点作弊，发现一条消息说“参考\bin\xxx.dll”，然后把dll复制到那里。

在构建解决方案时，我得到了相同的错误(类型或名称空间' '找不到)。在它下面，我看到一个警告，声明“引用无法解析”，并确保“程序集存在于磁盘上”。

我非常困惑，因为我的DLL非常清楚地位于引用所指向的位置。VS似乎没有突出显示任何错误，直到我尝试构建解决方案。

我终于意识到问题所在(或者至少我怀疑是问题所在)。我在同一个解决方案中构建库文件。因此，即使它存在于磁盘上，它也在那个位置被重新构建(在库重新构建的过程中，我的另一个项目-在同一解决方案中-引用了库，必须确定库不存在)

当我右键单击项目并只构建该项目，而不是整个解决方案时，我没有得到错误。

为了解决这个问题，我将库作为依赖项添加到正在使用它的项目中。

这样做:

我在解决方案资源管理器中右键单击我的解决方案并选择 “属性” 然后在“Common Properties”中选择“Project Dependencies”。 然后在项目下拉菜单中，我选择了项目 依靠图书馆，而且 选中“依赖”下的库旁边的复选框

这确保首先构建库项目。

在将一些新代码合并到vs2019项目后遇到了同样的问题。 重新启动VS，卸载和重新加载项目，确保解决方案中所有项目ToolsVersion=和TargetFrameworkVersion相同。这些都无济于事。

我有一个项目基板的情况，未能找到名称空间皮肤(在项目皮肤)。

最后我打开了基板。并检查了所有的ProjectReference Include条目。其他的都在那里，但没有对Skin的引用，即使Skin确实显示在小项目依赖对话框的复选框中。因此，项目依赖关系对话框接受了皮肤的复选框(并将其保存在某个地方)，但没有改变basis .csproj。然后我手动添加ProjectReference Include，确保我拥有皮肤项目的正确路径和GUID。

< ProjectReference Include = " \ Skin皮肤csproj”>。 < > {1ad4b5d7-5014-4f5f-983e-2c59ac0e0028} < - >项目项目 < Name > Skin - < Name > < / ProjectReference >

然后我保存了基板。Csproj，问题就解决了。正如其他人所说，这是VS工具的一个问题

它甚至发生在Visual Studio 2017中。

重启Visual Studio 无法构建的干净项目。 重新构建项目。