You need to enable JavaScript to run this app.
优惠活动
大模型
产品
解决方案
定价
更多

跨.NET Framework与.NET Core检测是否运行于IIS的方案

.NET Framework 共享代码库迁移至.NET Standard的托管环境检测方案需求

背景与现状

我正尝试将一个共享代码库从.NET Framework迁移至.NET Standard,该库原本依赖System.Web.Hosting.HostingEnvironment.IsHosted和HostingEnvironment.ApplicationID两个API。

该库为预编译程序集,被多类项目引用:
-.NET Framework控制台应用
-.NET Framework Windows Forms应用
-.NET Framework Windows服务
-独立ASP.NET网站(客户定制代码,常作为Web服务使用)
-第三方编写的ASP.NET站点扩展(创建新ascx控件,编译后的代码后置文件放入\bin\文件夹)

预编译的目的是可以直接将更新后的程序集替换到所有引用它的解决方案中,无需重新编译调用项目。

库的核心功能包括标准化数据库访问、日志记录、许可证验证、类型转换等,其中日志功能是迁移难点:日志不仅被调用项目直接使用,库内部模块(比如依赖数据库访问的许可证验证)也会调用日志记录错误。在IIS部署场景下,需要根据应用ID和应用池名称区分日志文件(例如IIS环境下日志命名为MyCompany.2.PublicSitePool.log,非IIS环境为MyCompany.log),尤其要适配第五种场景的复杂部署:父应用可能分布在多IIS站点的多应用池、多站点共用一个应用池、或同一站点不同子文件夹对应不同应用池的情况。

在.NET Framework环境中,我通过以下方式实现相关逻辑:

  • 用System.Web.Hosting.HostingEnvironment.IsHosted检测是否运行在IIS中
  • 用HostingEnvironment.ApplicationID获取应用ID
  • 从System.Environment.UserName获取应用池名称

迁移需求与约束

目标是将库迁移至.NET Standard,使其同时兼容.NET Core项目,但.NET Core中不存在System.Web.Hosting命名空间,解决方案需满足以下任一条件:

  1. 在.NET Framework和.NET Core环境下输出一致的检测结果
  2. 明确识别当前运行平台(.NET Framework/.NET Core),然后调用对应平台的技术实现

目前已在类构造函数中以单例模式实现了“是否在IIS中”的检查逻辑。反射方案虽非最优,但必要时可以接受。

已排除的方案:

  • 读取*.config配置文件不可行
  • 让调用应用主动指定“托管/非托管”状态是最不理想的方案,会破坏所有现有引用该库的解决方案

已参考的相关思路

已查阅多个技术问题,获取了部分零散思路,但未找到完整的解决方案,涉及的问题方向包括:

  • HostingEnvironment类无IsHosted定义的替代方案
  • .NET Core环境下如何判断应用是否为Web应用
  • 不依赖System.Web判断代码是否运行在Web服务器中
  • ASP.NET Core中获取HttpContext的替代方式

内容的提问来源于stack exchange,提问作者Bruce

相关产品推荐
方舟 Agent Plan

超全模态模型 × Harness 升级,最新支持 Deepseek-V4.1-Flash、GLM-5.3 系列、Doubao-Seedream-5.0-pro、Kimi-K3 (部分), 限时 9.9 元起

最近更新时间:2026.08.11 08:32:17