找不到元数据文件“.dll”

时间:2009-09-14 14:20:00

标签: c# .net wpf visual-studio-2008 c#-3.0

我正在开发一个WPF,C#3.0项目,我收到了这个错误:

Error 1 Metadata file
'WORK=- \Tools\VersionManagementSystem\BusinessLogicLayer\bin\Debug
\BusinessLogicLayer.dll' could not be found C:\-=WORK=- \Tools
\VersionManagementSystem\VersionManagementSystem\CSC VersionManagementSystem

这是我引用usercontrols的方式:

xmlns:vms="clr-namespace:VersionManagementSystem"
<vms:SignOffProjectListing Margin="5"/>

每次失败的构建后都会发生这种情况。我可以获得编译解决方案的唯一方法是注释掉我的所有用户控件并重新构建项目,然后我取消注释用户控件,一切都很好。

我已检查构建顺序和依赖项配置。

正如您所看到的,它似乎已经截断了DLL文件的绝对路径...我已经读过有一个长度错误。这可能是一个问题吗?

这非常烦人,不得不评论,构建和取消注释,构建变得非常烦人。

99 个答案:

答案 0 :(得分:733)

我遇到了同样的问题。 Visual Studio不构建正在引用的项目。

  1. 右键单击解决方案,然后单击“属性”。
  2. 点击左侧的配置。
  3. 确保选中“无法找到的项目”的“构建”下的复选框。如果已经选中,请取消选中,点击“应用”并再次选中复选框。
  4. (可选)您必须对解决方案属性的发布和调试模式执行此操作。

答案 1 :(得分:199)

在较新版本的Visual Studio中仍然会发生这种情况(我只是在Visual Studio 2013上发生过):

要尝试的另一件事是关闭Visual Studio并删除.suo文件旁边的.sln文件。 (它将在您下次Save all(或退出Visual Studio)时重新生成。)

在将新项目添加到另一台计算机上的解决方案然后拉入修订版时,我遇到了这个问题,但.suo文件在其他情况下也可能被破坏,导致非常奇怪的Visual Studio行为,所以删除它是我经常尝试的事情之一。

请注意,删除.suo文件将重置解决方案的启动项目。

.suo文件的更多内容为here

答案 2 :(得分:138)

建议的答案对我不起作用。该错误是另一个问题的诱饵。

我发现我的目标是稍微不同的.NET版本,这被编译器标记为警告,但它导致构建失败。 这应该被标记为错误而不是警告。

答案 3 :(得分:90)

嗯,我的答案不仅仅是所有解决方案的摘要,而且还提供了更多。

第(1)节:

一般解决方案:

我有四种此类错误(“无法找到元数据文件”)以及一条错误说“源文件无法打开”(“未指定的错误”)&#39;。

