Существуют ли какие-либо инструменты для создания прокси ASMX из сборок на стороне сервера?

Question

У нас есть набор сборок, которые реализуют операции веб-сервисов.

Чтобы создать клиентские прокси-серверы, мы сначала строим и разворачиваем веб-сервисы (сборки и файлы ASMX) на сервере.

Затем мы используем wsdl.exe, чтобы указать на конечные точки ASMX и сгенерировать классы для клиентских прокси.

Я видел, что можно создавать прокси из файлов wsdl (вместо конечных точек asmx), используя wsdl.exe или disco.exe.

---

Существует ли инструмент для создания файлов wsdl или прокси-классов непосредственно из сборок сервера без необходимости использования веб-сервера?

---

UPDATE:

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

1) Это довольно большой проект, который разрабатывается уже более двух лет. Решение использовать веб-сервисы ASMX было принято до появления WCF.

2) Я уже думал о написании нашего собственного прокси-генератора, и это может быть вариантом, если мы не найдем инструмент, который это делает.

3) Мы все еще хотим связать контракт с WSDL. Чего я пытаюсь избежать, так это зависимости от веб-сервера в процессе сборки.

4) Мы уже автоматически генерируем прокси в нашей автоматической сборке, которая выполняется в TFS Build и которая сама по себе не была проблемой. Проблема, как мне сказали, состоит в том, что нужно разделить сборку на две части: сервер и клиент. Могут быть альтернативы, чтобы избежать разделения, используя какую-то необычную задачу MSBUILD, но мои знания по этому вопросу ограничены.

5) Я ожидаю, что сборка будет тормозить при сборке TFS, если код на стороне клиента и код на стороне сервера не совпадают во время компиляции. Это должно быть решено на компьютере разработчика до регистрации.

6) У нас строгий контроль над серверной и клиентской частями. Этот набор веб-сервисов служит в качестве серверной части приложения Windows Forms Click Once. Все работает в интранете. Каждый раз, когда меняется контракт, он выполняется вместе с новой версией клиентского приложения.

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

Answer 1

Ну, и классические веб-сервисы ASMX, и современные сервисы WCF имеют возможность автоматически генерировать WSDL для вас. Если вы перейдете по URL-адресу конечной точки веб-службы, вы можете получить WSDL, просто добавив? WSDL в конец URL-адреса. Как правило, вы не хотите создавать прокси-серверы из кода самой службы ... цель веб-служб заключается в том, чтобы отделить вас от реализации и позволить вам связывать контракт (что и есть WSDL ... контракт). Вы можете создавать клиентские прокси несколькими способами ... либо с помощью wsdl.exe, svcutil.exe, либо с помощью опций «Добавить веб-ссылку» или «Добавить ссылку на службу» в Visual Studio.

Если вам действительно нужно, вы можете написать собственный генератор прокси. Недавно я написал динамический генератор прокси, который позволял генерировать прокси сервисов WCF во время выполнения с помощью облегченной генерации кода (ILEmit) через контейнер Castle Windsor IOC. Существует множество вариантов, но ключ заключается в том, что вы привязываетесь к WSDL (ваш контракт), а не к реальному коду C # сервиса. Наиболее идеальным вариантом будет написание WSDL и генерация прокси-клиентов и интерфейсов контрактов на обслуживание, а также контрактов данных / сообщений из WSDL. Это называется разработкой службы по контракту, и есть несколько продуктов для .NET, которые позволяют разработку по контракту.

EDIT:

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

Пример сценария. Предположим, у вас есть IServiceA, который имеет единственный метод, который принимает контракт данных в качестве параметра и возвращает другой контракт данных в результате:

[ServiceContract]
public interface IServiceA
{
    [OperationContract]
    SecureOutput SomeSecureOperation(SecureInput input);
}

public class SecureInput
{
    public UserCredentials Credentials { get; set; }
    public byte[] EncryptedData { get; set; }
}

public class SecureOutput
{
    public byte[] EncryptedData { get; set; }
}

Допустим, что вышеупомянутый сервис использует синхронное шифрование для шифрования и дешифрования данных, но позже он считается небезопасным. Таким образом, вы измените данные контрактов:

[ServiceContract]
public interface IServiceA
{
    [OperationContract]
    SecureOutput SomeSecureOperation(SecureInput input);

    [OperationContract]
    byte[] GetPublicKey();
}

public class SecureInput
{
    public UserCredentials Credentials { get; set; }
    public byte[] UserPublicKey { get; set; }
    public byte[] EncryptedData { get; set; }
}

public class SecureOutput
{
    public byte[] EncryptedData { get; set; }
}

Сервис теперь использует асинхронное шифрование и использует открытый ключ пользователя для шифрования возвращаемых данных. У службы также есть новая операция, позволяющая клиентам получать открытый ключ службы, чтобы они могли шифровать входные данные. контракт вашего сервиса изменился и требует обновления клиентского кода. Вы должны версии своего сервиса ... однако мы имеем дело с безопасностью, и старый должен быть заменен в пользу нового для поддержания безопасности. Если вы автоматически сгенерируете прокси-серверы своих клиентов в время сборки , у вас возникнут серьезные проблемы. Ваш клиентский код больше не совместим с новым прокси, и ваша сборка не удалась.

При работе с веб-службами лучше всего обрабатывать создание прокси вручную. Если прокси-сервер необходимо регенерировать (что, если вы правильно версируете свои сервисы, должно быть редким после заключения контракта), то вы не можете просто генерировать, не нарушая что-либо. Вам нужно будет сгенерировать прокси, а затем обновить все, что его использует, чтобы соответствовать новому интерфейсу. Я не могу вспомнить ни одного сценария, в котором я хотел бы генерировать свои прокси во время сборки, и при этом я не хотел бы регенерировать свой прокси-сервер каждую сборку. Я не могу рекомендовать такой сценарий никому. Я прошу прощения за то, что не ответил непосредственно на ваш вопрос, но я надеюсь, что мое объяснение поможет вам найти лучшее решение.

Answer 2

Я создал инструмент, который может генерировать файл WSDL из скомпилированной сборки c # (dll), которая содержит одно или несколько WebServices. Обычно вам требуется работающая служба (IIS или другая), в которой находится .asmx, чтобы вы могли получить WSDL с помощью /MyWebService.asmx?wsdl

.

Этот инструмент создает файл WSDL, используя отражение для извлечения всей информации из сборки (dll).

Скачать можно по адресу http://wsdlgenerator.codeplex.com

Answer 3

Вы можете использовать ServiceDescriptionReflector для создания файла WSDL из сборки.

См. Это руководство: http://www.pluralsight.com/community/blogs/craig/archive/2004/10/18/2877.aspx

EDIT:

После генерации WSDL с помощью ServiceDescriptionReflector вы можете использовать инструмент WSDL.exe для генерации прокси-классов.

Answer 4

Нет способа сделать это с помощью веб-сервисов ASMX.

Однако, поскольку Microsoft говорит: веб-службы ASMX - это «устаревшая технология» , сейчас самое время подумать о Миграции веб-служб ASP.NET в WCF .

Причина в том, что svcutil.exe может экспортировать метаданные из скомпилированных сборок, которые затем вы сможете развернуть и использовать для создания прокси-кода, также используя svcutil.exe.

Я согласен с ответом jrista : прокси-код является одним из видов сгенерированного кода, и я не верю, что он должен генерироваться во время сборки. Он должен быть сгенерирован разработчиком и фактически должен быть проверен в системе контроля версий.