Уточнение: речь идет не о пользовательских агентах обращениях к страницам, а о классическом ASP, вызывающем ASP.NET!
У меня есть приложения, которые находятся в середине перехода от классического ASP к ASP.NET. Полмиллиона строк кода, поэтому полное переписывание всего за один раз было просто неправдоподобным или откровенно осмотрительным, учитывая, что подавляющее большинство страниц Classic ASP работают просто отлично. Мы переводим страницы и функциональные возможности по мере того, как они приходят на доработку в любом случае , а не только потому, что это «круто».
Теперь, когда примерно половина страниц была преобразована, мы перенесли некоторые ключевые функции в ASP.NET. Вместо того, чтобы сохранять устаревшие версии этой функциональности (что означает два места для обслуживания вместо одного), я перешел к использованию SOAP для предоставления этой функциональности.
Ну ... не совсем. Вместо этого мы использовали то, что я раньше называл «SOAP для бедняков», хотя сегодня модно называть это REST. Я использую ServerXMLHTTP для связи со страницей назначения, связываю шарик XML и размещаю его на стороне ASP.NET. В результате я собрал несколько XML и использовал XPATH, чтобы разбить их на переменные.
Все это работает на удивление хорошо. Тем не менее, я обдумывал встроенные функции ASP.NET SOAP, которые, казалось бы, избавили от необходимости настраивать целевые страницы записи для моих кроссплатформенных вызовов ... но когда я смотрю на использование SOAP из Classic ASP, большинство предлагают использовать, казалось бы, внешнее устарел Soap Toolkit.
Вопрос в том; Кто-нибудь из вас имеет опыт установки такого рода, и если да, то есть ли более эффективные способы сделать это, чем пользовательские страницы REST или Soap Toolkit? Я думаю, что более быстрое раскрытие большей части функциональности ASP.NET могло бы помочь с миграцией, но я не хочу, чтобы излишне увлекаться устаревшими технологиями, такими как Soap Toolkit.