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

Я пытаюсь использовать систему проектов VS08SP1 по умолчанию для вызова компиляции С# в явном режиме 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>

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


warnings msbuild 64-bit csc mscorlib
person Ruben Bartelink    schedule 13.08.2009    source источник
comment
Я сталкиваюсь с той же проблемой. Было бы интересно решение. Спасибо.   -  person decasteljau    schedule 06.10.2009

Ответы (4)


arrow_upward
6
arrow_downward

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

person Todd H.    schedule 13.04.2011
comment
+1 Но переход на другую CLR и VS - это обман: P (Серьезно, спасибо, что нашли время ответить) - person Ruben Bartelink; 04.05.2011
comment
Наконец принимаю - хотя это не отвечает на настоящий вопрос, это решение, которое я фактически использовал, и я думаю, что это в значительной степени идиоматический «ответ» в этой экосистеме... - person Ruben Bartelink; 04.02.2012
comment
Это ни в коем случае не решение проблемы. Возможно, это сработало для вас, Тодд, но многие проекты нельзя просто изменить, чтобы они предназначались для другой среды. - person xxbbcc; 31.10.2012
comment
Не работает для меня. Я нацелился на .NET framework V4.0 и все еще получаю предупреждение. - person C Johnson; 30.10.2013
comment
Другая проблема с этим подходом заключается в том, что .NET 4 не всегда является решением. Мы создаем проект, который может быть развернут в средах нескольких клиентов, и мы не можем контролировать, есть ли у них 4 или нет. По нашему опыту, версия 4 также иногда вызывает проблемы с другим корпоративным программным обеспечением, поэтому для таких клиентов она может не подойти. - person Jay Imerman; 29.08.2014
comment
Этот ответ на аналогичный вопрос объясняет, почему возникает предупреждение и как .NET 4 устранила проблему. stackoverflow.com/a/4077901/54289 - person EnocNRoll - AnandaGopal Pardue; 04.03.2015

arrow_upward
9
arrow_downward

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

В файле проекта можно определить пользовательскую переменную в разделе 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, но до тех пор это будет работать. Я использую эту технику для ссылки на разные версии одних и тех же сборок в моих отладочных и выпускных сборках. Отлично работает!

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


Дополнительный интересный фрагмент из того же блог:

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

person Roland Pihlakas    schedule 03.02.2012
comment
+1 В моем сценарии мне эта техника на самом деле не нужна - я всегда хочу x64. Все еще оставляя вопрос непринятым - я хотел бы знать, что Microsoft порекомендует в качестве способа обработки встроенной ошибки (без необходимости терпеть их ужасное программное обеспечение для форума: P) - person Ruben Bartelink; 04.02.2012

arrow_upward
3
arrow_downward

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

person Peter T. LaComb Jr.    schedule 03.11.2010
comment
+1 проницательно (в первый раз я не был уверен). Я воздержусь от принятия, чтобы придерживаться моего привередливого рейтинга: P (Серьезно: мне интересно услышать о любых негативах моего второго подхода - вы могли бы подумать, что VS не будет выполнять его по умолчанию, если нет недостатков). Однако я думаю, что с точки зрения msbuild в этом есть смысл, и csc не следует встраивать всю эту политику непосредственно в инструмент. - person Ruben Bartelink; 05.11.2010
comment
Я не могу думать о каких-либо недостатках, если вы не компилируете на x86-сервере, который может не иметь сборки по этому пути. - person Peter T. LaComb Jr.; 05.11.2010
comment
что касается msbuild (действительно командная сборка), я бы предпочел запускать каждую сборку платформы на этой платформе. - person Peter T. LaComb Jr.; 05.11.2010

arrow_upward
1
arrow_downward

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

person Jay Imerman    schedule 29.08.2014