Первое замечание - при запуске под IIS 6 и 7 домены приложений могут находиться в отдельных рабочих процессах, если вы разрешаете IIS использовать несколько процессов для одного AppPool. Чтобы поместить его в надлежащий исторический контекст, AppDomain просто эмулирует то, что механизм IIS AppPool будет делать с любым двоичным файлом. Обеспечивает большую масштабируемость, и во многих случаях это не имеет значения, если у вас есть несколько копий «синглтона», что также может улучшить производительность.
Если вы действительно, действительно, и я имею в виду действительно :-), вам нужен синглтон серверного уровня, есть способ сделать это, не оплачивая затраты на удаленное взаимодействие, но только если вы знаете свой COM или WinNT API .
Маршрут WinNT будет самым легким в плане ресурсов, но вам придется выполнить полную работу WinNT до того момента, когда вы начнете спрашивать, почему вы все еще находитесь в C #, а не в C ++ - общая память, события или мьютексы WinNT и т. Д.
COM-маршрут потребует от вас принудительного вызова proc (правильные ключи реестра), и вы можете использовать AutoDual вместо AutoDispatch - сначала купить perf, а затем убедиться, что .NET имеет минимальный шанс длл как "свой". Цель состоит в том, чтобы заставить его выглядеть и крякать, как и любой другой из proc COM
Важный вопрос, который нужно задать себе: зачем мне это на самом деле? Если целью является кэширование, необходимо использовать совсем другую тактику, а не быструю обработку событий (в этом случае MSMQ будет хорошо работать - теперь он находится под эгидой WCF).