Подтвердить что ты не робот

Visual Studio 2012 добавляет ссылку на неправильную DLL

У меня возникли проблемы с получением Visual Studio для создания моего проекта в режиме выпуска... это дает мне ошибки в том, что сборки являются неправильным форматом. Оказывается, некоторые сборки x86 ссылаются вместо x64 сборок. Ассембли, такие как PresentationCore, System.Data и т.д.

Вещи, которые я пробовал:

  • Режим отладки, любой процессор строит отлично.

  • Режим отладки, x64 строит отлично.

  • Режим деблокирования, любой CPU не работает

  • Режим освобождения, x64 терпит неудачу (это комбинация, которую я хотел бы создать в моем проекте)

Проблема возникает, когда я пытаюсь удалить ссылку x86 и переключить ее на ссылку x64. Visual Studio просто добавляет старую ссылку x86 вместо ссылки x64. Например:

Я удаляю ссылку System.Data, которая находится в C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Data.dll

Я просматриваю и добавляю C:\Windows\Microsoft.NET\Framework64\v2.0.50727\System.Data.dll, но когда я нажимаю на эту ссылку в System.Data, путь остается чисто до старой dll и вызывает ту же ошибку. Это происходит и с несколькими другими DLL.

Кто-нибудь знает о решении этой проблемы?

4b9b3361

ОТВЕТЫ

Ответ 1

Ассембли, такие как PresentationCore, System.Data и т.д.

Мне не нравится отвечать на вопрос, не видя сообщение об ошибке. Но этого вторичного доказательства достаточно, чтобы ответить на вопрос. Во-первых, это не ошибка, это предупреждение . Это выглядит так:

предупреждение CS1607: сборка сборки - ссылочная сборка "System.Data.dll" нацелена на другой процессор

Вы также увидите файл mscorlib.dll. И PresentationCore.dll в проекте WPF. Что здесь происходит, так это то, что эти сборки являются особенными, они являются сборками смешанного режима. Другими словами, они содержат как собственный код, так и управляемый код. Нативный код является создателем проблем, такая сборка может использоваться только в проекте, который нацелен на правильный процессорный вкус. Если вы его смешиваете, вы получаете исключение BadImageFormatException во время выполнения.

Это не настоящая проблема с сборками .NET, у вашей машины фактически есть две версии этих DLL, хранящихся в GAC. Один, который будет использоваться, если ваша программа работает в 32-битном режиме, а другая, которая используется в 64-битном режиме. CLR автоматически выбирает правильный.

Однако есть только одна версия ссылочной сборки, та, которая хранится в c:\windows\microsoft.net, и что вы передаете компилятору, чтобы прочитать метаданные. Это всегда версия x86, там нет другой, поэтому не надо ее искать. Опять же, это не проблема, только метаданные ссылочной сборки используются компилятором, она не выполняет какой-либо из ее кода. И метаданные не зависят от битности сборки.

Тем не менее, это может быть проблемой, если вы создаете свою собственную сборку в смешанном режиме. Вы можете легко забыть о необходимости предоставить две версии. Так что компилятор беспокоится о том, что он видит, что вы попросили построить AnyCPU или x64 вашего проекта. Но обнаруживает, что эталонная сборка может работать только тогда, когда вы нацеливаете x86. Поэтому он немного скрипит, просто напомним, что есть некоторые доказательства того, что вы ошибаетесь и что ваша программа может упасть на исключение BadImageFormatException при ее запуске. Он иначе не рассматривает ссылочную сборку фрейма, отличную от вашей собственной ссылочной сборки.

Итак, особенность, а не ошибка. Просто предупреждение, которое не мешает вашей программе строить. Вы можете смело игнорировать это предупреждение, так как вы знаете, что .NET имеет правильную сборку, доступную в GAC во время выполнения. Примечательно, что .NET 4.0 не имеет этой проблемы, он использует очень разные сборки ссылок, у которых не установлен флаг ILONLY метаданных.

Ответ 2

Нечетное поведение. Превращение "Сформировать сборку сериализации" в разделе "Сборка в свойствах проекта" делает проект очень простым в режиме выпуска. Глядя на эта ссылка показывает, что этот параметр связан с XML-сериализацией, которую мы даже не используем в нашем решении.

Очень странно. Все еще ищете объяснение этого вопроса и поведения здесь.

Ответ 3

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

Для этого:

  • Перейдите в раздел "Скомпилировать > Администрирование конфигурации..."
  • В разделе "Конфигурация активных решений" выберите "Release", которая представляет собой конфигурацию, которая создает проблемы.
  • В разделе "Платформа активных решений" отметьте "Любой процессор". Если "x64" определен, вы также можете выбрать его.
  • Посмотрите список проектов сборки. Все проекты, необходимые для решения, должны быть отмечены правильными значениями в "Конфигурация", "Платформа" и иметь проверку "Компиляция".

В моем случае у меня есть проект sandcastle, который я снимаю большую часть времени, по крайней мере, в режиме отладки, потому что для компиляции требуется возраст. Иногда бывает, что один проект не имеет конфигурации для конфигурации "Release", и поэтому, когда процесс сборки пытается получить свои результаты, они не существуют (DLL не существует), и это создает исключение. В других ситуациях может быть, что проект вынужден компилировать для x86 (или x64), а остальное - нет, и поэтому возникает ошибка при попытке связать другие проекты ссылок с соответствующей версией ссылочных библиотек DLL.

Ответ 4

Какую версию .NET вы компилируете? Если вы можете изменить проект на более позднюю версию .NET Framework, это может помочь.

Ответ 5

Мой веб-проект VS2010 также генерировал эти предупреждения, и IIS выбрасывал исключение BadImageException. Настройки сборки/конфигурации/платформы выглядели нормально, но в окне "Выход" показано, что DLL была построена в папке x64 для любой конфигурации процессора. Удалены все папки под корзиной и перестроены. Предупреждения исчезли, и исключение BadImageException прошло.