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

StackOverflow https://stackoverflow.com/questions/1272733

Вопрос

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

предупреждение 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>

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

Это было полезно?

Решение

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

Другие советы

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

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

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

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

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

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

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


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

Есть и другие способы сделать это, но они также требуют ручного редактирования файлов проекта.Один из способов — указать условия для разделов PropertyGroup.Этот Переполнение стека Вопрос подчеркивает использование условий.

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top