Длина указателя сборки взаимодействия

Почему Visual Studio иногда превращает ОДИНАКОВЫЕ параметры указателя в COM-библиотеках в uint, а иногда в ulong? У меня есть COM-библиотека, в которой есть несколько методов с такими параметрами, как

[ in ] ULONG_PTR ParentWindow

Когда я обращаюсь к этой библиотеке на своем настольном компьютере, сборка взаимодействия превращает ULONG_PTR в uint. Когда я делаю то же самое на своем ноутбуке, он превращается в ulong. Это вызывает проблемы при совместном использовании проекта между машинами. Я, вероятно, мог бы хранить сборку Interop в SVN вместе с остальной частью проекта, но это вызывает проблемы, если мне когда-нибудь понадобится ее повторно сгенерировать, например, после обновления библиотеки COM.

Системы:

Desktop                                Laptop
- Windows Vista Professional 64-bit    - Windows 7 Ultimate 64-bit
- Visual Studio 2008 Professional      - Visual Studio 2008 Team System
  (SP1)                                  Development Edition (SP1)
- .Net Framework 3.5 SP1               - .Net Framework 3.5 SP1

UAC включен, а Visual Studio запущена от имени администратора.

Я попробую применить Visual Studio 2008 SP1 на ноутбуке, если это повлияет.

Изменить: применил SP1 на ноутбуке безрезультатно.

Обновление:

При добавлении ссылки на библиотеку COM в Visual Studio Process Monitor показывает, что devenv читает COMLibrary.dll на настольном компьютере, в то время как он читает COMLibrary64.dll на ноутбуке. Это определенно является причиной того, что рабочий стол показывает uint для указателей, а ноутбук показывает ulong.

Теперь, почему он делает это? Процесс Devenv на обоих компах запущен под WoW64.

При запуске программа использует COMLibrary64.dll на обоих компьютерах согласно Process Monitor. Таким образом, проблема кажется только во время добавления ссылки.

Далее постараюсь выполнить генерацию взаимодействия вручную.


person Mikko Rantanen    schedule 05.12.2009    source источник


Ответы (1)


Это точно один и тот же COM-сервер, а не 32- и 64-битные версии? То, что вы описываете, имеет все признаки таргетинга на разные разрядности, как вы, вероятно, знаете - ULONG_PTR составляет 32 бита в 32-битных целях компиляции и 64 бита в 64-битных целях компиляции, но собственный код должен быть либо одним, либо другим во время компиляции. .

Условный «правильный» перевод будет UIntPtr, но он будет плавать в зависимости от того, в какой среде работает клиентский процесс .NET, а не от того, что требуется, от разрядности COM-сервера.

person Barry Kelly    schedule 06.12.2009
comment
Да, это определенно похоже на разницу между 32-битной и 64-битной версиями. Немного обновил исходный пост, теперь, когда я понял, как это подтвердить. До сих пор не понимаю, почему разница. - person Mikko Rantanen; 06.12.2009
comment
О, и я думаю, что (U)IntPtr будет правильным в любом случае. Эти параметры в основном являются дескрипторами окон, и, по крайней мере, элементы управления WinForms предоставляют свойство Handle как IntPtr. Теперь мне просто нужно выяснить, как сказать это tlbimp. - person Mikko Rantanen; 06.12.2009
comment
COM является двоичным стандартом. COM-интерфейс не может плавать между 32-битной и 64-битной версиями в зависимости от того, какая платформа .NET использовалась для его выполнения, но код .NET будет. Вы должны использовать U/IntPtr только в том случае, если ваш исполняемый файл привязан к одному или другому (то есть не к AnyCPU). - person Barry Kelly; 06.12.2009
comment
Гум. Немного запоздалый ответ, имел дискуссию с разработчиками библиотеки COM - у них есть две версии библиотеки COM: 32-битная и 64-битная. Их 32-разрядный установщик отказывается устанавливаться на 64-разрядную машину, а 64-разрядный установщик устанавливает обе версии библиотеки COM. Это приводит к тому, что 32-разрядная ОС и 32-разрядные процессы, работающие под WoW64, всегда обращаются к 32-разрядной библиотеке COM, в то время как 64-разрядные процессы всегда используют 64-разрядную библиотеку COM. Разве это не приводит к длине плавающего указателя с точки зрения .Net? - person Mikko Rantanen; 08.12.2009