Ответ 1
Это нормальное предупреждение, вы всегда получите его, когда вы явно нацелитесь на x64. Это не будет проблемой во время выполнения, потому что на 64-битной машине GAC хранит 64-разрядную версию mscorlib.dll.
Длинная версия: несколько сборок .NET содержат неуправляемый код. Это делает их чувствительными к битту процесса, который их использует. Mscorlib.dll - один из них, System.Data.dll и сборки WPF - другие примеры. Microsoft решила это, построив две версии этих сборок, 32-разрядную и 64-битную. GAC может хранить их оба, разрешенные свойством AssemblyName.ProcessorArchitecture. "Обычный" параметр для этого свойства - MSIL, используемый, когда сборка содержит чистый IL. Одна копия сборки может быть использована как 32-разрядным, так и 64-битным процессом.
Ссылочные сборки, используемые компилятором, представляют собой копию сборников .NET. Компилятор использует их исключительно для своих метаданных. Эти копии, однако, являются копиями 32-битных сборок, они будут иметь ProcessArchitecture для X86 для сборок, содержащих неуправляемый код.
Вы можете видеть, где это происходит, вы компилируете для x64, и компилятор видит ссылку на x86. Достаточно генерировать предупреждение "эта программа будет работать только в том случае, если вы также предоставите x64 версию сборки". Это, безусловно, относится к сборкам .NET, но не обязательно для ваших собственных.
Возможно, примечательно, что это было решено в .NET 4.0. Он использует очень разные ссылочные сборки, которые хранятся в C:\Program Files (x86)\Reference Assemblies. В отличие от сборочных сборок v2, они сильно отличаются от копии в GAC. Все MSIL были удалены из них, они содержат только метаданные. И есть AnyCPU, поэтому больше никаких предупреждений. Инструмент, который использовался для их создания, интересен, к сожалению, Microsoft не делится им с нами.
Fwiw, явно нацеленный на x64, почти всегда не так. Это действительно имеет значение на сборке EXE, поскольку именно это определяет битту процесса. У сборника DLL нет выбора, подходящим для них является любой процессор, поэтому они могут работать в обоих направлениях. Редкое исключение состоит в том, что DLL имеет известную зависимость от неуправляемого компонента, как правило, COM-сервера. Такие компоненты обычно доступны только в виде 32-битных изображений, при попытке загрузить их в 64-разрядном режиме ( "Класс не зарегистрирован" ) вам сложно диагностировать сообщение об ошибке. Заставляя их нацеливаться на x86, вы получите еще один трудный диагностировать исключение, которое, возможно, немного легче для глаз, BadImageFormatException. Наличие зависимости от неуправляемого кода, доступного только в 64-битном коде, довольно редко, поэтому таргетинг на x64 не имеет особого смысла.