Возможно ли создать экземпляр наследника Page, если он определен в .aspx и .aspx.cs файлах?
Программирую за еду.

Пытаюсь сделать что-то вроде Proxy для веб-сайтов.

Идея: сервер получает запрос, создает нужный IHttpHandler и вызывает ProcessRequest c подмененным контекстом. Фишка в том, что многие из IHttpHandler-ов будут генерировать веб страницы, и хотелость бы использовать стандартные средства студии для их создания. Если бы можно было достучаться до класса, описанного в .aspx, можно было бы наделать обчных страниц, а в диспетчере делать IHttpHandler foo = new BarPage() и т.д.
Программирую за еду.

Server.Transfer("barpage.aspx") - редирект, только серверный.

В зависимости от логики приложения при обращении на какой-нибудь unipage.aspx происходит отрисовка разных страниц. Это нужно?

В том-то и проблема, что страницы хранятся на другом сервере. Нужны (веб)службы, которые будут возвращать "пользовательский интерфейс". Я представлял это так: прокси получает запрос клиента, подменяет некоторые свойства (что-бы грамотно рендерились ссылки на странице), отправлет его нужной службе, которая на его базе рендерит веб страницу и передает ее обратно прокси.
Программирую за еду.

Заморочка...

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



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


я хочу узнать возможность исполнения такого финта перед разработкой архитектуры, для того, чтобы в случае, если это очень тяжело, придумывать другой принцип работы .

Могу описать только самые общие соображения:
На предприятии есть различные клиенты, которые знают интерфейсы своих служб, но не знают деталей их реализации (в том числе и физ. адреса). Для того, чтобы получить сервисы, они обращаются к одной хорошо известной службе (портал) и запрашивают, что им надо. Портал предоставляет сервисы каталога, а за одно является и прокси, т.к. клиент не всегда может обратиться напрямую к службе (например, клиент не в доменной зоне, или работает по другому протоколу, портал будет преобразовывать протокол). Если считать человека с веб-брозером частным случаем клиента, а веб-сайт частным случаем службы, необходимо создать канал доступа к сайту через портал. Отсюда и вышеописанные извращения.
Программирую за еду.