Visual Studio 2017 未能在 .NET 4.7 项目中安装 nuget 包答案

【问题标题】：Visual Studio 2017 failing to install nuget package in .NET 4.7 projectVisual Studio 2017 未能在 .NET 4.7 项目中安装 nuget 包
【发布时间】：2017-08-31 02:20:43
【问题描述】：

尝试将 nuget 包安装到标准 .NET Framework 4.7 项目中时出现以下错误：

指定的路径、文件名或两者都太长。完全限定的文件名必须少于 260 个字符，目录名必须少于 248 个字符。

我正在使用 Visual Studio 2017 15.3.3 Enterprise（最新最好的）。

鉴于这是我的包，我可以完全控制源代码。有趣的是，我过去使用过这个包，名称没有变化，但为了这个循环，我重新构建了它以添加一个功能，现在出现了这个错误。

更有趣的是我有来自同一个库的包，具有相同的命名空间约定，具有 longer 名称，它们工作得很好，并且安装到同一个项目中完全没有问题。

我已经尝试过缩小包名，缩小包本身的类名，清理构建目录，清理来自 nuget 服务器的包主目录（它是安装了最新 nuget.server 的本地服务器，否则工作正常），甚至清除相关项目的 bin 目录，清除所有祖先的所有 bin 目录到“违规”包，清除包缓存，重新启动计算机并重建整个 nuget 包从头开始连锁，一切都无济于事。一位 MS MVP 告诉我“他们解决了这个问题”。显然没有。

如果有任何帮助，我将不胜感激，我已经无计可施，没有想法可以尝试。

谢谢。

【问题讨论】：

项目存储在您计算机的哪个位置？我发现最好将它们放在 C 驱动器的根目录中，否则我也会遇到此类问题。
它在默认位置：c:\user\documents\visual studio 2017\projects\ 等。我同意你关于名称的长度，但是，正如我之前所说，我有一些名称比这个更长的包，它们存在于相同的树结构中（相同的深度，更长的名称），它们工作得很好，我真的不想仅仅因为一个包的异常行为，就将 25 万行代码的大部分移动到新位置。
移动文件夹是一个简单的文件操作，不用复制。（如果您从命令行执行，可能会更快）。这是最常见的原因，您可能会受到 VS 中某些目标更改的影响，这些更改会导致 obj 中的文件具有更长的名称。目前有些人对项目文件的名称有疑问。
@Martin - 很抱歉没有澄清 - 这种结构也反映在 TFS 中，我的团队必须做出同样的改变 - 这会影响大量代码，搞砸 TFS（它非常讨厌我- 我知道，一个软件怎么能“讨厌” - 但它确实如此！）。简而言之，“移动文件夹”选项不是一个选项。但是感谢您的回复...
消息究竟来自哪里？它应该与文件或 msbuild 目标相关联

标签： nuget visual-studio-2017

【解决方案1】：

好的，非常感谢@danmosemsft，他建议使用 SysInternals 进程监视器进行挖掘。在摆弄了一下之后，我终于想出了如何将结果集缩小到文件活动。我注意到了，nuget 工程师应该注意这一点：问题不是项目名称太长，而是 nuget 试图更新不再存在的包。它为什么消失是一个尚未解开的谜团。我通常不使用 packages 目录，也不会对 packages.config 文件大惊小怪。我认为这可能与我急于等待 VS 启动、加载所有好东西然后允许我执行“管理 NuGet 包”- 全部更新有关。我记得看到 NUnit 或 FluentAssertions 的更新想要执行一些额外的文件活动，而不仅仅是安装下一个版本，我相信这是一个脚本。不能有把握地谈论它，因为第三方更新通常“正常工作”，所以我并没有那么关注。我没有看到 NuGet 的“完成”行，所以我认为这是我问题的根源。我没有等到 VS 安定下来，而是稍微推了一下（嘿，按钮响应了，所以 不应该有任何问题......）。

