Условные ссылки

В настоящее время наш код .net не зависит от процессора, но зависит от библиотек (Oracle/ODP.Net). Мы нашли решение, в котором мы редактируем файл csproj напрямую и помещаем ссылки в группы элементов с предложением Condition на основе выбранной нами конфигурации сборки. У нас есть 32-битная отладка/выпуск и 64-битная отладка/выпуск, и правильные сборки являются ссылками при создании этой конфигурации.

Это более-менее работает во время сборки, но вызывает всевозможные странности в Visual Studio (2008). Конечным результатом является то, что одна и та же сборка отображается четыре раза в ссылках, и три из них отмечены желтым восклицательным знаком. Он также генерирует около 76 предупреждений, от которых я не могу избавиться. Мы пытаемся стремиться к 0 предупреждений, потому что мы хотим знать, когда появляются новые, так что это немного проблематично.

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


reference c# conditional-compilation visual-studio-2008
person Community    schedule 12.05.2009    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Единственное, что приходит на ум, это иметь 4 отдельных файла проекта... но прежде чем вы начнете паниковать из-за необходимости поддерживать 4 файла при добавлении класса, вы можете использовать здесь еще один прием csproj:

<Compile Include="**\*.cs" />

который (IIRC) говорит: «включить все файлы cs на любом уровне в структуру папок».

person Marc Gravell    schedule 12.05.2009

arrow_upward
1
arrow_downward

Мы нашли ответ, который немного отличался от того, что мы искали, но мне он вроде как нравится. Если вы добавите это в свой файл конфигурации во время выполнения->AssemblyBinding

<dependentAssembly>
<assemblyIdentity name="Oracle.DataAccess" publicKeyToken="89b483f429c47342"  />
<bindingRedirect oldVersion="2.111.6.20" newVersion="2.111.6.0" />
</dependentAssembly>

Тогда 64-битная и 32-битная версии работают с одной и той же сборкой. Все, что нам нужно сделать, это не копировать Oracle.DataAccess.dll локально при развертывании и позволить ей получить ее из GAC.

Спасибо!

person Community    schedule 19.05.2009