Visual Studio "Восстановить все не удалось"

Ответ 1

Не ответ сам по себе - но вам лучше посмотреть окно вывода и посмотреть, что там там написано.

Кроме того, чтобы помочь с этим, вы можете посмотреть на многословие MSBuild - как показано на этом скриншоте (последние два варианта):

Остерегайтесь - самый высокий уровень генерирует МАССИВНОЕ количество информации.

Наконец - запуск msbuild из папки решения в командной строке действительно вызовет проблему - потому что сообщения об ошибках и предупреждения появляются соответственно красным и желтым цветом.

Ответ 2

Я нашел свое собственное решение, и оно простое:

При возникновении этой ошибки сохраните проект и закройте VS 2013. После этого снова откройте VS2013 и откройте последний проект.

Отлично работает. Но это очень раздражает каждый раз!

Многие люди сообщили об этой проблеме в VS2010, VS2012 и VS2013.

Ответ 3

Может быть поврежденный файл настроек пользователя.

Закройте решение, удалите его .suo(.v12.suo для VS2012 +), снова откройте решение, а Visual Studio построит новый. Вы потеряете проект StartUp, точки останова, закладки, какие файлы открыты, какие проекты/папки будут расширены и т.д. Но все это незначительно по сравнению с решением, не строящим!

Ответ 4

Вы пытались очистить решение до его перезагрузки?

Ответ 5

Это список проверок и вещей, которые я бы сделал, если бы вы были вами (попробуйте построить после каждого шага):

• Включен ли список ошибок? (Иногда я забыл активировать, и я вижу только предупреждения и сообщения).
• Проверить окно вывода сообщений об ошибках.
• Чистое решение.
• Двойная проверка после очистки, что все удалено из папок отладки.
• Создайте его в режиме выпуска.
• Проект проекта сборки для проекта, пока вы не выделите проблемный проект.
• Удалите код COM и комментарий, чтобы узнать, является ли это источником проблемы.
• Перезапустите VS2010.
• Перезапустить окна.

Ответ 6

Несколько мгновений назад я исправил его с установкой установки .NET Framework (.NET Framework v4.0 Extended в моем случае).

Ответ 7

У меня была такая же проблема в VS 2015. Я попытался следующее безуспешно:

1. Закрыть VS проект и открыть заново
2. Закройте все открытые проекты VS и снова откройте проект, в котором возникла проблема
3. Чистый раствор
4. Восстановить решение
5. Удалить все файлы в bin\debug и bin\release

Наконец, я попробовал ответить Кита Робертсона, удалить .suo (\Visual Studio 2015\Projects\[ProjectName]\.vs\[ProjectName]\v14\.suo). Хотя это не дало мне хорошую сборку, в конце концов я получил сообщение об ошибке, в котором говорилось, что у меня есть две точки входа в мое приложение. Я перешел к свойствам приложения (Alt + Enter) и выбрал объект автозагрузки из выпадающего списка.

Ответ 8

Выберите подходящую целевую структуру
- Щелкните правой кнопкой мыши на проекте
- Свойства
- На вкладке приложения выберите целевой каркас
Это сработало для меня.

Ответ 9

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

Было ли решение когда-либо построено?

Ответ 10

Я только что это случилось со мной и понял, что оставил строку "#error" в своем коде и забыл об этом. Когда я попытался построить, сборка завершилась неудачно, но строка #error не обнаружилась в моих ошибках.

Попробуйте найти все для '#error'

Ответ 11

Я исправил его в своей новой реализации Visual Studio 2013, перейдя в проект базы данных/Настройки проекта и заметив, что целевой платформой был SQL Server 2014 вместо 2012 года, как и должно быть.

Ответ 12

Я получил подобную проблему сегодня и исправил ее с ремонтом.

1. Начните
2. Бежать…
3. Appwiz.cpl
4. (Найдите установленную версию Visual Studio)
5. Щелкните правой кнопкой мыши
6. + Изменить
7. Ремонт

Ответ 13

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

Ответ 14

По-видимому, есть много причин этого. Я только что нашел причину моей проблемы:.NET-версия нового проекта, который я создал, была выше, чем версия проекта верхнего уровня. (4.5.2 против 4.0)

Ответ 15

У меня такая же проблема. Я пытался сослаться на более высокую версию .net Framework (4.5.2), чтобы понизить .net Framework версию (4.5), что вызывало ошибку сборки. Я сделал версию одинаковой в обоих проектах, и она работала.

Ответ 16

В моем случае это была неправильная дата и время компьютера.

Ответ 17

Проверьте окно вывода (View → Output), так как оно скажет вам, что происходит не так. Иногда ссылка может отсутствовать или возникает проблема с целевой версией .NET для одного проекта в решении.

Ответ 18

Эта ошибка мне кажется немного общей. Я также прошел через эту ситуацию, но мне удалось решить ее иначе, чем любая из упомянутых здесь.

У меня есть проект и несколько зависимостей. И одна из этих зависимостей претерпела изменения.

При компиляции основного проекта в режиме отладки я убедился, что все в порядке. Однако произошел переход в режим выпуска и перекомпиляция проблемы. Rebuild all failed и 0 Errors

Анализируя выходные данные отладки, я обнаружил ошибку:

Хотя зависимости сборки настроены правильно. При компиляции в режиме выпуска основной проект не нашел новый метод, созданный во вторичном проекте. Поэтому мне пришлось перекомпилировать каждый дополнительный проект один за другим в режиме релиза. После этого я перекомпилировал основной проект и все заработало.

Надеюсь, это поможет кому-то!

Ответ 19

Я не получал никаких отзывов/сообщений/ошибок. Просто все проекты не удалось построить.

Я закрыл и попробовал еще раз - я заметил ошибку, говорящую "вы не авторизованы для доступа..."

Я нажал на свою учетную запись, повторно ввел свои учетные данные и пересобрал решение.

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

Надеюсь, это кому-нибудь поможет.

Ответ 20

У меня просто было то же самое. Для меня это помогло перезагрузить VS и запустить его от имени администратора.

Ответ 21

Вот еще одна причина, которая может показаться знакомой для некоторых. Я интегрировал некоторый код в свое решение, которое обернуло DLL. Файл кода С#, который шел вместе с ним, предлагал хороший управляемый API и обрабатывал низкоуровневую загрузку LoadLibrary для доступа к DLL. Оба имели одинаковое базовое имя, поэтому у меня были SomeName.cs и SomeName.dll. Я мог бы просто вставить его в любой проект, и он бы работал.

Через некоторое время это было не так приятно, так как я начал использовать его в разных проектах. Я получил копии как DLL, так и кода оболочки в нескольких проектах. Поэтому я решил, что было бы лучше поместить код оболочки и DLL в новый проект библиотеки классов, а затем ссылаться на этот новый проект из других проектов.

После того, как я это сделал, я начал понимать эту проблему. Сборка шла хорошо до самого последнего этапа, а затем провалилась без ошибок. Вывод показал только успехи.

Проблема была в названии проекта библиотеки классов упаковки. Я использовал то же самое базовое имя (SomeName) для этого. По умолчанию имя сборки будет SomeName.dll, и у меня уже был один такой файл (DLL файл, который нужно обернуть), поэтому у меня возник конфликт с выходными файлами.

После переименования проекта упаковки и его выходной сборки в SomeNameWrapper проблема исчезла.

Возможно, это не ваша точная причина, но, вероятно, у вас также есть конфликт имен или проблема развертывания. И неудивительно, что компилятор не выдаст вам ошибку, потому что на этапе компиляции нет проблем, проблема начинается с развертывания, и, очевидно, это не проявляется очевидным образом.