Последний Resharper дает мне случайные ошибки сборки

Вот уже неделю я получаю случайные ошибки сборки, которые не имеют никакого смысла. Сначала я выдал другой билд, пока ошибка не появилась. Но теперь частота стала слишком высокой, чтобы ее терпеть.

Ошибки появляются попеременно и заключаются в следующем:

  • error MSB3249: Application Configuration file "app.config" is invalid. Could not find file 'XXX\app.config'.

    Странная вещь в этом заключается в том, что проект, связанный с XXX, не имеет app.config (это собственная dll C++). Кроме того, XXX чередует проекты.

  • error MSB3027: Could not copy "YYY.dll" to "bin\x86\Debug\YYY.dll". Exceeded retry count of 10. Failed. 1>C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.Targets(3540,5): error MSB3021: Unable to copy file "YYYdll" to "bin\x86\Debug\YYY.dll". The process cannot access the file 'YYY.dll' because it is being used by another process.

    Они всегда идут парами. Глядя на это с помощью Process Explorer, этот другой процесс всегда MSBuild.exe или devenv.exe. Цифры.

  • Не удалось загрузить некоторые проекты. Я попытался воспроизвести это, чтобы скопировать сообщение об ошибке, но теперь частота слишком низкая.

  • Тупик/Голодание: сборка застревает в строке «Сборка начата», и мне приходится ее отменять. Когда я это делаю, появляются некоторые из предыдущих ошибок.

Моя среда: Windows 8.1 64 бит, Visual Studio 2012, Resharper 8.2, решение с 98 проектами (C#, VB.NET, C++/CLI и C++)

Я пробовал перестраивать, очищать, открывать и закрывать VS, перезапускать Windows, отключать Resharper и перезапускать VS. С этим последним исправлением ошибки исчезли, но я скучаю по изящному R#. Я посмотрю средство отслеживания проблем R #, но кто-нибудь еще сталкивался с этим? Какой-то обходной путь, кроме отключения R#?


person dario_ramos    schedule 25.04.2014    source источник


Ответы (2)


ReSharper недавно изменил способ разрешения ссылок — теперь он использует msbuild вместо ядра Visual Studio для разрешения некоторых проблем. Есть несколько вещей, которые вы можете попробовать:

  1. Установите последнюю версию Версия ReSharper 8.2.1 (версия RC была выпущена сегодня, 25 апреля, исправлено множество проблем, связанных с ошибками сборки)
  2. Перейдите к параметрам ReSharper, «Общие» и внизу снимите флажок с параметра Use msbuild to obtain project references. Тогда попробуйте восстановить.

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

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

person Igal Tabachnik    schedule 25.04.2014
comment
+1, только что установил обновление, и сборка стала намного стабильнее. Ошибок пока нет. Мне не нужно было снимать флажок, который вы упомянули. Если так будет продолжаться еще какое-то время, я приму ваш ответ. - person dario_ramos; 28.04.2014

У меня была аналогичная проблема (случайные ошибки сборки). Это происходит в двух решениях, которые я тестировал. Ошибки всегда будут включать тип ошибки «файл не найден» или «отказано в доступе». Ошибки возникали при использовании ReSharper 8.2.0.2160, но обновление до ReSharper 8.2.1000.4556 устранило проблему (откат до ReSharper 8.0.1000.2286 также устранил проблему). Я не пробовал играть с опцией «MS build», упомянутой выше.

person kenntornslev    schedule 10.07.2014
comment
Привет - это новый вопрос? Вы можете написать свой собственный вопрос и вернуться к этому вопросу. В противном случае, это, вероятно, скоро будет удалено... - person Taryn East; 10.07.2014
comment
Это было задумано как уточнение ответа, данного выше. - person kenntornslev; 10.07.2014
comment
Это звучит как разработка проблемы, с которой вы столкнулись... если это разработка решения, то, вероятно, просто нужно немного изменить формулировку, чтобы сделать это более понятным... :) Например, используя прошедшее время, которое я имел аналогичная проблема... которую я решил с помощью... Напротив, использование настоящего времени подразумевает, что у вас все еще есть проблема, т.е. она еще не решена, и, следовательно, это не решение. - person Taryn East; 10.07.2014