Обновление веб-ссылки в Visual Studio

Я унаследовал проект веб-сайта, в котором используется ряд веб-служб WCF, размещенных на сервере BizTalk. У нас есть две среды, в которых мне нужно развернуть этот проект, с разными URL-адресами для разных серверов BizTalk.

т. е. в среде Staging мне нужно указать службы на xx.xx.xx.101
В среде Live мне нужно указать им на xx.xx.xx.102 или что-то еще.

В настоящее время у нас есть все URL-адреса, хранящиеся в ключах в файле web.config, поэтому мы можем изменять их динамически. К сожалению, это не работает.

Если я изменю URL-адрес в web.config на что-то отличное от того, с чем был скомпилирован проект, я получаю сообщение об ошибке при вызове службы:

Сервер не распознал значение HTTP-заголовка SOAPAction: xx.xx.xx.101\ServiceName\MethodName

Мне сказали, что единственный известный им способ развернуть это — обновить URL-адреса web.config, изменить все веб-ссылки в Visual Studio, чтобы они совпадали, нажать «Обновить веб-ссылку» для каждой ссылки в Visual Studio, а затем скомпилировать.

Я написал сценарий предварительной сборки NAnt, чтобы просмотреть и заменить все экземпляры URL-адреса, найденные где-либо в каталоге проекта, и даже это не имеет никакого значения.

Когда я нажимаю «Обновить ссылку», должно быть что-то еще, вытаскиваемое из службы, но я не уверен, что именно.

У кого-нибудь есть какие-либо идеи? Есть ли способ сделать это программно?


c# biztalk wcf web-services
person NeilD    schedule 09.03.2010    source источник
comment
Это веб-ссылки или ссылки на сервисы?   -  person John Saunders    schedule 09.03.2010

Ответы (3)


arrow_upward
3
arrow_downward

Являются ли упомянутые веб-сервисы точно такими же на разных серверах, за исключением URL-адреса? В частности, пространство имен должно быть одинаковым для всех упомянутых служб.

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

YourServiceReference yourService = new YourServiceReference();
yourService.Url = "http://yourconfigendpoint";

РЕДАКТИРОВАТЬ: Это для веб-сервисов старого стиля, а не для WCF, но должно быть похоже..?

person mattanja    schedule 09.03.2010
comment
Привет, Маттанья. Извините, если я не ясно выразился, но я уже устанавливаю для свойства URL значение web.config. После этого я получаю ошибку, показанную выше. Служба подключается к правильному серверу, но после этого возникает ошибка. - person NeilD; 09.03.2010
comment
Да, извините, я также заметил потом, что, возможно, я не дал вам ответ, который вы искали :) - отредактировано - person mattanja; 09.03.2010
comment
Честно говоря, я не уверен, что веб-сервисы одинаковы на обоих серверах. К сожалению, это не мои серверы, и это трудно проверить! - person NeilD; 09.03.2010

arrow_upward
0
arrow_downward

НилД! Я считаю, что полная замена URL в проекте не лучшее решение. Я думаю, что вызовы службы WCF в веб-проекте заставили контракты бросать сообщения. Можете ли вы разместить здесь фрагмент кода вызова какого-либо метода службы. Вы должны заменить только те URL, которые присутствуют в конструкторе прокси. Другие URL-адреса, в которых указано имя метода, должны оставаться неизменными.

person Yuriy Khan    schedule 09.03.2010
comment
Привет, Юрий... Код для вызова метода службы почти идентичен фрагменту, опубликованному выше маттаньей. Мне удалось решить проблему с помощью NAnt, но спасибо за ваше время. - person NeilD; 09.03.2010

arrow_upward
0
arrow_downward

Верно... Кажется, я исправил это!

Я отказался от всех веб-ссылок Visual Studio в пользу прокси-классов, сгенерированных задачей NAntContrib «wsdl».

Теперь скрипт будет обновлять все ссылки в зависимости от того, какой тип сборки вы выбрали (отладка, выпуск и т. д.).

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

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

person NeilD    schedule 09.03.2010