Я унаследовал веб-приложение на уровне Visual Studio 2003, которое поместило весь его код для доступа к SQL-серверу в веб-службу ASMX. Этот веб-проект имел веб-ссылку на веб-сервис. Мне нужно было взять все это под контроль исходного кода, обновить его до Vstudio 2008 и сделать кучу исправлений и улучшений.
При этом я наткнулся на аккуратную статью от Code Magazine, в которой подчеркиваются преимущества "разделения сборки" . Он был написан для WCF, но он «вдохновил меня» на:
- удалить веб-ссылку из моего основного проекта веб-приложения ASP.NET
- добавить новый проект в качестве библиотеки классов, которую я назвал ProxyZipeeeService
- добавить веб-ссылку в проект ProxyZipeeeService, чтобы указать на ZipeeeService проект
- добавить ссылку в основном проекте веб-приложения в ProxyZipeeeService.DLL , созданную при создании проекта с тем же именем.
Все работает, и я думаю, что есть некоторые преимущества [производительности?] Для разделения вещей, как это, но описав мою структуру, Мне нужно перейти к моему вопросу / проблеме :
Я сталкиваюсь с множеством проблем с конфигурацией, когда внедряю их в производственную среду, которые требуют от меня внесения изменений, которые являются довольно «неуклюжими» и склонными к ошибкам. Вот мое предположение о том, что нужно изменить, но я много искал и не могу понять, как:
Проект ProxyZipeeeService с веб-ссылкой в нем создает файлы следующим образом:
- Reference.map.vb, ProxyZipeeeService.disco, ProxyZipeeeService.wsdl и app.config
- на моем ПК для разработки файл app.config создал настройки для URL-адреса localhost (как это должно быть для моего ПК). Пожалуйста, просмотрите эту запись XML по адресу: http://pastebin.com/JtQCxT73
Когда я публикую проект веб-приложения на производственном веб-сервере, URL-адрес веб-службы «скрывается» внутри библиотеки DLL для ProxyZipeeeService (которая в настоящее время находится в папке bin веб-приложения, поскольку она ссылки).
Поскольку веб-сервер prod настроен на распознавание "файлов заголовков хоста" [другой вопрос когда-нибудь], URL с localhost завершается с ошибкой HTTP 400 Bad Request . Конфигурация заголовка узла требует, чтобы все, что связано с этим веб-сайтом по умолчанию, использовало домен http://www.zipeee.com/ZipeeeWebService/Zipeee.asmx
Итак, чтобы исправить это, мне пришлось «разобрать» мой проект разработки для ProxyZipeeeService - полностью удалить веб-ссылку, добавить ее обратно, но на этот раз сделать диалоговое окно точкой WS на рабочем сервере (вместо этого позволить ему найти WS в «этом решении», потому что это приводит к проблематичным настройкам «localhost»).
В конце концов я могу вытолкнуть на сервер prod веб-проект, ссылающийся на dll-прокси, который не сталкивается с проблемой заголовка хоста и работает без выдачи ошибки HTTP 400.
Но должен быть лучший путь!
Короче говоря, критический прокси-сервер DLL не может быть настроен с учетом URL, он должен использовать способ, который я сейчас настроил. Я попытался поместить запись applicationSettings из app.config в web.config моего проекта веб-приложения. Я также попытался поместить вариант этого в раздел appSettings . Обе эти попытки провалились.
Надеюсь, я был ясен и не слишком многословен. Пожалуйста, не предлагайте серьезную хирургию, такую как WCF, потому что я не могу откусить от этого сейчас для этого проекта. Спасибо за чтение и заранее спасибо за помощь.
EDIT UPDATE: изменение URL-адреса в веб-приложении веб-приложения не обнаружено! Проблема остается. Вот что я сделал:
- Точно так же, как вы сказали, подняв настройки из app.config прокси-сервера в web.config веб-приложения (создание новой группы разделов конфигурации, которая указывает на мои настройки из app.config.
- Значение в прокси, а теперь и в web.config читается как: http://localhost/ZipeeeWebService/Zipeee.asmx, что хорошо для тестирования на моем ПК разработчика
- Перед развертыванием всего этого на рабочем сервере я подумал, что мне нужно немного протестировать. Мой первый тест был с настройками выше, и я установил точку останова в проекте веб-службы и проверил, что прокси действительно пришел к localhost, как и предполагалось в записи web.config.
- Далее (контрольный пример 2) Я изменил запись web.config с localhost на www.zipeee.com, где находится производственный веб-сервис, используемый общедоступным веб-приложением.
- Я оставил ту же точку останова в первом вызове веб-службы на месте (ожидая, что она не будет достигнута, поскольку предполагалось использовать URL-адрес, указанный в файле web.config)
- К моему удивлению, точка останова была достигнута, и когда я проверил URL через окно «Немедленно», он показал, что это localhost (должен был быть www.zipeee.com, как нужно в web.config).
Возможно, я неправильно понял, что должен допускать этот подход? Есть ли что-то, что мне не хватает? Я НЕ перестраивал библиотеку Proxy (которая остается с localhost), которая, как я думал, была целиком (то есть, чтобы иметь возможность контролировать URL своего рода «поздним связыванием» посредством изменений в сети). .config веб-приложения).
Я остаюсь в тупике. Надеюсь, вы могли бы помочь мне немного больше ... Спасибо.
РЕДАКТИРОВАТЬ ОБНОВЛЕНИЕ: 12 октября
Спасибо. Я читаю ваши заметки, но все еще в замешательстве. Код проекта ProxyZipeeeService генерируется из веб-ссылки. Вот фрагмент из файла reference.vb ( вы предлагаете изменить этот сгенерированный код? ):
Public Sub New()
MyBase.New
Me.Url = Global.ProxyZipeeeService.My.MySettings.Default.ProxyZipeeeService_WSZipeee_Zipeee
If (Me.IsLocalFileSystemWebService(Me.Url) = true) Then
Me.UseDefaultCredentials = true
Me.useDefaultCredentialsSetExplicitly = false
Else
Me.useDefaultCredentialsSetExplicitly = true
End If
End Sub
Public Shadows Property Url() As String
Get
Return MyBase.Url
End Get
Set
If (((Me.IsLocalFileSystemWebService(MyBase.Url) = true) _
AndAlso (Me.useDefaultCredentialsSetExplicitly = false)) _
AndAlso (Me.IsLocalFileSystemWebService(value) = false)) Then
MyBase.UseDefaultCredentials = false
End If
MyBase.Url = value
End Set
End Property
Кстати, не могли бы вы прокомментировать, стоит ли вообще идея отдельной сборки (прокси) для веб-службы. Могут быть некоторые преимущества в производительности (?), Но эти проблемы с конфигурацией меня устраивают.
РЕДАКТИРОВАТЬ-ОБНОВИТЬ 12 октября - чуть позже
После последней публикации кода из сгенерированного файла reference.vb я обнаружил проблему! Объявления, которые вы разместили в файле web.config веб-приложения, назывались:
section name="ProxyZipeeeService.Properties.MySettings"
в то время как файл reference.vb ссылается на настройку как:
Me.Url = Global.ProxyZipeeeService.My.MySettings.Default.ProxyZipeeeService_WSZipeee_Zipeee
Изменение имени веб-конфигурации для чтения в виде раздела name = "ProxyZipeeeService. My .MySettings" позволило прокси-серверу найти параметр в web.config веб-приложения, и теперь я могу " переключать "URL-адрес веб-службы через параметры конфигурации.
Большое спасибо за вашу помощь. Я закрываю это сейчас.
p.s. Используют ли «профессионалы» прокси-классы в качестве оболочек для подобных веб-сервисов?