Как написать код C #, безопасный как под x86, так и под x64 при доступе к COM? Типичные ловушки? - PullRequest
3 голосов
/ 11 марта 2010

Мы используем библиотеку с открытым исходным кодом, написанную на C #, обертывающую Windows BITS COM компонент. Тем не менее, код безопасен только для запуска в режиме x86. Я хотел бы внести свой вклад в библиотеку, сделав ее безопасной как для x86, так и для x64, однако я не обладаю глубокими знаниями в этой области.

Не могли бы вы перечислить здесь хорошие / плохие практики, типичные проблемы, может быть, также принципы и т. Д., На что следует обратить внимание?

Например, я видел в коде IntPtr приведение к System.Int32, что плохо на x64. Как бы вы решали эту и подобные проблемы независимо от платформы?

Ответы [ 2 ]

2 голосов
/ 11 марта 2010

Я думаю, вы говорите о SharpBits.NET , обертке для компонента BITS. Да, есть несколько мест, где автор возился с взаимодействием. В противном случае нет никаких причин, по которым он не может работать, BITS доступен как 32-битный и 64-битный COM-сервер Один из примеров такого беспорядка в этой теме .

Неправильное или некорректное маршалирование объявления P / Invoke является подавляющим большинством всех 64-битных проблем взаимодействия. Я оставил много подсказок о проблемах 64-битного кодирования в этой теме .

1 голос
/ 11 марта 2010

Хм, вы не;)

Серьезно.

Проблема заключается в том, что 64-битные и 32-битные com-объекты не совместимы, поэтому вам определенно понадобится либо ленивая настройка загрузки без привязки stron (и тогда мы не будем говорить о COM, но COM с IDispatch), либо две разные сборки wrapepr. *

В целом x86 / x64 - ЗНАЧИТЕЛЬНЫЙ пробел, потому что его очень трудно преодолеть. Например, вы НЕ МОЖЕТЕ загружать 32-битную DLL в 64-битный процесс - независимо от того, упаковщик он или нет, вы просто не можете его загрузить.

MS разработала его таким образом, специально. Как таковой - нет никакого способа обойти это.

...