Переименование частей справочника службы

Question

Мне нужно получить доступ к службе на основе Java, которая определяет элемент portType в том же пространстве имен, которое используется одним из файлов схемы, которые он импортирует. К сожалению, эта схема включает complexType с тем же именем, что и portType!

Проблема заключается в том, что «Add Service Reference» использует имя portType создать имя контракта на оказание услуг, а также создает class с именем complexType - и он создает их в том же .NET пространство имен. Это не работает!

Есть ли что-то, что я могу сделать, либо в диалоговом окне «Добавить ссылку на службу», либо в файле .svcmap, чтобы «переименовать» тип контракта службы?

---

Тесно связан вопрос - есть ли то, что я мог сделать это, если portType и complexType были в разных пространствах имен (как, ИМХО, они должны быть)?

Answer 1

В Visual Studio вы можете выбрать свой проект в обозревателе решений, а сверху - небольшая коллекция значков. От правого наведения с помощью мыши над ними, и вы найдете один, который называется «Показать все файлы». Это покажет скрытые файлы, такие как классы, созданные ссылкой службы (теперь у вас должна быть стрелка для ее расширения).

У вас есть полный контроль над этими классами. Вы можете переименовать их, поместить их в другое пространство имен и т. Д.

Answer 2

Вы можете отредактировать созданные классы, как предлагает dustinmorris. Однако, если вам когда-либо понадобится обновить ссылку на службу, это становится проблематичным, поскольку оно будет восстанавливать эти классы.

Лучше было бы разбить их на 2 разных пространства имен, как вы предлагаете, это сработает.

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

Answer 3

Я думаю, что короткий ответ, к сожалению, «нет».

Можно ли даже удаленно попытаться убедить сопровождающих службы Java устранить неоднозначность со своего интерфейса? Если да, то я предложил бы лоббировать эти изменения столь же трудно, насколько это возможно, потому что остальная часть ваших вариантов не так уж велики:

Вы могли попробовать использовать ExcludedTypes элемент в .svcmap файл, чтобы заставить службу ссылка не генерирует complexType, которая конфликтует с portType. Если вам действительно нужно использовать этот complexType, вам нужно будет его реализовать вручную, что является обломком.

может вручную отредактировать файл Reference.cs, чтобы изменить имя одного из конфликтующих типов, как предложили другие. Но тогда всем, кто поддерживает код, нужно будет помнить о том, чтобы выполнять это ручное редактирование каждый раз, когда ссылка на службу регенерируется, что является обломком.

Вы могли играть с NamespaceMappings элемента в файле .svcmap, но это только позволяет переименовать все пространства имен, а не отдельные типы внутри этого пространства имен, который является облом.

Вы могли создать интерфейс контракта службы вручную (при условии, что это тот тип, который генерируется из portType), а затем использовать ServiceContractMappings элемент в .svcmap файл, чтобы использовать этот тип вместо автоматической генерации его , Но тогда, конечно, вам придется поддерживать этот интерфейс вручную, что является обломком. (Это, вероятно, лучший вариант, IMO, если вы не можете убедить обслуживающего персонала изменить свой сервис).