wsdl.exe/svcutil.exe - есть ли способ не генерировать классы для типов в xsds во время клиентского поколения или веб-сервиса

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

Возможная причина: Движок регекса должен сильно отследить, если он не жадный.

Я считаю, что вы ищете: svcutil.exe/r your-dtos.dll

/reference: - Типы ссылок в указанном сборка. При создании клиентов используйте эта опция используется для указания сборок, которые может содержать типы, представляющие импортируемые метаданные. (Краткое описание: / r)

По моему мнению, тесная связь прокси-сервера WCF, канала конечной точки, операций обслуживания и полезных нагрузок dto с одним и тем же сгенерированным прокси-сервером клиента является серьезным недостатком конструкции.

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

• Один и тот же клиент веб-службы (то есть Soap11, Soap12, XML, JSON) иметь возможность вызывать любую веб-службу.
• Это позволяет мне также использовать один и тот же экземпляр DataContract dto в любом из клиентов веб-служб
• Это имеет много преимуществ, включая быть возможность предоставлять одну и ту же веб-службу на нескольких различных конечных точках без дополнительной конфигурации. Таким образом обеспечивая оптимизированные конечные точки веб-сервиса для каждого потребителя моей услуги. Например.
  • XML для клиентов с высокой функциональностью и строгим типом,
  • JSON для клиентов Ajax,
  • WSDL для сред, предпочитающих сгенерированный код (например, Flex Builder, VS.NET 'Add Service Reference' и т.д.)

В моей компании мы разработали сотни веб-сервисов, вызываемых различными клиентами, например Ajax, Flash/ActionScript, C++, Silverlight, ASP.NET, и возможность звонить на одну и ту же веб-службу через различные конечные точки сэкономила нам бесчисленное количество часов.

Я не знаю какой-либо конкретной настройки или переключателя командной строки, чтобы обеспечить это - что вы можете сделать, но это в основном вопрос обучения и обеспечения соблюдения проверка, заключается в том, чтобы поделиться библиотекой классов (сборкой в ​​DLL) с разработчиками и убедиться, что все ссылаются на эту общую библиотеку классов и оставляют настройки по умолчанию в диалоговом окне «Добавить ссылку на службу» (на странице «Дополнительно» ):

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

Но опять же - это всего лишь подход типа «управление примером и проверка» - я не знаю какого-либо технического способа обеспечить это.

Если вы удалите конечную точку mex из файла конфигурации службы, клиентское приложение не сможет обнаружить и сгенерировать прокси-объекты.

Один из способов справиться с этой ситуацией, если я правильно понял ваш вопрос, - это сделать следующее:

1. Создать общий набор библиотек DLL, в которых есть служба, контракты данных / общая объектная модель.
2. Создайте службу, используя контракты в общей dll вместо контрактов, которые Visual Studio создает при создании новой службы.
3. Удалите конечную точку MEX из файла конфигурации сервера (это существенно нарушит создание прокси).
4. Пусть ваш клиент использует общую dll и вручную создает каналы на стороне клиента (через фабрику каналов и т. Д.).

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

РЕДАКТИРОВАТЬ: Следуя этому подходу, клиент все еще может попытаться сгенерировать прокси-объекты через wsdl.exe / svcutil.exe, но он не получит правильную информацию из wsdl. По сути, они сгенерируют нефункционирующий / неполный прокси.