Запретить использование конструктора по умолчанию в сгенерированном прокси веб-сервиса - PullRequest
2 голосов
/ 28 декабря 2010

У меня есть ситуация, когда у меня есть несколько веб-сервисов, которые мне нужно использовать. Мне нужна возможность выполнять пользовательские действия в конструкторе прокси-сервера перед выполнением любых вызовов (назначение настроенного URL-адреса, назначение заголовка SOAP и т. Д.).

Мое первое решение - создать дочерний класс, производный от сгенерированного прокси, а затем выполнить эти действия в конструкторе дочернего класса. Таким образом, код приложения может вызвать конструктор дочернего элемента и получить действительный прокси-сервер, в котором есть все, что мне нужно.

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

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

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

Кажется, что единственный способ получить все, что я хочу, это удалить открытый конструктор сгенерированного прокси и заменить его защищенным конструктором, а затем разрешить ссылку на эту сборку - они смогут работать с сложные типы, но не сможет вызвать конструктор. Моя проблема в том, что единственный способ, которым я могу придумать, это манипулировать сгенерированным кодом для изменения конструктора.

Есть идеи? Я использую WSDL.exe для генерации прокси, и там нет возможности скрыть конструктор. Есть ли другой способ, который я просто скучаю? Я полагаю, что могу написать инструмент для автоматической модификации прокси сразу после его генерации, но мне это просто ужасно.

Спасибо

Ответы [ 3 ]

2 голосов
/ 28 декабря 2010

Вы застряли с помощью .NET 2.0? Если нет, то вы не должны использовать WSDL.EXE. Вы должны использовать SVCUTIL.EXE или «Добавить ссылку на сервис».

Вместо создания производного класса вы должны создать свои собственные классы-обертки, которые используют прокси-классы. Можно использовать что-то вроде MyWrapper.CreateProxy(), что вернет правильно настроенный экземпляр прокси-класса.

Кстати, WSDL.EXE создает прокси, используя устаревшую технологию "ASMX", которая не может использовать типы из службы.

0 голосов
/ 02 января 2011

Я закончил тем, что изменил код, сгенерированный прокси, чтобы сделать конструктор защищенным, а не общедоступным.Вызов WSDL.exe уже был обработан в автоматизированном проекте, так что это было не так уж сложно.Это был единственный способ получить все, что хотел.

0 голосов
/ 28 декабря 2010

Вместо этого, почему вы не можете переопределить метод GetWebRequest? В любом случае он будет вызван до вызова сервисного метода.

Если вы добавили ссылку на службу, то инспектор сообщений будет делать то же самое.

...