В настоящее время проект содержит ссылки на несколько версий

Ответ 1

Я смог устранить эту проблему, удалив все файлы в моей папке bin, а затем восстановив проект. Для меня проблема заключалась в том, что очистка проекта заключалась только в удалении библиотек DLL в папке bin\Debug, в то время как старые библиотеки DLL остались в папке bin\Release.

Ответ 2

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

Ответ 3

У меня была такая же "очевидная" проблема, которая стоила мне целый день, пытаясь разрешить. Я тщательно проверял зависимости проекта, и все указывали на ту же версию злоумышленника. Я даже отключил свою локальную папку и вытащил все из Subversion - все равно. Я запускал Process Explorer и искал DLL только для того, чтобы найти старую dll, на которую ссылается .NET Reflector. Я использовал .NET Reflector за пару дней до отладки старой версии в другом решении Visual Studio, а .NET Relector ссылался на более старую dll в одной из своих папок. Это может сэкономить время.

Ответ 4

Я обнаружил, что проблема связана с тем, что я случайно установил неправильную папку запуска. Например, у меня был PROJECT_A с зависимостью от PROJECT_B, а PROJECT_A должен был быть запущенным проектом. Однако я не понимал, что PROJECT_B теперь является стартовой папкой.

PROJECT_A компилировался со старой ссылкой на DLL PROJECT_B, а затем PROJECT_B впоследствии создавал новую версию и копировал эту новую версию в папку bin.

Корректировка папки запуска исправила это для меня.

Ответ 5

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

Ответ 6

Сначала обходной путь: я отключил версию сборки Autoincrement!

Заметьте, что эта проблема возникла только в Vs2013 с копией решения, отлично работающего vs2010. Vs2013 Сборка, восстановление, чистое решение, ручное удаление. /bin или./obj или% TEMP% не решило проблему. Я также написал новое решение с нуля в Vs2013, чтобы избежать трупы от vs2010: это новое решение скомпилировано только дважды: в третий раз ошибка снова появилась без каких-либо изменений... что-то в машине оставалось грязным.

Теперь выражение...

У меня была та же проблема с решением с проектом 86 со следующим контуром: "60.dll" является неправильной dll:

- 99.exe 
-- 80.dll
---- 70.dll
------- 60.dll
-- 81.dll
-- 82.dll
---- 60.dll

Так возникла ошибка BC32206 с причиной.

The project '99.exe' currently contains references to more than one version of '60.dll, 
a direct reference to version 4.11.5618.23545 and an indirect reference (through '82.dll') to version 4.11.5618.23549. 
Change the direct reference to use version 4.11.5618.23549 (or higher) of '60.dll'

Обратите внимание, что версия отличается только версией от 23545 до 23549 (так что только единица "4" ): в некоторой перестройке это различие было единицей "1"; помните, что это число (секунды с полуночи /2), я понял, что по какой-то причине '60.dll 'был скомпилирован дважды... Нечего делать: я не нашел никакой другой копии '60.dll' с дата-время, соответствующее запросу более высокого значения "23549". Так что реально, что что-то прослушивается в Vs2013.

Итак, последний шанс: я отключил автоинкремент, и я прикрепил версию Assembly к XY0.0: этого вполне достаточно для моей цели, потому что "60.dll" является частью всеобъемлющей версии и никогда не следует развертывать отдельно (I по-прежнему используйте fileVersion для просмотра нужного файла)

Ответ 7

Я смог очистить сообщенный конфликт, изменив [сборка: AssemblyVersion ( "1.0. *" )] в [assembly: AssemblyVersion ( "1.0.5814.0" )] в файле AssemblyInfo.cs проекта "Оскорбление".

Основываясь на следующих наблюдениях, это, по-видимому, проблема IDE:

• Всякая разная версия сообщается при каждом запуске Visual Studio;
• Например, между версиями 1.0.5814.18599 и 1.0.5814.18600.
• В то время как фактическая ревизия во всех папках bin... 17929.

Видимо, VS обнаруживает и "кэширует" конфликт при его запуске. Clean или Rebuilt не дают никакой помощи.

Кроме того, кажется, что только такие библиотеки классов С# вызывают это поведение.

Ответ 8

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

Ответ 9

Я решил эту проблему для всех задач script в моем пакете SSIS, отредактировав файл .DTSX и заменив все экземпляры на "Microsoft SQL Server\100\SDK\Assemblies" на "Microsoft SQL Server\120\SDK\ассамблей".

Я сделал "replace", а затем обновился в VS 2013, и все ошибки ушли.

Обратите внимание, что ссылки уже ссылались на версию 12, но "HintPath" все еще ссылался на путь "\ 100". Я предполагаю, что это было источником проблемы.

Вот фрагмент XML из файла .DTSX до и после:

ДО:

<ItemGroup>
    <Reference Include="Microsoft.SqlServer.ManagedDTS, Version=12.0.0.0, Culture=Neutral, PublicKeyToken=89845dcd8080cc91">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>..\..\..\..\..\..\..\..\Program Files (x86)\Microsoft SQL Server\100\SDK\Assemblies\Microsoft.SQLServer.ManagedDTS.dll</HintPath>
    </Reference>
    <Reference Include="System" />
    <Reference Include="System.Data" />
    <Reference Include="System.Windows.Forms" />
    <Reference Include="System.Xml" />
    <Reference Include="Microsoft.SqlServer.ScriptTask, Version=12.0.0.0, Culture=Neutral, PublicKeyToken=89845dcd8080cc91" />
  </ItemGroup>

ПОСЛЕ:

 <ItemGroup>
    <Reference Include="Microsoft.SqlServer.ManagedDTS, Version=12.0.0.0, Culture=Neutral, PublicKeyToken=89845dcd8080cc91">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>..\..\..\..\..\..\..\..\Program Files (x86)\Microsoft SQL Server\120\SDK\Assemblies\Microsoft.SQLServer.ManagedDTS.dll</HintPath>
    </Reference>
    <Reference Include="System" />
    <Reference Include="System.Data" />
    <Reference Include="System.Windows.Forms" />
    <Reference Include="System.Xml" />
    <Reference Include="Microsoft.SqlServer.ScriptTask, Version=12.0.0.0, Culture=Neutral, PublicKeyToken=89845dcd8080cc91" />
  </ItemGroup>

Ответ 10

Я просто зашел в "NuGet" и удалил все пакеты, относящиеся к конфликтующей библиотеке. Затем я тщательно снова установил систему, убедившись, что каждый элемент имеет тот же самый (последний) номер версии. Я использовал модули "cEfSharp", но по ошибке установил смесь версий 57 и 51.

Ответ 11

в моем случае, очистить и построить хорошо работает

Ответ 12

Попробуйте удалить все файлы bin/debug/*