Ответ 1

У меня была такая же проблема. Microsoft, видимо, осознает эту проблему и исправлена ​​в предварительном просмотре следующей версии, подробнее см. Следующий комментарий:

https://developercommunity.visualstudio.com/comments/31393/view.html

В то же время обходным путем является открытие VS2017 (без загрузки вашего решения), откройте консоль диспетчера пакетов, дождитесь его полной загрузки и затем откройте решение.

Ответ 2

Я сталкивался с проблемой несколько раз, и все, кроме одного, были решены путем закрытия и перезапуска Visual Studio 2017. Поэтому, если вы этого не сделаете, попробуйте перезапустить VS, а если это не удастся, поищите более серьезные решения.

Ответ 3

Я столкнулся с той же проблемой в VS 2017 с последними обновлениями .NET SDK. Но вот быстрое и легкое решение, которое я смог найти.

Пока ваш проект открыт, откройте "Консоль диспетчера пакетов", а затем запустите команду 'dotnet restore'.

В окне консоли диспетчера пакетов убедитесь, что раскрывающееся меню "Источник пакета" сверху установлено на "Все", а "Проект по умолчанию" установлен на ваше имя проекта

Ответ 4

Просто перезапустите Visual Studio 2017, чтобы решить эту проблему.

Ответ 5

Аналогично @Keith это был результат SemVer в файле проекта 2017.

В файле .csproj я использую <PackageReference... Version="1.1.*" />. Когда решение сначала загружает Менеджер пакетов, выдается следующее:

Error occurred while restoring NuGet packages: The operation failed as details for project ProjectWebApi could not be loaded.

В VS 2017 15.2 (26430.14) он, похоже, не вызывает каких-либо реальных проблем, решение загружается и строит просто отлично. Если доступна более новая версия пакета, но не в локальном кэше .nuget, она загружается и устанавливается как часть запуска решения. Я не тестировал теги метаданных с предварительным выпуском или сборки, задерживая номер патча.

Ответ 6

Возможная работа вокруг

Попробуйте это: Измените местоположение вашего проекта на более простое местоположение. Например. поместите его на свой рабочий стол.

Возможная причина: возможно, она не могла загрузиться, потому что путь был проблемой (включенные пробелы, специальные символы и т.д.?).

Для справки:
Мой старый путь: C:\Users\Corey\Google Drive\College\Semesters\2018\Spring\CSIS 434 (Programming)\Projects\Project 1
Мой новый путь: C:\Users\Corey\Desktop

Вывод: из решения Andrew похоже, что Microsoft все еще пытается решить эту проблему. Несмотря на это, эта работа может работать для вас!

Ответ 7

Это произошло для меня из-за плохой поддержки VS2017 SemVer. Они вроде как пытались начать поддерживать его в файлах project.json, но при переводе на .csproj им удалось сделать что-то совсем сломанное.

У меня было:

<Project ToolsVersion="15.0" Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <Version>0.2.1-alpha</Version>
    ...

Это частично поддерживается VS2017, поскольку он компилируется, но он разбивает NuGet и имеет множество других проблем из-за некоторых частей .NET, распознающих Суффикс SemVer.

Исправлено удаление суффикса:

<Project ToolsVersion="15.0" Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <Version>0.2.1</Version>
    ...

Теперь работает NuGet.

Ответ 8

Я нашел еще одну проблему, вызвавшую эту ошибку.

Если вы добавите сведения о пакете для проекта и укажите версию с тремя цифрами, например 1.0.0, вы получите эту ошибку.

Если вы укажете версию как 1.0.0.0, решение будет построено отлично. Я предполагаю, что это нарушает внутреннюю проверку, так как это также установит Version в файл csproj.

TL; ДР:

Do: <Version>1.0.0.0</Version>

Не выполнять: <Version>1.0.0</Version>

ОБНОВЛЕНИЕ: см. также ответ Кейта.

Ответ 9

Убедитесь, что значение тега AssemblyName совпадает с значением тега RootNamespace, внутри .csproj. Это сработало для меня!