C#项目，编译器抱怨缺少对log4net的引用

本文介绍了C#项目，编译器抱怨缺少对log4net的引用的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

我正在使用Visual Studio 2017构建一个大型C#项目(解决方案中有200多个项目).编译其中一个项目时，出现很多错误，如下所示:

I am using Visual Studio 2017 to build a big C# project (200+ projects in the solution). When compiling one of the projects, I got many errors as shown below:

error CS0012: The type 'BufferingAppenderSkeleton' is defined in an assembly that is not referenced. You must add a reference to assembly 'log4net, Version=1.2.11.0, Culture=neutral, PublicKeyToken=1b44e1d426115821'.

但是，所讨论的项目确实引用了log4net 1.2.11.唯一可疑的是在log4net的软件包路径中找到的 net40-full :" C:\ XXXX \ Src \ packages \ log4net.1.2.11 \ lib \ net40-full \ log4net .dll "

The project in question, however, does reference to log4net 1.2.11. The only thing suspicious is the net40-full found in the package path of log4net: "C:\XXXX\Src\packages\log4net.1.2.11\lib\net40-full\log4net.dll"

在项目的package.config中，它包含以下行:

in the package.config of the project, it contains this line:

<package id="log4net" version="1.2.11" targetFramework="net461" />

并在其app.config中包含以下行:

and in its app.config, it contains this line:

<dependentAssembly> <assemblyIdentity name="log4net" publicKeyToken="1b44e1d426115821" culture="neutral"/> <bindingRedirect oldVersion="0.0.0.0-1.2.11.0" newVersion="1.2.11.0"/> </dependentAssembly>

我想知道是否是导致编译错误的版本(4.0与4.61)不匹配?

I wonder if it's the mismatch of the version (4.0 vs. 4.61) that causes the compiling error?

C#不是我的主要专长，但我的理解是nuget会查看这些配置文件以下载所需的软件包，在这种情况下为log4net.那么，它是怎么下载了4.0版本而不是4.6.1版本的?

C# is not my primary area of expertise, but my understanding is that nuget looks into those config files to download needed packages, in this case, log4net. Then how come did it download the 4.0 version rather than that of 4.6.1?

推荐答案

我的理解是nuget查看这些配置文件以下载所需的软件包，在这种情况下为log4net.

my understanding is that nuget looks into those config files to download needed packages, in this case, log4net.

NuGet的工作仅仅是下载软件包并提取其中的所有内容，至少在package.config项目的还原方案中. packages.config文件中的targetFramework属性仅被写入，而 nuget客户端.我不知道它的目的是什么.无论如何，我相信targetFramework的值只是安装该软件包时您的项目正在使用的.NET Framework.

NuGet's job is just to download packages and extract whatever's in them, at least in the restore scenario of a package.config project. The targetFramework attribute in the packages.config file is only written, never read by the nuget client. I have no idea what it's purpose or intention was. Anyway, I believe the value of targetFramework is just the .NET Framework your project was using when the package was installed.

那它怎么下载了4.0版本而不是4.6.1版本呢?

Then how come did it download the 4.0 version rather than that of 4.6.1?

背景信息，如果您真的不在乎，请跳至下一段.如果转到nuget上的软件包页面，您会在版本历史记录中看到未显示1.2.11.但是，如果您查看其他版本的URL，则可以猜到 1.2版的URL .11 .快速的脱口而出的评论，Fabio M很接近，但是说这个软件包已经不存在了，这不是很正确. " nuget不支持永久删除软件包.这样做会破坏每个项目都取决于软件包的可用性，尤其是涉及涉及软件包还原的构建工作流.".在程序包版本页面上，显示一条消息:所有者已取消列出该程序包.这可能意味着该程序包已被弃用或不再使用."​​

Background information, skip to the next paragraph if you really don't care. If you go to the package page on nuget, you'll see in the version history that 1.2.11 isn't shown. However, if you look at the URLs for other versions, you can guess the URL for version 1.2.11. Quick off-topic comment, Fabio M was close, but not quite correct in saying the package doesn't exist any more. "nuget does not support permanent deletion of packages. Doing so would break every project depending on the availability of the package, especially with build workflows that involve package restore.". On the package version page, there's a message saying "The owner has unlisted this package. This could mean that the package is deprecated or shouldn't be used anymore".

回到我的观点，一旦您到达此URL，请将nuget中的n更改为f以查看 fuget上的软件包版本.在框架旁边，您可以看到软件包支持的框架列表. net40是该软件包支持的最高版本.

Back to my point, once you're at this URL, change the n to an f in nuget to see the package version on fuget. Next to frameworks you can see a list of frameworks the package supports. net40 is the highest version that the package supports.

因此，NuGet之所以下载4.0版本"，是因为那是nuget软件包提供的与您的项目兼容的最接近的版本. .NET通常被认为是向前兼容的，因此net45二进制文件可以在net462运行时上运行，因此，当您的项目使用较新版本时，通常可以使用net45二进制文件.

So, the reason why NuGet "downloaded the 4.0 version" is because that's the closest version that the nuget package provides that is compatible with your project. .NET is generally considered to be forward compatible, so net45 binaries work on the net462 runtime, so it's generally ok to use net45 binaries when your project is using a newer version.

最后，关于您遇到的错误，正如我在第一段中所说的，在packages.config项目中，nuget的工作只是下载并解压缩该软件包.在安装时，它将向csproj添加一些信息，以便编译器可以尝试查找dll.因此，如果您查看csproj，则应该找到对log4net.dll的引用，它将包含编译器使用的提示路径.如果该提示路径错误，那么您将看到错误.这是在目录结构中移动项目但不重新安装软件包时最常见的情况.例如，如果回购结构最初是"project \ project.csproj"，并且已更改为"src \ project \ project.csproj"，则提示路径为".. \ packages \ log4net.1.2.11 \ lib \ net45 \ "log4net.dll"是错​​误的，因为需要添加一个附加的".. \"，以便packages文件夹的相对路径正确.提示路径错误可能还有其他原因，但这是最常见的原因.

Finally, about the error you're getting, as I said in my first paragraph, in packages.config projects, nuget's job is just to download and extract the package. At install time it adds some information to the csproj so the compiler can try to find the dll. So, if you look at your csproj, you should find a reference to log4net.dll, and it will contain a hint path that the compiler uses. If that hint path is wrong, then you'll get the errors you see. This is most common when projects are moved in the directory structure, but don't re-install the package. For example if the repo structure was origignally "project\project.csproj" and it's changed to "src\project\project.csproj", then the hint path of "..\packages\log4net.1.2.11\lib\net45\log4net.dll" is wrong, because an additional "..\" needs to be added so the relative path to the packages folder is correct. There may be other reasons the hint path is wrong, but this is the most common reason.