6

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

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

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

ответ

1

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

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

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

1

Мы нашли ответ, который немного отличался от того, что мы искали, но мне это нравится. Если добавить это в ваш конфигурационный файл под runtime-> 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.

Спасибо!

Смежные вопросы