Почему Rebuild не работает без ошибок?
С этого утра эта ошибка продолжает появляться. Я создаю все решение (25 проектов под управлением С#) и появляется сообщение "Перестроить все не удалось", но без ошибок! (У меня есть 13 предупреждений о том, что COM не поддерживает Generics, но это "нормально", потому что одна dll выставляется как COM.)
Не ответ сам по себе - но вам лучше посмотреть окно вывода и посмотреть, что там там написано.
Кроме того, чтобы помочь с этим, вы можете посмотреть на многословие MSBuild - как показано на этом скриншоте (последние два варианта):
Остерегайтесь - самый высокий уровень генерирует МАССИВНОЕ количество информации.
Наконец - запуск msbuild из папки решения в командной строке действительно вызовет проблему - потому что сообщения об ошибках и предупреждения появляются соответственно красным и желтым цветом.
Я нашел свое собственное решение, и оно простое:
При возникновении этой ошибки сохраните проект и закройте VS 2013. После этого снова откройте VS2013 и откройте последний проект.
Отлично работает. Но это очень раздражает каждый раз!
Многие люди сообщили об этой проблеме в VS2010, VS2012 и VS2013.
Может быть поврежденный файл настроек пользователя.
Закройте решение, удалите его .suo(.v12.suo для VS2012 +), снова откройте решение, а Visual Studio построит новый. Вы потеряете проект StartUp, точки останова, закладки, какие файлы открыты, какие проекты/папки будут расширены и т.д. Но все это незначительно по сравнению с решением, не строящим!
Вы пытались очистить решение до его перезагрузки?
Это список проверок и вещей, которые я бы сделал, если бы вы были вами (попробуйте построить после каждого шага):
Несколько мгновений назад я исправил его с установкой установки .NET Framework (.NET Framework v4.0 Extended в моем случае).
У меня была такая же проблема в VS 2015. Я попытался следующее безуспешно:
Наконец, я попробовал ответить Кита Робертсона, удалить .suo (\Visual Studio 2015\Projects\[ProjectName]\.vs\[ProjectName]\v14\.suo). Хотя это не дало мне хорошую сборку, в конце концов я получил сообщение об ошибке, в котором говорилось, что у меня есть две точки входа в мое приложение. Я перешел к свойствам приложения (Alt + Enter) и выбрал объект автозагрузки из выпадающего списка.
Выберите подходящую целевую структуру
- Щелкните правой кнопкой мыши на проекте
- Свойства
- На вкладке приложения выберите целевой каркас
Это сработало для меня.
Было ли решение когда-либо построено?
Я только что это случилось со мной и понял, что оставил строку "#error" в своем коде и забыл об этом. Когда я попытался построить, сборка завершилась неудачно, но строка #error не обнаружилась в моих ошибках.
Попробуйте найти все для '#error'
Я исправил его в своей новой реализации Visual Studio 2013, перейдя в проект базы данных/Настройки проекта и заметив, что целевой платформой был SQL Server 2014 вместо 2012 года, как и должно быть.
Я получил подобную проблему сегодня и исправил ее с ремонтом.
Appwiz.cpl 
Как только вероятность получения этой ошибки возникает, когда мы пытаемся переименовать имя ссылки службы, мы приводим другое имя в ссылке на службу, но в пространстве имен где-то, где оно будет ссылаться на старое имя, поэтому, если вы удалите и добавите ссылка на службу затем сохраняет одно и то же имя, иначе мы можем столкнуться с этой ошибкой, но мы можем увидеть ошибку в окне вывода.
По-видимому, есть много причин этого. Я только что нашел причину моей проблемы:.NET-версия нового проекта, который я создал, была выше, чем версия проекта верхнего уровня. (4.5.2 против 4.0)
У меня такая же проблема. Я пытался сослаться на более высокую версию .net Framework (4.5.2), чтобы понизить .net Framework версию (4.5), что вызывало ошибку сборки. Я сделал версию одинаковой в обоих проектах, и она работала.
В моем случае это была неправильная дата и время компьютера.
Проверьте окно вывода (View → Output), так как оно скажет вам, что происходит не так. Иногда ссылка может отсутствовать или возникает проблема с целевой версией .NET для одного проекта в решении.
Эта ошибка мне кажется немного общей. Я также прошел через эту ситуацию, но мне удалось решить ее иначе, чем любая из упомянутых здесь.
У меня есть проект и несколько зависимостей. И одна из этих зависимостей претерпела изменения. 
При компиляции основного проекта в режиме отладки я убедился, что все в порядке. Однако произошел переход в режим выпуска и перекомпиляция проблемы. Rebuild all failed и 0 Errors
Анализируя выходные данные отладки, я обнаружил ошибку:
Хотя зависимости сборки настроены правильно. При компиляции в режиме выпуска основной проект не нашел новый метод, созданный во вторичном проекте. Поэтому мне пришлось перекомпилировать каждый дополнительный проект один за другим в режиме релиза. После этого я перекомпилировал основной проект и все заработало.
Надеюсь, это поможет кому-то!
Я не получал никаких отзывов/сообщений/ошибок. Просто все проекты не удалось построить.
Я закрыл и попробовал еще раз - я заметил ошибку, говорящую "вы не авторизованы для доступа..."
Я нажал на свою учетную запись, повторно ввел свои учетные данные и пересобрал решение.
Вуаля! Я получил то, что привык видеть при создании решения - множество ошибок во всей их красе.
Надеюсь, это кому-нибудь поможет.
У меня просто было то же самое. Для меня это помогло перезагрузить VS и запустить его от имени администратора.
Вот еще одна причина, которая может показаться знакомой для некоторых. Я интегрировал некоторый код в свое решение, которое обернуло DLL. Файл кода С#, который шел вместе с ним, предлагал хороший управляемый API и обрабатывал низкоуровневую загрузку LoadLibrary для доступа к DLL. Оба имели одинаковое базовое имя, поэтому у меня были SomeName.cs и SomeName.dll. Я мог бы просто вставить его в любой проект, и он бы работал.
Через некоторое время это было не так приятно, так как я начал использовать его в разных проектах. Я получил копии как DLL, так и кода оболочки в нескольких проектах. Поэтому я решил, что было бы лучше поместить код оболочки и DLL в новый проект библиотеки классов, а затем ссылаться на этот новый проект из других проектов.
После того, как я это сделал, я начал понимать эту проблему. Сборка шла хорошо до самого последнего этапа, а затем провалилась без ошибок. Вывод показал только успехи.
Проблема была в названии проекта библиотеки классов упаковки. Я использовал то же самое базовое имя (SomeName) для этого. По умолчанию имя сборки будет SomeName.dll, и у меня уже был один такой файл (DLL файл, который нужно обернуть), поэтому у меня возник конфликт с выходными файлами.
После переименования проекта упаковки и его выходной сборки в SomeNameWrapper проблема исчезла.
Возможно, это не ваша точная причина, но, вероятно, у вас также есть конфликт имен или проблема развертывания. И неудивительно, что компилятор не выдаст вам ошибку, потому что на этапе компиляции нет проблем, проблема начинается с развертывания, и, очевидно, это не проявляется очевидным образом.