我试图摆脱'无法找到元数据文件'的错误。为此,我阅读了很多帖子,博客等,发现这些解决方案可能有效(在此汇总):

  1. 重新启动Visual Studio并再次尝试构建。

  2. 转到&#39;解决方案资源管理器&#39; 。右键单击Solution。转到属性。转到&#39; Configuration Manager&#39; 。检查是否选中了&#39; Build&#39; 下的复选框。如果未选中任何一个或全部,请检查它们并再次尝试构建。

  3. 如果上述解决方案不起作用,请按照上面步骤2中提到的顺序进行操作,即使选中了所有复选框,也请取消选中它们,再次检查并再次尝试构建。

  4. 构建订单和项目依赖关系:

    转到&#39;解决方案资源管理器&#39; 。右键单击Solution。转到&#39;项目依赖关系......&#39; 。您会看到两个标签:&#39;依赖关系&#39; &#39;建立订单&#39; 。此构建顺序是构建解决方案的顺序。检查项目依赖项和构建顺序,以验证某个项目(例如&#39; project1&#39;)是否依赖于其他项目(例如&#39; project2&#39;)是否正在尝试在该项目之前构建(project2) 。这可能是导致错误的原因。

  5. 检查缺失.dll的路径:

    检查丢失的.dll的路径。如果路径包含空格或任何其他无效路径字符,请将其删除并再次尝试构建。

    如果这是原因,请调整构建顺序。


  6. 第(2)节:

    我的具体案例:

    我尝试了上述所有步骤,并重新安装了Visual Studio几次。但是,它对我没有帮助。

    所以,我决定摆脱我遇到的其他错误(&#39;源文件无法打开('未指定的错误')&#39;)。

    我发现了一篇博文: TFS Error–Source File Could Not Be Opened (‘Unspecified error ‘)

    我尝试了该博文中提到的步骤,我摆脱了错误&#39;源文件无法打开('未指定的错误')&#39; ,令人惊讶的是我摆脱了其他错误('无法找到元数据文件')


    第(3)节:

    故事的道德:

    尝试上面第(1)节中提到的所有解决方案(以及任何其他解决方案)以消除错误。如果没有任何效果,根据上面第(2)节中提到的博客, 从.csproj文件中删除源控件和文件系统中不再存在的所有源文件的条目

答案 4 :(得分:35)

在我的情况下,它是由.NET Framework版本不匹配引起的。

一个项目是3.5,另一个项目是4.6.1。

答案 5 :(得分:25)

关闭并重新打开Visual Studio 2013对我有用!

答案 6 :(得分:16)

嗯,以前的答案中没有任何内容对我有用,所以它让我思考为什么我点击并希望何时作为开发人员我们应该真正尝试了解这里发生了什么。

我觉得这个错误的元数据文件引用必须保存在某个地方。

快速搜索.csproj文件显示出有罪的行。我有一个名为&lt; itemGroup&gt;的部分这似乎挂在旧的不正确的文件路径上。

<ItemGroup>
    <ProjectReference Include="..\..\..\MySiteOld\MySite.Entities\MySite.Entities.csproj">
        <Project>{5b0a347e-cd9a-4746-a3b6-99d6d010a6c2}</Project>
        <Name>Beeyp.Entities</Name>
    </ProjectReference>
...

真的很简单:

  1. 备份.csproj文件。
  2. 在.csproj文件中找到不正确的路径并正确重命名。
  3. 确保在摆弄之前备份旧的.csproj。

答案 7 :(得分:14)

我也遇到了这个问题。首先,您必须通过右键单击Build来手动构建DLL项目。然后它会工作。

答案 8 :(得分:13)

我收到同样的错误&#34;元数据文件&#39; .dll&#39;无法找到&#34;,我尝试了上面描述的几个方面,但错误的原因是我引用的是第三方DLL文件,该文件的目标是.NET版本高于我的项目目标.NET版本。所以解决方案是改变我的项目的目标框架。

答案 9 :(得分:11)

在我的情况下,我以错误的方式安装了我的目录。

如果您的解决方案路径类似于“我的项目%2c非常受欢迎的%2c单元测试%2c软件和硬件.zip”,它无法解析元数据文件,也许我们应该防止一些无效的单词,如%2c。

将路径重命名为普通名称解决了我的问题。

答案 10 :(得分:10)

我在我的解决方案中添加了一个新项目并开始实现这一目标。

原因?我带来的项目是针对不同的.NET框架(4.6和我的另外两个是4.5.2)。

答案 11 :(得分:9)

对我来说,它试图在用于包含Project的路径中找到DLL,但我们已将其移动到新目录。解决方案有正确的项目路径,但Visual Studio以某种方式继续查看旧位置。

解决方案:重命名每个问题项目 - 只需添加一个字符或其他内容 - 然后将其重命名为原始名称。

这必须在Visual Studio中重置某种全局缓存,因为这样可以清除这个问题和类似的几个缓存,而像Clean这样的东西不会。

答案 12 :(得分:9)

对我而言,当我将一个新项目纳入解决方案时就发生了。

Visual Studio自动选择.NET framework 4.5。

我像其他库一样更改为.NET 4.5.2版本,并且工作正常。

答案 13 :(得分:8)

对我来说,以下步骤有效:

  • 找到未构建的项目
  • 删除/添加对解决方案中项目的引用。

答案 14 :(得分:8)

我也在解决这个问题,但是在尝试了之前的答案之后,对我来说唯一有用的就是在我的解决方案中逐个打开每个项目并单独构建它们。

然后我关闭了Visual Studio 2013,重新打开了我的解决方案并且编译得很好。

这很奇怪,因为如果我在解决方案资源管理器中单击每个项目并尝试以这种方式构建它们,那么它们都会失败。我不得不在他们自己的解决方案中单独打开它们。

答案 15 :(得分:7)

我在Visual Studio 2012中遇到了一个包含许多项目的解决方案。按照与项目构建顺序相同的顺序手动重建解决方案中的每个项目(在解决方案资源管理器中右键单击并重建)为我修复了它。

最终我找到了一个给我编译错误的程序。我修复了错误,之后解决方案就会正确构建。

答案 16 :(得分:7)

我的问题实例是由一个公共项目引起的,该项目中有一个重复的类名(在不同的文件名下)。奇怪的是,Visual Studio无法检测到这一点,而只是炸毁了构建过程。

答案 17 :(得分:6)

在我的情况下,问题是我手动删除了一个标记为“缺失”的非编译文件。一旦我删除了对现在丢失文件的引用并重新编译 - 一切都很顺利。

答案 18 :(得分:6)

几年后再回到这个问题,这个问题很可能与Windows最大路径限制有关:

Naming Files, Paths, and Namespaces Maximum Path Length Limitation

答案 19 :(得分:6)

在我的情况下,问题是由简单的构建错误引起的,

  

错误CS0067:事件&#39; XYZ&#39;永远不会使用

由于任何原因,没有出现在错误窗口中。

因此,Visual Studio构建系统似乎错过了错误,并尝试构建依赖项目,而这些项目又因烦人的元数据消息而失败。

建议是 - 听起来很愚蠢 - :

首先查看输出窗口

这个想法让我感到震惊了半个小时......

答案 20 :(得分:5)

看起来这类错误与Visual Studio无法提供有关错误的正确信息有关。开发人员甚至不了解构建失败的原因。它可能是语法错误或其他。通常,要解决此类问题,您应该找到问题的根源(例如,查看构建日志)。

在我的情况下,问题实际上是Error List窗口没有显示任何错误。但确实存在语法错误;我在Output窗口中发现了这些错误,在修复它们之后,问题就解决了。

答案 21 :(得分:5)

我遇到了同样的问题。就我而言,我所引用的类库项目具有比我的项目更高的 .Net版本,而VS无法构建该项目并引发了与您发布的错误相同的错误。

我只需将我的类库项目的 .Net版本(已破坏构建的项目)设置为与引用项目的.Net版本相同,即可解决问题。

答案 22 :(得分:5)

我也有同样的错误。它隐藏在下面的路径中。 我提到的DLL文件的路径就像“D:\ Assemblies Folder \ Assembly1.dll”。

但程序集引用的原始路径是“D:\ Assemblies%20Folder \ Assembly1.dll”。

由于此路径名称变化,无法从其原始路径检索程序集,因此会抛出“未找到元数据”错误。

解决方案是Stack Overflow问题 How do I replace all the spaces with %20 in C#?

答案 23 :(得分:4)

如果使用假装配,则可能会显示此错误。删除假货可以成功构建项目。

答案 24 :(得分:4)

就我而言,我在特定(空)命名空间中注释了类:

namespace X.Y.Z.W
{

    // Class code

}

当我删除命名空间代码及其导入(使用)命令时 - 它修复了问题。

在构建中它还说 - 以及项目缺少的DLL文件:

  

错误CS0234:命名空间“X.Y.Z”中不存在类型或命名空间名称“W”(您是否缺少程序集引用?)

答案 25 :(得分:4)

我在尝试发布Web应用程序时遇到此错误。原来,其中一个类属性被包装成

#if DEBUG
    public int SomeProperty { get; set; }
#endif

但财产使用情况并非如此。发布是在发布配置中完成的,显然没有DEBUG符号。

答案 26 :(得分:4)

只是指出明显的明显:如果你没有启用“在构建开始时显示输出窗口”,请确保你注意到你的构建是否失败(左下方的小“构建失败”错误)! !!

答案 27 :(得分:4)

如果您的解决方案名称中有空格,这也会导致问题。从解决方案名称中删除空格,因此路径不包含%20将解决此问题。

答案 28 :(得分:4)

根据错误消息,我不相信文件路径被截断。它看起来是不正确的。如果我正确读取消息,它似乎正在寻找...

的DLL文件
  

工作= - \工具\ VersionManagementSystem \ BusinessLogicLayer \ BIN \调试\ BusinessLogicLayer.dll

这不是有效路径。是否有可能在构建过程中将宏定义设置为无效值?

答案 29 :(得分:4)

我正在运行Visual Studio 2013。

似乎构建依赖项不正确。删除* .suo文件确实解决了我遇到的问题。

答案 30 :(得分:3)

在我看来,解决方案中的一些项目是针对任何CPU ,其中一些是针对x86的。在整个解决方案中统一平台目标后,编译错误消失了。

答案 31 :(得分:3)

我遇到了这个问题,因为.nuget\NuGet.exe未包含在我的存储库中。虽然我在NuGet.targets中启用了DownloadNuGetExe,但在尝试下载时报告了代理错误。这导致项目构建的其余部分失败。

答案 32 :(得分:3)

在我的情况下,我遇到了这个错误,因为我的一个项目使用了与其他解决方案不同的.NET框架版本。我使用NuGet包管理器来安装NLog,所以我认为它是为这个项目的.Net版本安装的。

我尝试了这篇文章的所有解决方案,但没有一个正在运作。我删除了NLog,清理了解决方案并trid编译:同样的事情,CS006错误。

当我从该项目中删除了obj\Debug中解决方案编译的所有文件时。

答案 33 :(得分:3)

在解决方案文件夹中删除包含NuGet的packages文件夹对我有用。重建后,一切都恢复了。检查解决方案中的References并检查具有黄色三角形的参考。

示例图片:

Enter image description here

答案 34 :(得分:3)

就我而言,这些错误是由NuGet包管理器中的一些损坏引起的。解决方案的子项目没有构建,但由于元数据错误,没有显示错误。

一旦所有NuGet包都得到纠正,项目就可以再次正确构建。

答案 35 :(得分:3)

我在4.6.1中有一个类,它引用的是4.6.2中的接口...将该类升级到462可以修复它。

答案 36 :(得分:3)

当我反编译一个在生产环境中部署的非常旧的库时,我遇到了类似的问题,但源代码丢失了。

我使用了.dll,反编译并生成了项目和解决方案。由于这种错误,我无法构建解决方案。

之前答案中的提示没有帮助,但过了一段时间后,我注意到某些项目中缺少对像System.dll这样的程序集的引用。

假设项目A依赖于项目B.项目B中没有对System.dll的引用,但构建后的错误就像&#34;元数据文件&#39; B.dll&#39;无法找到&#34;。

项目B中缺少System.dll没有错误。

在项目B中添加类似System.dll的库的引用解决了这个问题。 (System.Data,System.DirectoryServices等)

答案 37 :(得分:3)

我有同样的问题。就我而言,该项目仍然会在发布模式下构建,就在我尝试构建调试失败的时候。

我最终要解决的问题是将所有dll(以及我的发布文件夹中的其他文件)复制到我的调试文件夹中。在为每个项目执行此操作后,错误消失了。

答案 38 :(得分:3)

我在打开引用实体框架的项目后收到此错误,因此我删除了此类引用,并通过这种方式重新启动了实体框架版本6.0.0.0:

install-package entityframework -version 6.0.0.0

错误仍然显示,所以我认为这些引用是存在的,因为有一个旧版本的实体框架据说&#34;预先安装&#34;在项目上,但它并没有真正起作用。

所以我走到文件packages.config并注意到还有另一个参考:

<packages>
  **<package id="EntityFramework" version="5.0.0" targetFramework="net45" />**
  <package id="EntityFramework" version="6.0.0" targetFramework="net45" />
</packages>

然后我删除了该行,清理并重建了项目和容器解决方案,最终工作了。

答案 39 :(得分:2)

就我而言,ReSharper是愚蠢的,即使我的项目以C#6为目标,我也会被提供重构以使用仅限C#7的功能。

出于这个原因,我最终改变了这段代码,

private DateTime? _joinedDate;
[Column(TypeName = "DateTime2")]
public DateTime JoinedDate
{
    get { return _joinedDate ?? DateTime.Now; }
    set { _joinedDate = value; }
}

进入此代码:

private DateTime? _joinedDate;
[Column(TypeName = "DateTime2")]
public DateTime JoinedDate
{
    get => _joinedDate ?? DateTime.Now;
    set => _joinedDate = value;
}

由于使用表达式主体的getter和setter的某些原因,编译器会出现该元数据错误而不是语法错误。

答案 40 :(得分:2)

正如用户@burzhuy指出的那样,查看Output窗口,而不仅仅是Error List窗口非常重要。

就我而言,我正在努力修改Roslyn编译器。它的构建项目进行额外检查,以查看公共字段是否与已定义为编译器的公共接口的内容一致,否则会产生RS0016或RS0017错误。我添加了几个公共字段,并通过将鼠标悬停在错误上并选择“添加到公共API”修复了RS0016错误。

后来我改变主意,把公共领域搬到另一个班级。由于某种原因,这产生了“无法找到元数据文件的错误”,而且我越弄错,我得到的错误就越多。

您需要找到正确的PublicAPI.Unshipped.txt文件(在我的情况下,它位于E:\Roslyn\32414\src\Compilers\Core\Portable中)并手动编辑以删除不再相关的行。

答案 41 :(得分:2)

当我编写c#7代码但该项目使用的是.net框架的旧版本时,我的问题就来了

答案 42 :(得分:2)

Visual Studio 2019对我有用:

  1. 关闭Visual Studio
  2. 删除隐藏的.vs文件夹
  3. 重新打开Visual Studio并重建解决方案。

答案 43 :(得分:2)

在VS 2019中,通过展开 Analyzers

在项目 References 下检查是否有未解决的项目。

enter image description here

对我来说,有两个.dll文件路径错误。右键单击每个,然后选择删除

enter image description here

构建项目,然后构建解决方案。 完成。

答案 44 :(得分:2)

在我个人的情况下,我未能在解决方案中添加对其中一个项目的引用,这就是为我解决错误的原因。

答案 45 :(得分:2)

问题的原因可能是您在解决方案中添加了对DLL文件和项目的引用。

如果您有项目A,B和C:

  • 将B和C作为解决方案中的项目引用。
  • B将C引用为DLL文件(对文件的引用)

您可以单独构建每个项目,但无法重建以以下结尾的解决方案:元数据文件&#39; C.dll&#39;无法找到。

将参考从文件更改为解决方案中的项目有助于。

答案 46 :(得分:2)

aaaaa和六年后在升级到Visual Studio 2015期间出现同样的问题。由于此特定解决方案不在此列表中,因此我将其添加到其中。

两个引用的dll位于c:\ windows \ system32 ...文件夹中。 将它们移动到非系统文件夹并添加对新文件夹的引用最终修复它。其他问题确实是其他人已经在这里说过的话

答案 47 :(得分:1)

我发现如果您删除Microsoft.CSharp程序集作为项目中的引用,您将收到此错误。

答案 48 :(得分:1)

我在VS2019中遇到了同样的问题。这是您需要做的:

  1. 在某些分支上推送最新更改
  2. 删除项目
  3. 从快速入门中删除项目-您可以尝试引用不存在的项目,它会要求您删除
  4. 克隆项目
  5. 运行项目

答案 49 :(得分:1)

我有一个非常不寻常的错误案例,但是也许有人会从中受益。

我遇到此错误,因为我正在处理的解决方案中的一个项目(具有目标框架netstandard 2.0)缺少.dll文件,而该项目使用的引用(对Microsoft.Office.Interop.Word)一次出错。

此解决方案是从git存储库中克隆的,对于我团队中的其他人来说,同样的解决方案也可以很好地编译。

我尝试了所有建议的解决方案-重新启动VS,计算机;清洁项目;选中和取消选中构建复选框;检查构建顺序是否正确等。

我发现默认情况下未选择此项目的清单(项目属性中的清单下拉列表为空且被禁用)。因此,我尝试添加它,但没有任何效果。

最后,我开始将此 project .csproj文件与该项目的另一个旧版本进行比较,该版本的编译没有问题。 经过一些无聊的尝试后,我发现,两个项目中通往Microsoft.Office.Interop.Word的路径都是相同的,甚至认为这是一个以许多“向上”符号(.. \ )。而且没有工作的项目比其他项目低一个级别。

在项目.csproj文件中的Microsoft.Office.Interop.Word的引用路径中再添加一个“向上”符号(.. \)解决了该问题。

我不知道为什么以这种方式创建此路径并且在我的情况下不会更新,而对于我团队中的其他人却正常工作。

答案 50 :(得分:1)

我同意以上所有内容只是有所不同。 就我而言:我正在使用Visual Studio2019。我关闭了VS-2019,并使用VS-2017打开。并重建项目,一切正常! 我在谁的职位上约会的日期是:2019/4/19

答案 51 :(得分:1)

  1. 右键单击解决方案,然后单击“清理”。
  2. 右键单击解决方案,然后单击“重建”。

答案 52 :(得分:1)

在我的情况下,我收到此错误消息的原因很简单,在从TFS获取项目的最新版本后,解决方案中的错误项目被标记为启动项目。选择正确的项目作为启动项目为我解决了这个问题。

答案 53 :(得分:1)

哇,好像这个错误可能来自无处不在。

无论如何,我在我的MVC应用程序中添加了一个新的WebAPI控制器,它自动获得了NuGet的所有引用。稍后我从NuGet UI中删除了引用,但我忘了使用它们删除文件(即System.Http)。

出于某种原因,我收到的错误是这个,以及关于未使用的变量的简单警告。

我注释掉变量以至少摆脱警告并重建指出我使用不存在的引用的所有文件。删除这些文件后,一切正常。

答案 54 :(得分:1)

这里介绍的大多数方法都无法解决我的问题。

最后,我通过执行以下步骤解决了该问题:

1。。关闭Visual Studio。

2。。删除每个项目的bin文件夹中的所有内容。

3。。打开解决方案并重新构建。

希望这会有所帮助。

答案 55 :(得分:1)

对我来说问题是我打开了两个Visual Studio窗口,我的项目在一个窗口中调试运行,我试图在另一个窗口中构建它。

我不得不停止调试,然后让我成功构建。

答案 56 :(得分:1)

由于元数据错误导致您可能无法看到代码中的语法错误,因此可能会发生此问题。因此,在执行先前答案中的任何操作之前,请检查您的源文件。

答案 57 :(得分:1)

我遇到了这个问题。在我的例子中,多个C#项目被引用为DLL文件。项目中用作DLL文件(在其他项目中)的任何编译时错误都会导致大量错误。原因是,编译时错误阻止了相应DLL文件的创建,这导致项目中的一系列错误引用丢失的DLL文件。

因此,当您在解决方案资源管理器中重建(忽略繁琐的编译时错误)时,会发生一堆“元数据文件.dll”无法找到错误(让您认为除了简单的重建之外您做了什么错误)。

如果您遇到此问题,那么最佳解决方案是清理解决方案,然后逐个构建每个项目,以确定哪个项目正在启动错误。

答案 58 :(得分:1)

当我从调用扩展方法中删除类型注释时,我在Visual Studio 2015中遇到了这个错误,该方法只留下空的尖括号。

所以我没有obj.extensionMethod<Type>()而是obj.extensionMethod<>()

我会将此归类为Visual Studio中的错误,因为我看不出错误会如何产生错误。

答案 59 :(得分:1)

在 Visual Studio 2019 中:

  • 关闭 Visual Studio。
  • 删除位于同一个目录中的 .vsccc 文件 文件夹作为您的解决方案文件。
  • 打开解决方案并重建。

答案 60 :(得分:0)

我遇到了同样的问题。首先,我从工具> Nuget 包管理器> 包管理器设置中清除了所有 nuget 缓存,然后单击“清除所有 Nuget 缓存”。在这之后打开 Powershell 并运行“dotnet restore”然后运行“dotnet build”。就我而言,此解决方案修复了我的错误。

答案 61 :(得分:0)

当前项目的框架版本与其余项目不同。 将框架版本更改为现有项目版本将解决此问题。

答案 62 :(得分:0)

就我而言,我删除了另一个项目的引用,但我从未在代码中使用它,因此我没有遇到任何编译错误。

提示:检查您的解决方案中是否有对不存在的其他项目的任何引用。

答案 63 :(得分:0)

尝试发布我的项目

时遇到此错误,

以上所有答案,对我没有帮助...

我只是更改了部署,发布成功了!

答案 64 :(得分:0)

在我的情况下,这是依赖项目(该项目取决于错误消息中的那个项目)在项目的“属性→应用程序→装配信息...”下的“装配版本”字段中缺少值。我只是添加了与“文件版本”相同的数字,单击“确定”,编译器错误消失了!

Missing Assembly Version

事实证明,重新添加AssemblyVersion然后再次构建项目导致另一个错误,声称它已经存在于项目中。它是!在解决方案资源管理器中项目的属性节点下,有一个“ SolutionVersionInfo.cs”文件,其中也包含一个AssemblyVersion属性-从项目中删除此文件可解决此错误。

答案 65 :(得分:0)

对我来说,发生此问题是因为我是内联变量。

因此以下内容可以成功构建:

ReportCategory reportCategoryEnum;
Enum.TryParse(reportCategory, true, out reportCategoryEnum);

当我按以下方式修改代码时,未显示任何错误,但构建失败

Enum.TryParse(reportCategory, true, out ReportCategory reportCategoryEnum);

答案 66 :(得分:0)

就我而言,我删除了git文件夹并删除了Git(Azure DevOps)。 这是我唯一可行的方法。

我尝试清理,重建,重新配置构建,删除bin和obj文件夹;没有任何效果。 当我删除Git解决方案时,瞧!它对我有用。

我听不懂,但这为我解决了。

答案 67 :(得分:0)

这在VS2019 .Net Core,ASP.Net Core解决方案中为我工作。

  1. 在解决方案的相同位置打开PowerShell控制台。
  2. 键入dotnet restore以还原所有程序包和项目
  3. 输入dotnet build。解决方案将构建

现在它也可以从Visual Studio IDE中构建。 给出的其他解决方案都不适合我

答案 68 :(得分:0)

我在一个.csproj文件中发生合并冲突,最终得到一个构建目标的两个副本。

<Compile Include="SystemCodes\APSystemCodes.cs" />

在我消除了重复项之后,构建工作正常了。

答案 69 :(得分:0)

对我来说,这是一个未使用的导入,在Controller上“使用ApsNetCore”。删除它,清理,重建它即可。

答案 70 :(得分:0)

对我来说,这是错误的文件夹名称。如果您关闭源代码并用'%20'代替空格,则会出现此类错误。 解决方案-只需重命名重命名的文件夹即可。

答案 71 :(得分:0)

区分大小写

就我而言,错误信息如下

<块引用>

严重性代码描述项目文件行抑制状态 错误命令 ""C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools\gacutil.exe" /i "C:\Users\cmaggiul\source\repos\consume -evalue-api\EValueApi\EValueApi\bin\debug\EValueApi.dll"" 以代码 3 退出。EValueApi

我沿着 EValueApi.dll 文件的路径,发现调试目录在 Windows 中是大写的。我将目录更改为小写(以匹配 gacutil.exe 使用的位置并解决了我的问题。

答案 72 :(得分:0)

可能会发生此问题,因为您正在使用为项目选择的 .net 版本不支持的功能。

在我的情况下,原因是我使用 ?? 运算符检查null并引发异常。

奇怪的是, VS 不能在构建错误列表中告知问题的实际原因。

但是您可以在构建的 Output 日志中找到此信息。

答案 73 :(得分:0)

导航到解决方案的文件夹资源管理器,并删除引发错误的未使用的项目文件夹。就我而言,删除项目后,该文件夹仍然存在于目录中。删除文件夹后解决方案成功构建!

答案 74 :(得分:0)

我用的是 VS 2019。我们组应该是从 2017 升级到 2019。

实际解决方案

我尝试克隆到 C: 驱动器上的一个文件夹,该文件夹是我的漫游配置文件的一部分(在网络上也是如此)。我创建了一个本地文件夹,保证不会被跟踪并克隆到那里。问题迎刃而解。

注意事项:

  • 这不可能是路径长度问题,因为我还尝试将其克隆到名称比原始路径长的文件夹中,并且构建得很好。
  • 这不可能是因为文件名中有空格,因为我们的解决方案文件夹中有空格。
  • 这个问题似乎只影响 VS2019 而不是 VS2017。尽管我们之前遇到过漫游配置文件问题,但它曾经在我们尝试与 Git 同步而不是构建时发生。

我尝试/检查过的其他事情无济于事

  • 重启VS、注销、重启等
  • 从 DevOps 存储库中删除解决方案并重新克隆
  • 我们的代码中没有构建错误
  • 取消选中并重新选中构建配置框
  • 构建顺序是有道理的
  • 所有 .NET Framework 目标都相同。 (就我而言,4.6。可能无关紧要。)
  • DLL 实际存在于路径中
  • 重新加载项目
  • 重新安装 NuGet 包
  • 重新添加 DLL

答案 75 :(得分:0)

这里没有其他任何东西对我有用,但这对我有用:

  1. 使用 Git 存储更改
  2. 清理和构建
  3. 应用存储
  4. 重建

现在,VS 突然向我指出了一个以前没有出现过的错误。此外,intellisense 忽略的那个文件中有几个错误。我在没有红色下划线的帮助下更正了那些,然后能够成功构建。

答案 76 :(得分:0)

Visual Studio IDE在幕后不做任何构建,而Msbuild应用程序则在做。 VS IDE本质上只是构造Msbuild使用的项目文件,而且如果您将其交给IDE自行解决,它经常会出错。如果收到<Reference Include="C:\\correct path to assembly\\yourAssembly.dll" />错误,则可能是由于未找到正确/预期的程序集。因此,当您引用4.0程序集时,Visual Studio可能正在为4.5框架应用程序创建项目文件,并期望有4,5个程序集。因此,请查看您的Visual Studio设置是否存在不兼容性,或者自己进入项目文件,然后通过指定正确的路径pd.concat手动对其进行修复。

答案 77 :(得分:0)

以前的解决方案都不适合我,所以我会分享一下。

在从另一个相互引用的分支合并一些新的类库后,我遇到了这个问题。删除项目中的引用并重新创建它们最终修复了问题。显然Visual Studio已合并错误的文件路径。

答案 78 :(得分:0)

很奇怪!我尝试了以前的所有答案,遗憾的是我的情况没有任何效果。

我遇到了两个错误:

  1. 缺少.dll文件
  2. 已在具有相同参数的其他地方定义的方法
  3. 我已经通过删除在其他地方重复的功能来清除第二个错误。

    我的第一个错误 - 缺少.dll文件已经解决了它。

    我想说,如果您有多个错误以及.dll丢失文件错误,请先尝试解决其他错误。也许.dll错误自己解决了!

答案 79 :(得分:0)

在经常更改解决方案后,我开始遇到这个问题,搁置更改并撤消它。

解决问题的唯一方法是删除并再次添加从TFS到我的本地文件夹的映射。

答案 80 :(得分:0)

我看到了这个错误,因为我的代码中有以下行(看起来我还在思考SQL模式):

if(myVar is null)
    DoSomething();

Visual Studio(2017)在设计或编译时没有报告任何错误,但是项目不会构建并且错过了#d;缺少.dll&#34;错误。将错误行更改为:

if(myVar == null)

问题已解决。

答案 81 :(得分:0)

到目前为止,几十个答案都没有为我工作。在我的情况下,我也得到了错误:

  

元组元素名称&#39;价值&#39;是推断。请使用语言版本7.1或更高版本通过其推断名称访问元素

这出现在&#34;元数据文件&#39; .dll&#39;旁边。无法找到&#34;建筑上的错误,但很快就消失了,因为错误有时会像IDE&#34;赶上&#34 ;.

双击错误以找到它,并删除有问题的代码,修复它。

否则,您可以在Visual Studio中尝试:

菜单项目→&lt;项目名称&gt; 属性构建→按钮高级语言版本 C#&lt;最新未成年人版本&GT; (例如&#34; C#5.0&#34;)

这也解决了这个问题。

它看起来像&#34;元数据文件&#39; .dll&#39;无法找到&#34;通常是其他一些潜在问题的症状,因此,如果没有一个顶级解决方案适合您,请检查其他错误和警告,并尝试找到真正的问题。

答案 82 :(得分:0)

就我而言,设置目标框架解决了问题:

  1. 右键单击该项目,然后选择属性

  2. 应用程序中,将目标框架更改为与主项目相同(例如“.NET Framework 4.5”)。

答案 83 :(得分:0)

在我的情况下,我还有一堆其他的构建错误(一些简单的类型转换)以及这个错误,我正试图解决这个问题,而我并没有专注于其他错误

最终解决了我的问题是我修复了所有其他构建错误,然后我再次构建并成功构建。

因此,如果您有其他构建错误以及丢失的DLL文件错误,并且其他任何内容都无效,请先尝试修复其他错误,然后重新构建解决方案。

答案 84 :(得分:0)

对我来说,问题是构建输出中没有出现的错误,即我有两个最初位于不同命名空间的实用程序类。我更改了第二个的名称空间以匹配第一个名称空间(不知道第一个中有另一个实用程序类),这就是这个错误开始出现的时候。

我想构建输出错误浮出水面,因为无法构建逻辑层库DLL文件,主应用程序找不到它。

解决方案是将第二个实用程序类更改回另一个命名空间,这就是当真正的构建错误开始涌入时。在对它们进行排序之后,构建就完成了。

概述,如果以前的任何解决方案对您不起作用,您可能会在Visual Studio未显示的代码中抑制错误,因此请尝试重新编写您的编码步骤并检查是否存在任何异常情况。

PS:这是在Visual Studio 2015社区版

答案 85 :(得分:0)

检查主项目的.csproj文件。如果您在解决方案中删除项目或更改引用,Visual Studio不会清除它。

我在.csproj文件中引用了三次旧项目,并且编译向已删除的项目显示了此错误。

答案 86 :(得分:0)

更新dll / nuget后出现此问题。

我可以通过更正.csproj文件来手动解决此问题。大多数情况下,文件中未更新版本。 例如:

<Analyzer> Include="..\packages\Microsoft.CodeAnalysis.**VersionCheckAnalyzer.2.9.1**\analyzers\dotnet\Microsoft.CodeAnalysis.VersionCheckAnalyzer.dll"/>

<Analyzer> Include="..\packages\Microsoft.CodeAnalysis.**VersionCheckAnalyzer.2.9.7**\analyzers\dotnet\Microsoft.CodeAnalysis.VersionCheckAnalyzer.dll"/>

答案 87 :(得分:0)

我有相同的问题和另一种解决方案。

问题: 一个解决方案,多个项目。使用其他一些结果的主应用程序失败,并显示:

CSC:错误CS0006:找不到元数据文件'C:\ Repos \ TheApplication \ TheApplicationCommon \ bin \ Debug \ TheApplication.dll'

但实际上,该项目产生了C:\Repos\TheApplication\TheApplicationCommon\bin\Debug\TheApplicationCommon.dll 另一个项目也使用完美编译的相同dll。

在我更新内部的NuGet软件包之前,该软件包使用了PostSharp 3.x.x.x,现在使用了PostSharp4.x.x.x。我的解决方案是将其添加到我的* .csproj文件中:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="...">
  <Import Project="..." Condition="..." />
  <PropertyGroup>
    ...
    <AssemblyName>TheApplication</AssemblyName>
    ...
    <SkipPostSharp>True</SkipPostSharp> <!-- This line -->
  </PropertyGroup>
...

另一个解决方案->清理,另一个解决方案->重建,它可以在本地和构建服务器上运行。

希望它可以帮助某人。该线程很旧,很长,但是这个问题经常出现,我还没有看到这个解决方案。顺便说一句,使用Visual Studio 2017(15.8.x)。

答案 88 :(得分:0)

在我的Web.config文件中,对此进行了更改

<?xml version="1.0" encoding="utf-8"?>

对此

<?xml version="1.0"?>

解决了我的问题

答案 89 :(得分:0)

当我进行构建时,通常会在Visual Studio 2017中显示如下错误:

Error   CS0006  Metadata file 'C:\src\ProjectDir\MyApp\bin\x64\Debug\Inspection.exe' could not be found MyApp   C:\src\ProjectDir\MyApp\CSC 1   Active

但是有时候这样的错误会显示几秒钟,然后消失并切换回上面的消息:

Error   CS1503  Argument 1: cannot convert from 'MyApp.Model.Entities.Asset' to 'MyApp.Model.Model.Entities.Inspection' MyApp   C:\src\ProjectDir\MyApp\ViewModels\AssetDetailsViewModel.cs 1453    Active

因此,我花时间对第一个错误进行了故障排除,但真正的问题却是由第二个错误引起的。首先,我必须删除所有/ bin和/ obj目录,然后如上所述也删除.suo文件。这使我可以将问题缩小为界面问题。

在我的界面中,我有这个:

    Task<IList<Defect>> LoadDefects(Asset asset);

但是在我的实际实现中,我有以下代码:

    public virtual async Task<IList<Defect>> LoadDefects(Inspection inspection)
    {
       var results ...
       // ....

        return results;
    }

我将界面更新为以下内容后,构建成功完成:

    Task<IList<Defect>> LoadDefects(Inspection inspection);

因此,当实际问题是CS1503错误时,似乎在VS中进行缓存导致其继续显示CS0006错误。

答案 90 :(得分:0)

就我而言,我注意到已将.Net Framework 4.7项目引用为对.Net Framework 4.6.1项目的依赖关系,从而解决了此问题。将项目4.7迁移到4.6.1之后,我的应用程序正常编译了

答案 91 :(得分:0)

在我的情况下,当我在本地引用NuGet软件包并将其目录移动到其他地方时发生了这种情况,我更改了NuGet.Config内的路径,但是不幸的是,我发现我应该更改.csproject文件手动更新参考路径,但是错误消息CS0006距描述此问题还很远。 通常,当找不到对DLL的引用时,也会发生这种情况,以便能够找出问题,在项目中搜索您的引用并发现问题,您将找到一些带有警告图标的引用,并尝试对其进行修复。应该能按预期工作。

答案 92 :(得分:0)

许多这样的答案听起来像是反复试验。但就我而言,这很简单:在该特定位置找不到引用的dll。

如果您通常在这种情况下看到生成错误,则该生成会抱怨许多dll。关键是找到丢失的正确的dll。就我而言,解决方案中的一个项目具有直接dll引用而不是项目引用。因此,在构建失败的解决方案之前,我需要构建一个输出该dll的项目,以确保失败的解决方案在该特定位置找到丢失的dll。

哇..很简单,但是很难用语言表达出来。

答案 93 :(得分:0)

我在getting latest(Team Foundation Server(TFS)命令)之后遇到了这个问题。

解决冲突后,我发现使用namespace that does not exist in the project的声明。

所以我删除了using语句,然后clean and rebuild,一切正常。

答案 94 :(得分:0)

删除bin / obj文件夹,然后重建项目对我来说很有效。

就我而言,我相信发生的事情是我第一次构建项目时遇到了运行时错误,因此没有生成我的dll文件。

在引用另一个项目时发生这种情况。我所引用的项目就是那个有问题的项目。

答案 95 :(得分:0)

就我而言,解决方案的父文件夹名称中有一个%20。我通过删除%20重命名了父文件夹,此问题已解决。

答案 96 :(得分:0)

我遇到了这个问题。就我而言,我从所有项目中删除所有bin和obj文件夹,然后此错误将为我解决。再尝试一次以解决问题

答案 97 :(得分:-1)

使用Visual Studio 2019时遇到相同的错误。 仔细查看后台发生的情况后,我发现附加类库存在错误,这些错误又无法正确编译,并且同时出现错误“找不到元数据文件”。更正错误,再次编译,一切正常。

对于我来说,答案是在“输出”标签的分析中找到的。

答案 98 :(得分:-1)

我的项目遇到了同样的问题,我在解决方案中添加了控制台应用程序,但其他解决方案不起作用并且显示未找到 .dll,所以我尝试了这种方法:

  1. 右键单击有问题的项目
  2. 点击应用标签,这是默认的
  3. 将输出类型控制台应用程序更改为类库