Title is pretty much it. The DLL that has the logic that differs depending if this is website or some other app type. In the framework we often used HttpContext.Current. We could also retrieve request from it. I looked at different docs, like RuntimeInformation, System.Runtime.Hosting and others.
Is there a proper way to determine that?
There is no standard method to detect that your dll is running in website and first of all there never was one even for the .NET Framework.
Your method based on HttpContext.Current is very limited due to assumptions you have to make to use it and never ever was supposed to allow for universal detection of process which supports website.
First of all it seems that your definition of problem "detect if dll is running in website or other app" is just too wide. If you want for sure to know if you dll is running in a website you would have to know in advance what dlls will be present in tested "website". It is entirely conceivable that website can be created based on private web frameworks which skip all standard ASP.Net Core components and even .NET Core networking libraries and yet can use your assembly which than would have no simple way to detect that it is running in the website. As an example one could create very fast .NET Core website based on Intel DPDK user space IO library. To better understand the problem go to techpowerup benchmarks and check how many different low and higher level web frameworks and stacks exist for every programing language or just in time compiled languages for different virtual machines. Currently .NET Core is a unique example with very limited number of web frameworks and stacks.
Perhaps, proper way to state the problem would be: "detect if a dll is running in ASP.Net Core framework" or even if the dll is running in a process that uses ASP.Net Core assemblies and .NET Core networking stack. And than having limited the scope of detection to tractable problem size it's up to you to determine which parts of request processing pipeline would you check to confirm that dll is running in a process which could be described as having a website functionality. As you may know ASP.Net Core processing pipeline is extensible and can be heavily customized by any user what could render above method useless (in .NET Framework this statement holds as well).
Otherwise, attempting to find a "general" solution you may decide to go for very general method of detecting website process but than most probably very low level verification at the OS level is required. You could check if the process in which your dll is running is using kernel or even userspace networking stack (again as an example Intel DPDK, however, there are many others in HPC space) and keeps open sockets listening for incoming requests. Than you would need continuously maintained large whitelist of processes for every system and apps which legitimately use open listening sockets for other than website purposes to eliminate any false positives.
