Усунення неполадок взаємодії (Visual Basic), Microsoft Docs
При взаємодії між COM і керованим кодом .NET Framework можна зіткнутися з типовими питаннями, які розглядаються в наступних розділах:
Маршалінг взаємодії
Іноді виникає потреба у використанні типів даних, які не входять до складу .NET Framework. Складання взаємодії виконують більшу частину роботи з об'єктами COM, але може виникнути необхідність керування типами даних, що використовуються, коли керовані об'єкти надаються COM. Наприклад, структури в бібліотеках класу повинні задати некерований тип BStr для рядків, що відправляються в об'єкти COM, створені Visual Basic 6.0 та попередніми версіями. У таких випадках можна використовувати атрибут MarshalAsAtribute, щоб керовані типи надавалися як некеровані.
Експорт рядків фіксованої довжини до некерованого коду
У Visual Basic 6.0 і раніше версіях рядки експортувалися в об'єкти COM як послідовності байтів без порожнього завершального знака. Для сумісності з іншими мовами Visual Basic 2005 під час експорту рядків включено завершальний знак. Найкращий спосіб вирішити проблему несумісності - це експортувати рядки без завершального знака як масиви типу Byte або Char.
Експорт ієрархій успадкування
Ієрархії керованого класу вирівнюються при поданні їх як об'єктів COM. Наприклад, якщо визначити базовий клас за допомогою елемента, а потім успадкувати базовий клас у похідному класі, який надається як об'єкт COM, клієнти, які використовують похідний клас в об'єкті COM, не зможуть використовувати успадковані елементи. Елементи базового класу доступні з об'єктів COM тільки як екземпляри базового класу і лише за умови, що базовий клас також створений якоб'єкт COM.
Перевантажені методи
Хоча можна створити перевантажені методи за допомогою Visual Basic, вони не підтримуються COM. Коли клас, що містить перевантажені методи, виставлений як об'єкт COM, нові імена методів створюються для перевантажених методів.
Наприклад, розглянемо клас, що має два навантаження методу Synch. Коли клас виставлений як об'єкт COM, нові створені імена методів можуть бути Synch та Synch_2.
Перейменування може викликати дві проблеми для споживачів об'єкта COM.
Клієнти можуть очікувати створених імен методів.
Створені імена методів у класі, виставленому як об'єкт COM, можна змінити при додаванні нових перевантажень до класу або його базового класу. Це може спричинити проблеми керування версіями.
Для вирішення обох проблем при розробці об'єктів, які будуть надані у вигляді об'єктів COM, надайте кожному методу унікальне ім'я замість використання навантаження.
Використання об'єктів COM у зборках взаємодії
Складання взаємодії використовуються майже так само, як коли б вони були керованим кодом, що замінює об'єкти COM, які вони представляють. Тим не менш, оскільки вони є обгортками, а не справжніми об'єктами COM, є деякі відмінності у використанні складання взаємодії і звичайних складання. Ці відмінності стосуються надання класів, а також типів даних параметрів та значень, що повертаються.
Класи, що надаються як інтерфейси, і як класи
На відміну від класів у звичайних збірках класи COM представлені у збірках взаємодії як інтерфейси, і як класи, що представляють клас COM. Ім'я інтерфейсу збігається із ім'ям класу COM. Ім'я класу взаємодії те саме, що й ім'я вихідного класу COM, але з доданим у кінці словом "Class".Припустимо, що є проект із посиланням на складання взаємодії для об'єкта COM. Якщо COM-клас названий MyComClass, IntelliSense та браузер об'єктів будуть показувати інтерфейс з ім'ям MyComClass і клас з ім'ям MyComClassClass.
Створення екземплярів класу .NET Framework
Як правило, екземпляр класу .NET Framework створюється за допомогою інструкції New з ім'ям класу. Наявність класу COM, представленого складання взаємодії, - це той випадок, коли можна використовувати оператор New з інтерфейсом. Поки не використовується COM-клас з інструкцією Inherits, можна використовувати інтерфейс так само, як і клас. У наступному коді показано, як створити об'єкт Command у проекті, який має посилання на об'єкт COM бібліотеки Microsoft ActiveX Data Objects 2.8:
Проте, якщо клас COM використовується як основа для похідного класу, слід використовувати клас взаємодії, який представляє клас COM, наприклад:
Складання взаємодії неявно реалізують інтерфейси, що представляють класи COM. Не слід використовувати оператор Implements для цих інтерфейсів: результатом такої спроби буде помилка.
Типи даних параметрів і значень, що повертаються
Методи COM рівня модуля
Більшість об'єктів COM використовуються шляхом створення екземпляра COM за допомогою ключового слова New з подальшим викликанням методів об'єкта. Один виняток із цього правила включає COM-об'єкти, що містять COM-класи AppObj або GlobalMultiUse. Такі класи нагадують методи рівня модуля в класах Visual Basic 2005. У Visual Basic 6.0 і попередніх версіях неявно створюються екземпляри таких об'єктів при першому виклику одного з їх методів. Наприклад, у Visual Basic 6.0 можна додати посилання на Microsoft DAO 3.6 Object Library та викликати метод DBEngineбез попереднього створення примірника:
Visual Basic 2005 вимагає, щоб екземпляри об'єктів COM завжди створювалися до їх методів. Щоб використати ці методи у Visual Basic 2005, оголосіть змінну потрібного класу і за допомогою ключового слова "new" призначте об'єкт для змінної об'єкта. Ключове слово Shared можна використовувати, коли потрібно переконатися, що створено лише один екземпляр класу.
Необроблені помилки в обробниках подій
Цей приклад, як і передбачалося, викликає виняток. Однак, при використанні того ж прикладу без блоку Try. Catch. Finally, помилка не обробляється, ніби використовувалася інструкція OnError Resume Next. Без обробки помилок поділ на нуль викликає неявну помилку. Оскільки такі помилки ніколи не викликають помилку необробленого виключення, дуже важливо використовувати ту чи іншу форму обробки винятків у обробниках подій для об'єктів COM.
Загальні відомості про помилки взаємодії COM
Без обробки помилок виклики взаємодії часто створюють помилки, які мають мало корисної інформації. По можливості слід використовувати структуровану обробку помилок, щоб отримувати докладніші відомості про їх характер. Це може бути особливо корисним при налагодженні програм. приклади.
Перевірка вмісту об'єкта виключення дає такі відомості, як опис помилки, HRESULT та джерело помилок COM.
Питання, пов'язані з елементами керування ActiveX
Більшість елементів керування ActiveX, що працюють у Visual Basic 6.0, працюють і в Visual Basic 2005. Більшість винятків — це контейнерні елементи керування, тобто елементи керування, які візуально містять інші елементи керування. Нижче наведено деякі приклади старих елементівкерування, які не працюють коректно з Visual Studio.
Елемент управління Frame із Microsoft Forms 2.0
Елемент керування Up-Down, званий також елементом керування обертанням
Елемент управління Sheridan Tab
Способів обійти проблеми з елементами керування ActiveX, що не підтримуються, мало. Якщо у вас є вихідний код, можна виконати міграцію існуючих елементів керування Visual Studio. Інший варіант — запитати постачальників програми оновлені версії елементів керування, сумісні з .NET, для заміни непідтримуваних елементів керування ActiveX.
Передача ByRef властивостей ReadOnly елементів керування
Visual Basic 2005 іноді викликає помилки COM, такі як "Помилка 0x800A017F CTL_E_SETNOTSUPPORTED", коли ви передаєте властивості ReadOnly деяких старих елементів керування ActiveX як параметри ByRef в інші процедури. Така ж процедура, викликана Visual Basic 6.0, не викликає помилки, і параметри обробляються так, якби вони передавалися за значенням. Повідомлення про помилку у Visual Basic 2005 є COM-об'єктом звітності від того, що ви намагаєтеся змінити властивість, яка не має процедури властивості Set.
За наявності доступу до процедури, що викликається, можна запобігти цій помилці, оголосивши з ключового слова ByVal параметри, які підтримують властивості ReadOnly. приклади.
Розгортання збірок, що надають взаємодію
З розгортанням збірок, які надають COM, пов'язані особливі проблеми. Наприклад, проблема може виникнути тоді, коли різні програми посилаються на ту саму збірку COM. Ця ситуація звичайна, коли встановлено нову версію збірки, а інша програма все ще використовує попередню версію. Наслідком видалення будь-якої збирання,містить бібліотеку DLL, яка спільно використовується, може виявитися недоступністю цієї бібліотеки.
Щоб уникнути цієї проблеми, слід встановлювати спільно використовувані збірки у глобальний кеш збірок (GAC) і використовувати MergeModule для цього компонента. Якщо неможливо встановити програму у глобальний кеш збірок, тоді її слід встановити в CommonFilesFolder у пов'язану з версією вкладену папку.
Складки, які не використовуються спільно, повинні бути розміщені в одній папці з додатком, що викликає.