Программное обеспечение VB6, использующее веб-службы WCF. Конечные точки в App.config. Err VB6 не имеет App.config

У нас есть система EPOS, встроенная в VB6. Клиент использует Microsoft Dynamics AX в качестве CRM-системы. Сторонняя организация создала реализацию AX для нашего клиента и предоставила набор веб-служб WCF, которые нам необходимо использовать для синхронизации данных между EPOS и AX CRM. Зная, что VB6 будет иметь проблемы с вызовом служб WCF, я создал следующие компоненты для обработки связи между EPOS и AX CRM.

VB6 EPOS, который вызывает ->
1) VB6 DLL-оболочка, которая вызывает ... ->
2) .NET (3.5) COM Callable Proxy DLL-оболочка, которая вызывает ... ->
3 ) .NET (3.5) Обработчик веб-служб (где фактически вызываются веб-службы) ->
Microsoft Dynamics AX CRM.

Я создал тестовое консольное приложение на Vb.NET для имитации вызовов из VB6, чтобы помочь с отладкой, так что тестовое консольное приложение вызывает компонент 2.

При этом я получал следующее исключение: -

"(не удалось найти элемент конечной точки по умолчанию, который ссылается на контракт 'X' в разделе конфигурации клиента servicemodel. Это может быть связано с тем, что не был найден файл конфигурации для вашего приложения, или потому, что в клиентском элементе не удалось найти элемент конечной точки, соответствующий этому контракту. ) "

Я погуглил и обнаружил, что мне пришлось скопировать раздел привязок и конечных точек из app.config компонента 3 в новый app.config для моего приложения Test Console. Я не знаю WCF, и на данный момент у меня нет времени, чтобы по-настоящему изучить его до такой степени, чтобы я понял, почему это исправило эту ошибку.

Однако теперь я пытаюсь вызвать службы из VB6 EPOS, и эта ошибка появляется снова. Поэтому я добавил app.config к Компоненту 2, думая, что, поскольку Компонент 2 является первым компонентом .NET (3.5) в цепочке, именно туда и должно идти объявление конечной точки, но нет. Ошибка все еще появляется.

У кого-нибудь есть идеи? Любые герои-программисты, которые могут пролить свет на это для простака, пожалуйста ??? Пожалуйста, не спрашивайте, почему мы не переписываем EPOS. Мы будем. просто еще нет. Там более 3 миллионов строк спагетти-кода, а я работаю над этим всего 8 месяцев !!!

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


person psiberman    schedule 30.09.2011    source источник


Ответы (1)


Отличный вопрос ...

Ваша проблема, по сути, исходит из всех необходимых данных конфигурации, необходимых для работы со службой WCF.

При работе с .NET Windows или веб-приложениями данные конфигурации как на стороне клиента, так и на стороне сервера WCF Services находятся в файле конфигурации приложения. Для приложения Windows этот файл будет app.config, тогда как это будет web.config для веб-приложения.

В вашем случае вы хотели бы поместить логику прокси в некоторую форму COM-видимой .dll.

Это вас огорчит ... на платформе .NET файл .config для хост-приложения верхнего уровня (веб или Windows) - это место, где читаются все данные конфигурации. Даже если ваше приложение использует десятки сборок .NET (каждая из которых требует настраиваемой конфигурации), среда выполнения ожидает, что все эти элементы конфигурации будут находиться в самом верхнем файле конфигурации приложения.

Чтобы решить вашу проблему, вам нужно будет связаться со службой, к которой у VB6 есть доступ (подумайте о веб-службах ASMX), и попросите эту службу перенаправить ваш вызов в соответствующую службу WCF.

Другой альтернативой является передача переменных конфигурации непосредственно из вашего приложения VB6 в вашу Com-visible сборку, чтобы вы могли использовать модель расширяемости WCF для создания прокси (переопределяя поведение по умолчанию для чтения данных конфигурации из файла) с вашей переданной конфигурацией. .

Я бы сказал, что последний сценарий может идти в обоих направлениях, поскольку является нарушением SOA / OOP ... в зависимости от ситуации приложению VB6 может / может быть неуместно знать / хранить детали конфигурации для связи с ( в конечном итоге) конечная точка WCF

person fdfrye    schedule 30.09.2011
comment
Спасибо за это! Я рассмотрю ваши предложения. Должен сказать, однако, что моя точка зрения о нарушении правил ООП, тем не менее, остается в силе. Я не могу придумать причину, по которой в подобном сценарии ваш первоначальный вызывающий должен знать что-либо о компонентах на нескольких этапах вниз по цепочке. Может быть, это потому, что я не знаю WCF. Лучше научись побыстрее! - person psiberman; 30.09.2011
comment
Верно, я думаю, что в большинстве сценариев для первоначального вызывающего абонента нормально знать подробности о том, «как» вызывать службу WCF. Эти детали конфигурации, связанные с адресом, контрактом, привязкой, конечной точкой и т. Д., На самом деле являются просто фрагментами информации, описывающей, как достичь службы, а не совсем о том, что делает служба или как она это делает ... - person fdfrye; 30.09.2011
comment
Вы также можете создать файл MyVB6.exe.config (где MyVB6.exe - исполняемый файл VB6, который использует службу WCF), чтобы затем можно было найти информацию о конфигурации службы WCF. Я успешно делал это раньше. Кроме того, для отладки вы также можете создать файл VB6.exe.config, поскольку отладка происходит через исполняемый файл VB6.exe. HTH. - person fourpastmidnight; 06.11.2012