Не существует стандартного метода для определения того, что ваша dll работает на веб-сайте, и, прежде всего, ее никогда не было даже для .NET Framework.
Ваш метод, основанный на HttpContext.Current, очень ограничен из-за допущений, которые вы должны сделать, чтобы использовать его, и никогда не предполагалось, что он обеспечит универсальное обнаружение процесса, который поддерживает веб-сайт.
Прежде всего, кажется, что ваше определение проблемы «определить, работает ли dll на веб-сайте или в другом приложении», слишком широкое. Если вы хотите точно знать, работает ли ваш dll на веб-сайте, вы должны заранее знать, какие dll будут присутствовать на проверенном «веб-сайте». Вполне возможно, что веб-сайт может быть создан на основе частных веб-фреймворков, которые пропускают все стандартные компоненты ASP.Net Core и даже сетевые библиотеки .NET Core, и в то же время могут использовать вашу сборку, которая не имела бы простого способа обнаружить, что он работает в веб-сайт. В качестве примера можно создать очень быстрый веб-сайт .NET Core на основе библиотеки ввода-вывода пространства пользователя Intel DPDK. Чтобы лучше понять проблему, перейдите в бенчмарки techpowerup и проверьте, сколько существует веб-фреймворков и стеков низкого и высокого уровня для каждого языка программирования или просто скомпилированных языков для разных виртуальных машин. В настоящее время .NET Core является уникальным примером с очень ограниченным количеством веб-фреймворков и стеков.
Возможно, правильным способом постановки проблемы было бы: «определить, работает ли dll в каркасе ASP.Net Core» или даже если dll работает в процессе, который использует сборки ASP.Net Core и сети .NET Core стек. И чем ограничить сферу обнаружения до размера проблемы, которую можно решить, вам решать, какие части конвейера обработки запросов вы бы проверили, чтобы подтвердить, что dll работает в процессе, который можно охарактеризовать как имеющий функциональность веб-сайта. Как вы, возможно, знаете, конвейер обработки ASP.Net Core является расширяемым и может быть сильно настроен любым пользователем, что может сделать вышеуказанный метод бесполезным (в .NET Framework это утверждение также выполняется).
В противном случае, пытаясь найти «общее» решение, вы можете решить использовать очень общий метод обнаружения процесса веб-сайта, но, скорее всего, требуется очень низкий уровень проверки на уровне ОС. Вы можете проверить, использует ли процесс, в котором работает ваша dll, ядро или даже сетевой стек пользователя (опять же, в качестве примера Intel DPDK, однако в пространстве HPC есть много других) и поддерживает открытые сокеты для прослушивания входящих запросов. Чем вам понадобится постоянно поддерживать большой белый список процессов для каждой системы и приложений, которые законно используют открытые сокеты прослушивания для целей, отличных от веб-сайта, чтобы исключить любые ложные срабатывания.