因此，packages 目录完全塞满了不属于那里的旧东西。因此，我手动清理了所有杂物，手动清理了 packages.config 文件，重新启动了 VS，等待它安定下来，执行了我的 NuGet 更新和中提琴！没问题 - 即使是单个字符也没有更改任何祖先包名称。

那么，我从中得出什么结论？我的信念是，实际构建 nuget 和 nuget.server 的人应该仔细查看引发的错误，以便我认为错误与其说是路径太长的错误，而是“嘿，我没有找到我期望的文件，所以文件名充满了垃圾（现在可能太长了），所以我会抛出一个错误，说它太长并退出”。似乎无法处理导致此特定问题的丢失包/包目录

我通过确保所有包目录都清除所有垃圾并从干净的源重新构建来解决了我的问题。我的问题现在解决了。

感谢所有回复的人。

更新：虽然上述内容有助于解决方案，但它不是答案。以下是导致此问题的一系列事件及其最终解决方案。解决方案是在 C:\User\Sam\Documents\Visual Studio 2017\Projects 目录中创建的，指定名称为 AWE.Lib.ADO.MsSqlSvr.ServerEntityHandler。这工作得很好，没有错误。但是，由于从高位更改命名方案，该项目的根目录从“C:\User\Sam\Documents\Visual Studio 2017\Projects”更改为“C:\User\Sam\Documents\Visual Studio 2017\Projects\DotNet_4.7\AWE 8.x”。没问题，我想 - 鉴于一位同时也是 MS MVP 的同事告诉我，所有命名长度限制已在 VS 2017 中删除。所以......我将项目从当前的主页移到了目录指定的。编译得很好，引入更新但已经安装的 nuget 包就好了，等等。

或者我是这么认为的。当我需要添加一个新的（以前不是解决方案的一部分）nuget 包时，我收到了上述错误。事实证明，接收解决方案的新名称比 VS 接受的长几个字符 - 命名长度限制仍然存在。

我是如何最终解决这个问题的：在与此作斗争之后，我举起双手，决定重新开始——一个真正的文件 |新的。因此，我从一个名为如下的新解决方案开始： “C:\Users\Sam\Documents\Visual Studio 2017\Projects\DotNet_4.7\AWE 8.x\AWE.Lib.ADO.MsSqlSvr.HndlrServerEntity” 这会产生错误 - 名称太长。我想知道 Nuget 的错误，因为它指定名称的长度应小于 248 个字符或最多 260 个字符。

我被允许使用的新解决方案对话框是这样的：“C:\Users\Sam\Documents\Visual Studio 2017\Projects\DotNet_4.7\AWE 8.x\AWE.Lib.ADO.MsSqlSvr. HndlrServerEnt”，总共 106 个字符。如果目录被缩短，我可以添加名称的长度。如果我缩短实际解决方案名称的长度，VS 会再次接受它。只要目录加上解决方案名称的总长度小于或等于 106 个字符，就没有问题。

令人讨厌的一点来自于在一个位置创建解决方案并让它在所有方面都正常工作，将所述解决方案移动到不同的目录，仍然让它在所有方面都起作用（我不需要添加任何新的 nuget 包然而），然后尝试在移动后将新的 nuget 包添加到组合中。这就是触发上述 nuget 错误的原因。

所以...最终的“修复”，使用更短的名称，因为似乎 106 个字符是限制，尽管错误消息在说什么（以及 MS MVP 被告知/告诉我的内容）。

【讨论】：

感谢您在这里分享您的解决方案，您可以将其标记为答案，这样可以帮助遇到相同问题的其他社区成员。
Microsoft.CodeDom.Providers.DotNetCompilerPlatform.2.0.0 是一个很长的名字。然后它有子文件夹和更多子文件夹。

【解决方案2】：

