У меня была такая же проблема, поэтому я написал рубиновый камень под названием Twig . В нем перечислены ветви в хронологическом порядке (сначала самые новые), а также можно указать максимальный возраст, чтобы вы не перечисляли все ветви (если их много). Например:
$ twig
issue status todo branch
----- ------ ---- ------
2013-01-26 18:00:21 (7m ago) 486 In progress Rebase optimize-all-the-things
2013-01-26 16:49:21 (2h ago) 268 In progress - whitespace-all-the-things
2013-01-23 18:35:21 (3d ago) 159 Shipped Test in prod * refactor-all-the-things
2013-01-22 17:12:09 (4d ago) - - - development
2013-01-20 19:45:42 (6d ago) - - - master
Он также позволяет хранить пользовательские свойства для каждой ветви, например, идентификатор заявки, статус, задачи и фильтровать список ветвей в соответствии с этими свойствами. Дополнительная информация: http://rondevera.github.io/twig/
.
Нашел решение. Он состоит из нескольких частей и требует нескольких изменений на стороне C #, в большей степени на стороне Delphi. Обратите внимание, что это было протестировано с Delphi 2007 и Visual Studio 2008.
Сторона C #: Используйте BasicHttpBinding вместо WSHttpBinding.
Шаг исправления 1
BasicHttpBinding myBinding = new BasicHttpBinding();
myBinding.Security.Mode = BasicHttpSecurityMode.None;
Это изменение устранит ошибки application / soap + xml на стороне Delphi.
Сторона Delphi 2007: Запуск с измененной веб-службой C # теперь будет генерировать такие ошибки:
Exception class ERemotableException с сообщением 'Сообщение с действием '' не могут быть обработаны на получатель, из-за ContractFilter несоответствие в EndpointDispatcher. Это может быть из-за несоответствие контракта (несоответствие действий между отправителем и получателем) или несоответствие привязки / безопасности между отправитель и получатель. Проверь это отправитель и получатель одинаковы договор и такая же привязка (включая требования безопасности, например Сообщение, Транспорт, Нет). '
Чтобы решить эту проблему, добавьте SOAPActions ко всем поддерживаемым интерфейсам. Вот пример из моего кода; это должно быть выполнено ПОСЛЕ всех изменений InvRegistry, сделанных секцией инициализации файла import-from-WSDL-PAS:
Fix Step 2
InvRegistry.RegisterDefaultSOAPAction(TypeInfo(IVMProvisionCore), 'http://Cisco.VMProvision.Core/CoreServices/%operationName%');
Имя типа и URL-адрес должны быть получены из файла импорта, сгенерированного Delphi, из WSDL и / или проверка самого WSDL. Приведенный выше пример был для моего собственного проекта. После этих изменений кода появится ошибка:
Exception class ERemotableException с сообщением 'Форматер бросил исключение при попытке десериализации сообщение: Ошибка при десериализации тело сообщения запроса для операция ....
Эта ошибка устраняется добавлением следующего кода (кредиты на http://www.bobswart.nl/weblog/Blog.aspx?RootId=5:798 ). Опять же, этот новый код должен быть после всех вещей InvRegistry при инициализации файла WSDL-to-PAS.
Fix Step 3
InvRegistry.RegisterInvokeOptions(TypeInfo(IVMProvisionCore), ioDocument);
На этом этапе пакеты будут перемещаться между Delphi и C # - но параметры не будет работать должным образом. C # получит все параметры как пустые, а Delphi, похоже, неправильно получает параметры ответа. Последний шаг кода - использовать слегка настроенный объект THTTPRIO, который допускает буквальные параметры. Уловка в этой части состоит в том, чтобы убедиться, что опция применяется ПОСЛЕ того, как интерфейс был получен; делать это раньше не сработает. Вот код из моего примера (просто фрагменты).
Это вызвано несоответствием версии SOAP. Служба C # ожидает сообщение SOAP12 и получает сообщение SOAP11 от вашего приложения Delphi. В зависимости от вашей ситуации вам нужно изменить любую из двух сторон. Я не могу комментировать сторону Delphi. На стороне WCF вы можете использовать BasicHttpBinding, который по умолчанию соответствует SOAP11, или, если вам нужен больший контроль, используйте CustomBinding, определяя тип сообщения SOAP11.
Я также столкнулся с той же проблемой при использовании веб-службы C # в delphi.
Delphi 7.0 / 2005/2007 не поддерживает новые определения WSDL.
Для этого вам нужно будет загрузить последнюю версию WSDL Importer (WSDLImp.exe). Он также предоставит исходный код для обновленных файлов передачи исходного кода delphi.
Спасибо, это очень помогло. У меня были проблемы с еще парой морщин. Для меня проблема №2 (SOAPAction) была полностью испорчена, потому что OperationName не совпадала. Группа .Net стандартизировала размещение «In» в конце SOAPAction, но не Operation.
Итак, yadda.yadda.com/whatever/services/%operationName%
действительно должно быть
yadda.yadda.com/whatever/services/%operationName%In
В этом конкретном случае.
Мне потребовалось довольно много времени, чтобы заметить это, но я, наконец, заметил, тестируя параллельно с SoapUI, что у него были другие действия SOAPA, чем те, которые возвращаются в ответе об ошибке. Я исправил это, и это сработало. Но это было после долгих попыток выяснить, что должно быть в DefaultSOAPAction в первую очередь. Опять же, здесь нам помог SoapUI.
В любом случае, если вы обнаружите, что получите эту ошибку:
«Действие (что угодно) не может быть обработано в получателе из-за несоответствия ContractFilter в EndpointDispatcher ...»
Первый шаг - заполнить DefaultSOAPAction, и, если проблема не исчезнет, сравните то, что указано в ошибке, с тем, что действительно должно быть.
HTH, Крис