Вы не должны действительно добавлять его к существующим классическим страницам ASP. Возможно, вы захотите выполнить полную (но медленную) миграцию с классического ASP на .Net. В противном случае вы можете просто захотеть полностью добавить новые функции на новых страницах. Если у вас есть шаблонный сайт, это может стать немного громоздким, потому что вам нужно будет воссоздать эти шаблоны в .Net, так как смешивать .Net и classic в одном файле невозможно.
В конечном итоге вы могли бы в конечном итоге прибегнуть к iframes, но это иногда делает браузеры глупыми. Если ваше приложение зависит от сеанса, вам придется учитывать это, потому что .Net не может получить доступ к классическому сеансу, если вы не придерживаетесь примитивов (string / int / etc) и не используете внешний поставщик состояний (например, SQL) для хранения данные с идентификатором сеанса, которые могут быть переданы.
Наличие гибридного сайта - очень сложная перспектива, которую нельзя воспринимать легкомысленно. Поступай осторожно, иначе ты действительно будешь в маринаде.
РЕДАКТИРОВАТЬ: описание частичного гибридного
У нас было около 700 страниц сайта для перехода с классического asp на Asp.Net 2.0. Многим страницам было выделено время для полной передачи в течение одного проекта, но некоторые области не могли быть реорганизованы и должны были быть размещены. Мы собрали архитектуру мастер-страницы для новой структуры .Net, библиотеки данных и библиотеки бизнес-объектов, и мы начали передачу. При включении классических страниц ASP мы определили, что у нас есть несколько потребностей.
- Поскольку главные страницы будут управлять основным макетом, меню, верхним и нижним колонтитулами, нам нужно будет удалить эти элементы с любых перенесенных страниц.
- Новые требования к сеансу несовместимы с существующими возможностями сеанса.
- Классические страницы asp по-прежнему должны быть обязательны для проверки подлинности с помощью форм .Net.
Я решил эти проблемы с помощью следующих решений:
- Наше приложение предназначено для конкретного клиента, поэтому мы смогли определить требования браузера. Это позволило нам использовать iframe для хранения классического содержимого / приложений asp, не беспокоясь о том, что iframe сойдет с ума от нас в Webkit, Firefox или чем-то еще.
- Для соответствия требованиям сеанса мы создали небольшой механизм шифрования / дешифрования в .Net и в классическом asp, который позволил нам зашифровать «строку запроса» для передачи информации о сеансе туда и обратно. Это не было супер-безопасностью, просто достаточно, чтобы случайный пользователь не испытывал соблазна связываться с данными. Кроме того, нам пришлось построить два файла перевода. Первым файлом перевода был статический метод библиотеки .Net, который собирал данные сеанса, извлекал необходимые фрагменты и создавал строку запроса. Второй была классическая версия asp, предназначенная для чтения строки запроса, анализа данных и непосредственного создания примитивов сеанса.
- Приведение классических asp-страниц в соответствие с .Net было проблемой управления сервером. Для этого достаточно использовать атрибут formsauthentication protection = "All", но я обнаружил, что он по-прежнему не охватывает элементы, ожидаемые другими обработчиками. Поэтому я добавил в IIS сопоставление с подстановочными знаками для обработки всех файлов. В свойствах веб-сайта IIS выберите «Домашний каталог» и нажмите «Конфигурация». Внизу следующего окна находится поле «Карты приложения с подстановочными знаками». Нажмите «Вставить» и перейдите к версии .Net, которую вы используете, чтобы найти файл aspnet_isapi.dll. Это заставит все файлы анализировать этот файл (который безвреден, за исключением того, что запускает запрос аутентификации).
Я не могу предоставить конкретные примеры кода из-за NDA, но это должно, по крайней мере, дать некоторые идеи о том, куда идти дальше.