编译器出现此错误消息还有另一个原因。在构建时，请确保将源代码放置在长度小于 260 个字符的文件夹位置。例如，C:\Users\User\source\Services\Exp\Sample-web-application-indot-net-displaying-RestAPI\Sample-web-application-indot-net-displaying-RestAPI\SportsStore 之类的路径大约有 150 个字符长，但解决方案中有子文件夹，这些子文件夹又包含源代码文件等。有时某些文件的路径总长度会超过 260 个字符的长度。

我认为 Visual Studio 的未来版本会有更大的长度限制。在那之前，我们可以确保我们的文件名不会太长。

【讨论】：

是的，根据我的一位 MS MVP 朋友的说法，这个问题（路径长度为 260）已经解决了。当我向他展示事实并非如此时，他非常惊讶——问题仍然存在于某些地方。
要在不将整个源代码移动到硬盘上的另一个文件夹的情况下解决此问题，您只需将驱动器映射到该文件夹（如果合适的话，甚至可以是包含所有存储库的父文件夹），并且然后直接从资源管理器中打开VS中的解决方案文件（它不能通过VS本身打开）。要将驱动器映射到本地文件夹，请按照 here 使用 net use x: \\localhost\c$\Folder\Example。

【解决方案3】：

在将项目移动到另一个文件夹后，我遇到了同样的问题。在我的情况下，我关闭了 VS 将根目录中的 .vs 文件夹重命名为 1.vs （有效地删除了它）并重新打开了我的项目。

【讨论】：

【解决方案4】：

在我的例子中，我首先尝试使用 Manage Nuget Packages for Solutions 安装一个包，但遇到了这个错误。然后我尝试使用 Package Manager Console 安装相同的包，它工作正常。我再次卸载了该软件包并尝试使用 Manage Nuget Packages for Solutions 进行安装，这次它也运行良好。

【讨论】：

【解决方案5】：

根据我的经验，我所要做的就是将整个项目移动到我的 c: 驱动器，删除不必要的文件夹以确保路径更短。完成交易。

【讨论】：

您错过了“但是由于从高位更改命名方案，该项目的根目录从...更改”的部分。我无法选择源代码的存储位置，这种变化来自食物链的上层。
我的解决方案只是一种直接处理错误的简单方法，解释简单明了，但是，我确实错过了用户无法选择存储源代码的部分，事实上，这让我感到困惑，为什么会这样......？？
要在不将整个源代码移动到硬盘上的另一个文件夹的情况下解决此问题，您只需将驱动器映射到该文件夹（如果合适的话，甚至可以是包含所有存储库的父文件夹），并且然后直接从资源管理器中打开VS中的解决方案文件（它不能通过VS本身打开）。要将驱动器映射到本地文件夹，请按照 here 使用 net use x: \\localhost\c$\Folder\Example。

【解决方案6】：

当我尝试将项目文件夹复制到 OneDrive 时出现此错误，问题是 OneDrive 没有上传长名称文件。

我已经解决了这个问题，方法是复制项目文件夹，然后使用 USB 将其粘贴到新笔记本电脑中。

希望能帮到你

【讨论】：

【解决方案7】：

将项目的文件夹移动到距根目录几级的文件夹中。例如桌面和瞧。

【讨论】：

要在不将整个源代码移动到硬盘上的另一个文件夹的情况下解决此问题，您只需将驱动器映射到该文件夹（如果合适的话，甚至可以是包含所有存储库的父文件夹），并且然后直接从资源管理器中打开VS中的解决方案文件（它不能通过VS本身打开）。要将驱动器映射到本地文件夹，请按照 here 使用 net use x: \\localhost\c$\Folder\Example。

【解决方案8】：

尝试关闭来自File->Close Solution 的解决方案并再次打开它。

在我卸载、安装甚至更新 NuGet 包的情况下，除了重新打开（有时您也可以关闭并再次打开 Visual Studio）之外，没有任何效果。解决方案发挥了作用。

【讨论】：