2009-03-18 6 views
2

Конкретно:Могу ли я остановить отображение dll COM?

У нас есть веб-сервис (написанный на .Net), который использует большое количество COM-библиотек для основной бизнес-логики (написанной на VB6). Предположим теперь, что это запечатанные библиотеки.

К сожалению, многие из этих библиотек COM реализуют свои сообщения об ошибках или сообщениях проверки; если мы перейдем к неполным данным или если другая связь с COM отсутствует, они отобразят диалоговое окно. Эти диалоговые окна являются проблемой ... при работе в IIS эти сообщения помещают запрос, ожидая, пока пользователь нажмет ok в поле, которое невозможно увидеть.

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

ответ

2

С оговоркой, что я не сделал это лично, я считаю, перехватывать и перенаправлять вы хотите может быть достигнуто за счет Win32 Hooks

+0

Я думаю, что это лучшее решение, если он не хочет копать в COM-код DLL, но ему нужно больше работы! –

+0

Согласен, обновится сегодня вечером, когда у меня будет моя справочная библиотека. – cmsjr

+0

Наверное, не больше работы, на самом деле. Унаследованные DLL являются частью 10-летнего страхового приложения с отдельными Dll для каждой компании/даты рейтинга и региона. Там около 10 000 библиотек! – mdryden

2

Отображение форм наименьшей из ваших проблем, если они были написаны в VB6 быть используемый в настольном приложении. Эти COM-объекты, вероятно, не ожидают одновременного доступа к нескольким потокам. Это может взорваться очень эффектно или очень тонко.

Если руководство в зависимости от этого работает на 10 000 библиотек, то вам нужно понять, что нарушение допущений в 10 000 единиц десятилетнего кода не является хорошей идеей.

Если менеджмент достаточно взрослый (и в США), то напомните им о старых рекламных роликах о «Это не nice, чтобы обмануть мать-природу». Плохие вещи могут случиться.


Я думаю, мне нужно более подробно рассказать о «плохих вещах».

Я предполагаю, что это объекты VB6 COM, созданные для взаимодействия с приложением или приложениями форм VB6. Эти COM-объекты тогда могли бы разумно предположить, что к ним обращался только один поток, только один пользователь за один раз обращался к ним, и на самом деле только один поток и один пользователь обращались к ним в течение всего их жизненного цикла.

Как только вы запускаете их на сервере, вы нарушаете их предположения.

Кто может сказать, что это вызовет? Никто не будет делать этот анализ, потому что они были основными (и действительными) предположениями! Будет ли код, возможно, кэшировать что-то в потоковом локальном хранилище? Это сработало бы для первоначального сценария. Возможно, общие данные используются для кэширования информации. Он должен быть блокирован, если он будет использоваться несколькими потоками, и тогда вам будет нужно надеяться, что информация не будет изменяться для каждого пользователя, поскольку разные потоки могут выполняться от имени разных пользователей.

Однажды мне сказали, чтобы исправить утечку памяти. Короче говоря, это была не утечка памяти. Это был фрагмент устаревшего неуправляемого кода, который предполагал, что он работает в настольном или пакетном приложении. В веб-службе это извергало мусор по всей куче. Поэтому он выбрасывал исключения повсюду и заставлял другой, не связанный код делать то же самое. Неуправляемые исключения не приходят с подробностями, поэтому невозможно было понять, что вызвало проблему, или как ее решить.

В этом случае я смог просто установить блокировку для доступа. Это было достаточно хорошо, потому что этот код предполагал пакетную среду, а не интерактивную среду.Этого может быть недостаточно, если ваши COM-объекты делают предположения, что их десятилетние требования не изменились из-под них.

Если COM-объекты могут работать под единым идентификатором пользователя, это избавит вас от одного горя. Кроме того, вам просто нужно убедиться, что одновременно есть только один экземпляр данного объекта и что все его доступ к нему сериализуется. Для этого используйте инструкцию SyncLock для VB.NET.

Конечным решением было бы сделать «тестовый порт» кода. Я бы использовал существующую кодовую базу для создания автоматических модульных тестов (возможно, используя vbunit). После того, как кусок кода имеет достаточное пространство для тестирования, вы можете переносить этот код (все еще как объект COM) на VB.NET. Модульные тесты могут использоваться для подтверждения того, что порт все еще работает.

Такой порт может быть не таким жестким, как вы думаете. «Скопировать и вставить и исправить ошибки компилятора» достаточно хорошо работает между VB6 и VB.NET. Есть даже инструменты, чтобы помочь. Но это автоматические тесты, которые делают это практичным. В противном случае у вас будут разумные опасения относительно того, насколько хорошо порт был сделан.

Обратите внимание, что новые COM-объекты все еще должны использоваться исходным кодом VB6. На самом деле это должен быть тест.

Обратите также внимание на то, что это была бы хорошая возможность задокументировать переносимый код, так что это еще не проблема в течение еще десяти лет. Просто не теряйте документацию!

+0

О, как бы я хотел, это был вариант. Руководство не хочет выбрасывать годы рейтинговых правил, и я не в состоянии изменить свое мнение. Проблема с резьбой - это то, что меня очень беспокоит. – mdryden

+0

+1. Пронизывающий кошмар. Кстати, есть несколько вопросов о StackOverflow о конвертации VB6 в VB.NET с информацией о дополнительных ресурсах (включая ведущие инструменты). Вы можете перекрестно ссылаться на них. – MarkJ

+0

Спасибо, ребята. Вы оба не представляете, насколько близко вы находитесь на самом деле. На данный момент мне придется попытаться отключить этот огонь, но рано или поздно этот вариант, скорее всего, окажется единственным вариантом. Разве это не руководство? – mdryden

0

Ознакомьтесь с некоторыми статьями Джесси Каплана в журнале msdn. Его колонка называется CLR Inside Out. Найдите статьи COM Interop. Выпуски можно найти здесь: http://msdn.microsoft.com/en-us/magazine/cc159440.aspx

Редактировать: Похоже, г-н Каплан является лишь случайным участником этого раздела. Это по-прежнему отличный ресурс для связанных с Interop советов.

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