Восстановление nuget: исключение было выдано целью вызова

Question

Когда я бегу nuget restore из командной строки я получаю

Ошибка анализа файла решения на MyProject.sln: Исключение было выдано целью вызова.

но восстановление пакетов nuget из Visual Studio выполняется без ошибок. Есть обходные пути?

Answer 1

Эта ошибка особенно расстраивает большие решения во многих проектах, так как NuGet не намекает на то, что в момент разбора файла произошла ошибка.

Чтобы проанализировать проблему, попробуйте msbuild MyProject.sln; парсер msbuild немного более многословен. По крайней мере, он даст вам номер строки, чтобы вы знали, где искать ошибку. открыто MyProject.sln в текстовом редакторе, чтобы проверить эту строку. В моем случае это была просто пустая строка, случайно введенная при ручном разрешении конфликта слияния TFS.

(Это может показаться довольно очевидным, чтобы msbuild, но в нашем случае этот вызов был частью большого скрипта сборки, где nuget restore будет первым, прерывая процесс сборки до msbuild был достигнут.)

В будущем выпуске NuGet должно появиться более подробное сообщение об ошибке; см. выпуск № 1150.

Answer 2

Я нашел решение после изучения нашего контроля версий. Произошло неправильное слияние (в git), в результате чего у нашего решения было 2 вложенных проекта.

Project(...) = ...
Project(...) = ...
EndProject
Global
.......

и последний EndProject отсутствовал. Интересно то, что Visual Studio не вышел из строя, хотя наш файл решения был эффективно поврежден.

Добавление EndProject между двумя проектами исправило ошибку.

Answer 3

У меня была такая же проблема. Проблема была в том, что в файле sln есть такие же пустые строки. Я убрал строки. Решено

Бывшая проблема

//Blank Line
Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio 15
VisualStudioVersion = 15.0.27130.2010
MinimumVisualStudioVersion = 10.0.40219.1

    GlobalSection(ProjectConfigurationPlatforms) = postSolution
        {658E5ED2-A01E-41DD-A952-F5EDE9E4AEE0}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
        {658E5ED2-A01E-41DD-A952-F5EDE9E4AEE0}.Debug|Any CPU.Build.0 = Debug|Any CPU

        {658E5ED2-A01E-41DD-A952-F5EDE9E4AEE0}.Prod|Any CPU.ActiveCfg = Prod|Any CPU
        {658E5ED2-A01E-41DD-A952-F5EDE9E4AEE0}.Prod|Any CPU.Build.0 = Prod|Any CPU
    EndGlobalSection

Фиксированная версия

Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio 15
VisualStudioVersion = 15.0.27130.2010
MinimumVisualStudioVersion = 10.0.40219.1

    GlobalSection(ProjectConfigurationPlatforms) = postSolution
        {658E5ED2-A01E-41DD-A952-F5EDE9E4AEE0}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
        {658E5ED2-A01E-41DD-A952-F5EDE9E4AEE0}.Debug|Any CPU.Build.0 = Debug|Any 
        {658E5ED2-A01E-41DD-A952-F5EDE9E4AEE0}.Prod|Any CPU.ActiveCfg = Prod|Any CPU
        {658E5ED2-A01E-41DD-A952-F5EDE9E4AEE0}.Prod|Any CPU.Build.0 = Prod|Any CPU
    EndGlobalSection

Answer 4

Мое решение состояло в том, чтобы обновить nuget.exe до последней версии.

Answer 5

У меня такая же проблема. Это произошло на нашем CI-сервере (TFS 2018) при использовании задачи "Восстановление Nuget". По-видимому, агент сборки использовал старую версию nuget (4.1), и у него возникли проблемы с чтением файла решения Visual Studio 2019 (sln и / или csproj), что привело к ошибке, указанной @sashoalm.

Ответ от Microsoft заключался в том, чтобы использовать задачу "Nuget Tool Installer", но она не работала за стеной корпоративного прокси, за которой я нахожусь. Судя по тому, что я читал, людям это сложно. Согласно Microsoft, они решили эту проблему, но только в Azure Devops Server 2019 в обновлении задачи "Установщик инструмента Nuget".

Какое решение - вручную загрузить выбранный вами nuget.exe и скопировать его в агент сборки. Затем замените задачу "Nuget" на задачу "Powershell" и выполните

Write-Host "Restoring packages"
Write-Host "Using nuget.exe at" $(nugetexepath)
$(nugetexepath) restore [PATH_TO_SLN_FILE] -Verbosity Detailed -NonInteractive

Я добавил переменную

nugetexepath

а также в конфигурации сборки.

Возможно, это будет решено в будущем обновлении от Microsoft, которое поможет всем, кто все еще находится на TFS 2018, а не на Azure Devops Server 2019.

Answer 6

Это также может произойти после установки VS 2017 15.7, но без установки.Net 4.7.2.

Смотрите здесь для более подробной информации: https://github.com/NuGet/Home/issues/6918

Answer 7

Я получил эту ошибку из моего лазурного конвейера. Я зашел на сервер сборки и запустил msbuild mysolution.sln. Это выявило другую ошибку:

Необработанное исключение: System.IO.FileNotFoundException: не удалось загрузить файл или сборку Microsoft.Build.Framework, Version=15.1.0.0,Culture= нейтральный, PublicKeyToken=b03f5f7f11d50a3a или одну из его зависимостей. Система не может найти указанный файл. в Microsoft.Build.CommandLine.MSBuildApp.Execute(String commandLine)
в Microsoft.Build.CommandLine.MSBuildApp.Main()

Именно тогда я обнаружил, что нашел этот ответ. Не удалось загрузить файл или сборку Microsoft.Build.Framework(VS 2017) и подумал, что мне нужно обновить nuget, поэтому я добавил шаг в свой конвейер для задачи установщика NuGet и установил его. использовать более новую версию.

https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/tool/nuget?view=azure-devops

Больше никаких ошибок.