Visual Studio 2017 无法在 .NET 4.7 项目中安装 nuget 包

Question

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

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

我使用的是 Visual Studio 2017 15.3.3 Enterprise（最新的和最好的）。

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

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

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

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

谢谢。

Answer 1

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

结果，包目录绝对塞满了不属于那里的旧东西。 所以，我手动清理了所有的 cruft，手动清理了 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 错误的原因。

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

Answer 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 的未来版本会有更大的长度限制。 在此之前，我们可以确保我们的文件名不会太长。

Answer 3

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

Answer 4

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

Answer 5

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

Answer 6

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

我通过复制项目文件夹然后使用 USB 将其粘贴到新笔记本电脑中来解决此问题。

我希望这可以帮助

Answer 7

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

Answer 8

尝试从File->Close Solution并再次打开它。

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