MSBUILD/csc: Самый чистый способ обращения с предупреждением x64 mscorlib 1607

Я пытаюсь использовать систему проектов по умолчанию VS08SP1 для вызова компиляции С# в явном режиме x64 (в отличие от AnyCpu). Когда я явно отмечаю модуль как x64, я получаю a:

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

Один способ удаления с помощью /nowarn:1607. Основываясь на моих исследованиях, на практике нет никаких проблем с этим. Если кто-то может рассказать о реальной проблеме, с которой они столкнулись, пожалуйста, не стесняйтесь отвечать.

Однако это просто неправильно! Таким образом, другой подход, который я использовал, заключался в том, чтобы сделать /nostdlib+, а затем добавить <Reference> с жестко закодированным <HintPath> к явно 64-битовому mscorlib:

<Reference Include="mscorlib">
  <HintPath>$(windir)\Microsoft.NET\Framework64\v2.0.50727\mscorlib.dll</HintPath>
</Reference>

Это работает и, вероятно, лучше (если кому-то не нужно указывать причины, почему предыдущий подход лучше), но может ли кто-то подтвердить, что это подходящая вещь, надеюсь, ссылаясь на что-то авторитарное?

Ответы

Ответ 1

Я обнаружил, изменив проект Target Framework на .NET Framework 4, он исключил предупреждение.

Ответ 2

В этом блоге я нашел предложение, которое слишком длинное, чтобы скопировать его полностью здесь, но вкратце идея может быть описана с помощью резюме, адаптированное из этот комментарий:

В файле проекта вы можете определить пользовательскую переменную в разделе PropertyGroup для каждой конфигурации сборки. Пример:

<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release|x64'">
    <MyCustomPath>C:\Windows\Microsoft.NET\Framework64</MyCustomPath>
</PropertyGroup>

Просто добавьте тег, например

<Reference Include="System.Data">
    <HintPath>$(MyCustomPath)</HintPath> 
</Reference>

а затем используйте макрос для определения ссылочного пути. Вы можете определить MyCustomPath в другом месте для разных конфигураций сборки (платформа и/или отладка/выпуск).
Проблема не будет существовать, если MS поддержит это в VS UI, но до тех пор это будет работать. Я использую эту технику для ссылки на разные версии одних и тех же сборок в своих отладочных и релизных сборках. Отлично работает!

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

Еще один интересный фрагмент из тот же блог:

Есть несколько других способов сделать это, но они также требуют ручной редактирования файлов проекта. Один из способов - указать условия для разделов PropertyGroup. Этот вопрос fooobar.com/questions/190092/... подчеркивает использование условий.

Ответ 3

Я считаю, что ваш второй вариант (явная ссылка с /nostdlib+) лучше, потому что он не будет подавлять это предупреждение, если вы должны ссылаться на другие сборки, не созданные на той же платформе.

Ответ 4

В моем случае у меня было это предупреждение, потому что в моем решении было реализовано сочетание проектов x86 и x64. Если я создам конфигурации сборки x86 во всех моих проектах и настрою их на сборку, предупреждения исчезнут. Однако, если бы я хотел настроить таргетинг на x64, я бы подумал, что мне придется перестроить проект (или следовать совету выше), чтобы переработать их для платформы x64.