【问题标题】:The type is defined in an assembly that is not referenced, how to find the cause?类型定义在未引用的程序集中,如何查找原因?
【发布时间】:2014-01-06 19:11:43
【问题描述】:

我知道错误消息很常见,关于这个错误有很多关于 SO 的问题,但到目前为止没有解决方案对我有帮助,所以我决定提出这个问题。与大多数类似问题的不同之处在于我使用 App_Code 目录。

错误信息:

CS0012: The type 'Project.Rights.OperationsProvider' is defined in an
assembly that is not referenced. You must add a reference to assembly
'Project.Rights, version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.

源文件:

c:\inetpub\wwwroot\Test\Website\App_Code\Company\Project\BusinessLogic\Manager.cs

根据herehere 的建议,我已删除 C:\Windows\Microsoft.NET/*.* 中的所有 Project.Rights.dll 实例 根据this,我检查了有问题的 .cs 文件是否将构建操作设置为“编译”。他们是这样。 我还仔细检查了包含“Project.Rights.OperationsProvider”类型的 .cs 文件是否已部署到 App_Code 目录。

由于某种原因,应用程序没有在 App_Code 目录中寻找类型。由于我已经删除了 Project.Rights.dll 的所有实例(我知道),我不知道错误消息提到的是哪个程序集。

【问题讨论】:

  • 你正在使用一个类(比如说 A),它公开了 Project.Rights.OperationsProvider 类型的方法/属性/东西。编译器需要知道那是什么,然后它将搜索该程序集(Project.Rights)。如果没有找到它(因为您的网站项目中没有对它的引用)...您会收到此错误。 解决方案: 不要从系统中删除该程序集!!!添加对它的引用。
  • 尝试转到工具 - 选项 - 项目和解决方案 - 构建和运行 - 将两个详细信息设置为详细。这会告诉你依赖是什么,以及编译器在哪里寻找它。

标签: c# asp.net .net asp.net-4.0


【解决方案1】:

当您收到此错误时,这意味着您正在使用的代码引用了程序集中的类型,但程序集不是您项目的一部分,因此无法使用它。

删除 Project.Rights.dll 与您想要的相反。您需要确保您的项目可以引用程序集。所以它必须要么放在全局程序集缓存中,要么放在你的 Web 应用程序的 ~/Bin 目录中。

编辑-如果您不想使用程序集,那么删除它也不是正确的解决方案。相反,您必须删除代码中对它的所有引用。由于您编写的代码并不直接需要该程序集,而是您引用的其他内容需要该程序集,因此您必须将引用的程序集替换为没有 Project.Rights.dll 作为依赖项的内容。

【讨论】:

  • 我不能使用该程序集,这是一个要求。我需要摆脱它并将类存储在 App_Code 目录中。我知道它听起来如何,相信我。被要求更改应用程序以便所有业务逻辑都存储在 App_Code 中而不是 DLL 中......这并不好玩。
  • 不,这意味着他正在使用引用它的东西(而不是他直接使用)。 @afaf12 如果你必须摆脱它......你必须检查 正在使用它(想象这作为一个 indirect 参考)。您不能简单地将代码粘贴到 App_Code 目录中,任何已编译的程序集仍将引用原始(和外部)程序集...
  • 我也有类似的情况,您的帖子帮助很大。就我而言,我引用了一个程序集“A”。该程序集正在使用另一个程序集“B”。尽管我将它添加到我的项目中,但我一直收到一个错误,即缺少程序集“B”。一旦我将程序集“B”复制到我的 bin 目录,问题就解决了。原因是我的项目没有使用程序集“B”,而是使用了程序集“A”,但它没有找到它,因此引发了异常。谢谢。
【解决方案2】:

我的问题是我的一个项目的输出类型设置为控制台应用程序。为了解决这个问题,我右键单击项目,选择属性,单击应用程序选项卡,然后将输出类型(从控制台应用程序)更改为类库。我重新编译后,这个错误就消失了。

【讨论】:

    【解决方案3】:

    我在使用现有项目的新创建解决方案上遇到了这个问题。出于某种原因,一个项目无法“看到”另一个项目,即使它与其他所有项目具有相同的引用,并且被引用的项目也在构建中。我怀疑它未能检测到与多个目标框架有关的东西,因为它是在一个框架中构建的,而不是在另一个框架中构建的。

    清理重建没用,重启VS也没用。

    最终的工作是打开“VS 2019 的开发人员命令提示符”,然后发出 msbuild MySolution.sln 命令。这成功完成了,之后VS也开始构建成功。

    【讨论】:

      【解决方案4】:

      当我尝试从 .NET 程序集选项卡添加引用时,它对我不起作用。 但是,当我使用 BROWSE 将引用添加到 C:\Windows\Microsoft.NET\Framework\v4.0.30319

      时,它起作用了

      【讨论】:

        【解决方案5】:

        我有类似的问题,我删除了 RuntimeFrameworkVersion,问题就解决了。

        尝试删除 1.1.1 或

        【讨论】:

          【解决方案6】:

          对我来说,这是由项目直接和间接(通过另一个依赖项)引用了具有不同程序集名称的两个不同版本的 Bouncy Castle 引起的。 Bouncy Castle 版本之一是 NuGet 包,另一个是从 GitHub 下载的源代码的调试版本。两者名义上都是 1.8.1 版本,但 GitHub 代码的项目设置将程序集名称设置为 BouncyCastle,而 NuGet 包的程序集名称为 BouncyCastle.Crypto。更改项目设置,从而对齐程序集名称,解决了问题。

          【讨论】:

          • 我建议您也可以通过解释您如何修复它来使您的答案更有帮助。
          【解决方案7】:

          在我的例子中,引用的 dll 版本实际上比我之前的版本更新。

          我只需要回滚到以前的版本并修复它。

          【讨论】:

            【解决方案8】:

            在我的例子中,我引用了一个构建到错误平台/配置的库(我刚刚创建了引用的库)。

            此外,我无法在 Visual Studio 配置管理器中解决问题 - 无法切换并为此库创建新的平台和配置。我通过更正该项目的.sln 文件的ProjectConfigurationPlatforms 部分中的条目来修复它。它的所有排列都设置为Debug|Any CPU(我不确定我是怎么做到的)。我用工作项目的条目覆盖了损坏项目的条目,并更改了每个条目的 GUID。

            运作项目的条目

            {9E93345C-7A51-4E9A-ACB0-DAAB8F1A1267}.Release|x64.ActiveCfg = Release|x64 {9E93345C-7A51-4E9A-ACB0-DAAB8F1A1267}.Release|x64.Build.0 = Release|x64

            已损坏项目的条目

            {94562215-903C-47F3-BF64-8B90EF43FD27}.Release|x64.ActiveCfg = Debug|Any CPU {94562215-903C-47F3-BF64-8B90EF43FD27}.Release|x64.Build.0 = Debug|Any CPU

            现已修复损坏的条目

            {94562215-903C-47F3-BF64-8B90EF43FD27}.Release|x64.ActiveCfg = Release|x64 {94562215-903C-47F3-BF64-8B90EF43FD27}.Release|x64.Build.0 = Release|x64

            我希望这对某人有所帮助。

            【讨论】:

            • 对我来说是相似的。 VIsual Studio 已将我的一些项目的 GUID 从 FAE04EC0-301F-11D3-BF4B-00C04F79EFBC (C#) 更改为 9A19103F-16F7-4668-BE54-9A1E7A4F7556 (ASP.NET)。在我把它们换回来后,一切都很顺利。
            【解决方案9】:

            就我而言,这是因为我使用了

            隐式运算符

            BLLDAL 类之间。当我想在应用层中使用BLL 层时,我得到了这个错误。 我变了

            隐式运算符

            显式运算符

            没关系。 谢谢

            【讨论】:

              【解决方案10】:

              类型“Domain.tblUser”是在一个不是 参考。您必须添加对程序集“域”的引用, 版本=1.0.0.0,文化=中性,PublicKeyToken=null'。

              **Solved:**
               Add reference of my domain library layer to my web app libary layer
              

              注意:根据你的 DI 容器,确保你的引用是正确的

              【讨论】:

                【解决方案11】:

                清理您的解决方案并重新构建对我有用(在 Visual Studio 中,这些是您在解决方案资源管理器中右键单击时获得的选项),错误在我的项目中消失了。

                【讨论】:

                  【解决方案12】:

                  检查项目中的目标框架。

                  在我的情况下,“您必须添加对程序集的引用”实际上意味着调用者和引用项目没有相同的目标框架。调用者项目具有 .Net 4.5 ,但引用的库具有目标 4.6.1。

                  我确信,MS 编译器可以更智能并记录更有意义的错误消息。我给https://github.com/dotnet/roslyn/issues/14756添加了一个建议

                  【讨论】:

                  【解决方案13】:

                  对我来说,出现错误的原因是报告错误的 WebForm 已从另一个文件夹中移出,但其 codefile 类的名称保持不变,与实际路径不对应。

                  初始状态:
                  原始文件路径: /Folder1/Subfolder1/MyWebForm.aspx.cs
                  原始代码文件类名: em> Folder1_Subfolder1_MyWebForm

                  文件移动后:
                  文件路径: /Folder1/MyWebForm.aspx.cs
                  代码文件类名(不变,带显示的错误): Folder1_Subfolder1_MyWebForm

                  解决方案:
                  重命名你的代码文件类Folder1_Subfolder1_MyWebForm
                  改为一个对应 新路径Folder1_MyWebForm

                  一下子解决问题,没有错误报告..

                  【讨论】:

                    【解决方案14】:

                    我只是碰巧不同的项目引用了同一个 dll 的不同副本。 我确保所有文件都引用了磁盘上的同一个文件,并且错误如我预期的那样消失了。

                    【讨论】:

                      【解决方案15】:

                      这也可能意味着您使用了一个库,该库公开了在库中定义的(公共)类型。 即使你没有在你的库中专门使用这些(没有构建的那个)。

                      这可能会阻止您编写使用您无法使用的类(在其签名中具有未引用的库中的类型)的代码。

                      【讨论】:

                        【解决方案16】:

                        在我的情况下,这是因为执行 NuGet 包更新仅更新了对 一些 中的 dll 依赖项的引用,但 不是所有 我的解决方案中的项目 - 导致版本冲突.使用a grep-style tool 在我的解决方案中搜索 *.csproj 文件中的文本,然后很容易看到仍需要更新的项目。

                        【讨论】:

                        • 感谢您的回答 - 我认为它与此类似,但很高兴看到它。换句话说 - 我的父项目(服务)在我的数据层中调用带有可选参数的构造函数并没有将该引用添加到 .csproj。比较子 .csproj 文件和父 .csproj 文件应该阐明一个 ItemGroup 应该在不是的父级中。
                        • 解决方案的 Visual Studio 包管理器窗口(不适用于单个项目)具有 Consolidate 选项卡,该选项卡显示哪些包在不同项目中具有不同的版本。可证明它比类似 grep 的工具更好
                        【解决方案17】:

                        您正在使用的库(DLL 文件)可能需要另一个库。在我的例子中,我引用了一个包含数据库实体模型的库 - 但我忘记引用实体框架库。

                        【讨论】:

                          【解决方案18】:

                          主要原因之一可能是 DLL 的属性 您必须在做任何事情之前检查 specific version property 是否为真,使其为假

                          原因: 也许源代码在你构建它时加入了其他(旧)版本,但是这个库升级了新的更新版本现在在 Assembly Cash 和你的应用程序禁止获取新的 DLL,并且在禁用 specific version property你的applacaten将免费获得新版本的DLL引用

                          【讨论】:

                            【解决方案19】:

                            当您收到此错误时,发生的情况并不总是很明显,但正如错误所说 - 您缺少参考。以下面这行代码为例:

                            MyObjectType a = new MyObjectType("parameter");
                            

                            它看起来很简单,您可能已经正确引用了“MyObjectType”。但是,可以说“MyObjectType”构造函数的重载之一采用您没有引用的类型。例如有一个重载定义为:

                            public MyObjectType(TypeFromOtherAssembly parameter) {
                                // ... normal constructor code ...
                            }
                            

                            这至少是您会收到此错误的一种情况。因此,请查找这种类型的模式,其中您引用了类型,但不是所有类型的属性或方法参数,这些类型可能用于在该类型上调用的函数。

                            希望这至少能让你朝着正确的方向前进!

                            【讨论】:

                            • 关于扩展方法的注意事项:如果两个类有同名的扩展方法,则一种类型的参数可以“感染”另一种类型的扩展方法的使用。
                            • @Athari 谢谢你,我永远也想不通
                            • 经过一段时间的查找,偶然发现了这个答案。这正是我的问题,您的解释非常有帮助。感谢负载。
                            • 但是如果我不想将构造函数与引用一起使用怎么办?我想使用其他的,而不添加参考。看来这应该是可能的。
                            • 这看起来很奇怪,但我收到了这个错误,因为我在其中一个程序集名称的情况下不匹配(看起来 nuget 区分大小写?)!我有一个库 C 引用库 B 和 A。库 B 也引用了库 A,但使用名称 'a' 而不是 'A' 将 A 打包为依赖项。构建库 C,我一直收到此错误,直到我更正 B 中的依赖项名称!
                            猜你喜欢
                            • 2011-08-16
                            • 2014-08-15
                            • 2016-05-01
                            • 2018-01-10
                            • 1970-01-01
                            • 1970-01-01
                            • 2023-03-28
                            • 2018-12-26
                            • 1970-01-01
                            相关资源
                            最近更新 更多