我有一个解决方案，其中包含许多不同的api，它们引用了我们在Utilitys文件夹中构建的不同依赖项。
在Azure Devops中，当我去构建解决方案时，它抱怨它找不到那些依赖项的依赖项并失败。这些依赖关系指向解决方案的相同依赖关系，这些依赖关系由几个文件夹组成。因此依赖项HintPath为../../packages，而不是解决方案的依赖项HintPath为./packages
当我独立于解决方案构建csproj文件时（即，不将其构建为解决方案的依赖项），它们的构建就很好，并且没有发现packages文件夹。 Nuget Restore报告没有问题，我们已经将软件包检入到源代码管理中，因此不会丢失任何内容。即使有，Nuget也会在它们丢失时将其还原。
所以我在想：当我构建解决方案并尝试在下面构建依赖项时，它试图访问从解决方案目录开始然后从那里向上的软件包（master/../../packages/而不是{ {1}}）。该文件夹不存在，会导致其失败，并且对于为什么单独构建依赖项有意义。
是否有人在Azure Dev Ops中遇到过此问题，或者有任何解决方法的想法？
我们可以将提示路径编辑为指向./的依赖关系，这些依赖关系已经起作用了，但是我们仍然有一个本地构建，我们仍然将其用于生产，但这种生产方式无法正常运行并且会中断。我们正在尝试使它们保持同步。
如果您有任何想法请告诉我。
谢谢
答案 0 :(得分：0)
Azure构建管道：构建解决方案依赖项失败-找不到软件包，但独立构建csproj依赖文件工作正常
要解决此问题，您可以尝试将这些依赖项的依赖项安装到解决方案中。那是因为NuGet团队不赞成NuGet 3.0中的解决方案级别软件包：
https://github.com/NuGet/Home/issues/522
因此，我们需要确保该解决方案使用的所有软件包都位于默认软件包文件夹./packages中，而不是其他软件包文件夹中。
如果上述方法对您没有帮助，您可以在问题中分享您的项目结构。
希望这会有所帮助。
答案 1 :(得分：0)
最适合我的解决方案是更改NuGet软件包在解决方案中的存储方式。除了使用packages.config，Visual Studio中还提供了一个使用PackageReference的选项，这是一种为NuGet引用软件包的新方法。将我们的大多数项目切换为使用NuGet的新方式后，它便可以运行和构建。