System.Drawing在Windows或ASP.NET服务中

根据MSDN,在Windows服务或ASP.NET服务中使用System.Drawing命名空间中的类并不是一个特别好的主意.现在我正在开发一个类库,它可能需要访问这个特定的命名空间(用于测量字体),但不能保证主机进程不是服务.

现在有一个不太理想的方法,如果System.Drawing不可用,我可以回退,但如果可行的话,我宁愿在System.Drawing中使用类.所以我想要做的是在runtume确定System.Drawing是否安全,如果是,请使用它,否则回到次优选项.

我的问题是:我怎么可能检测System.Drawing是否可以安全使用？

我想我应该

检测当前进程是Windows服务还是ASP.NET服务

检测GDI是否可用

或者,如果可以安全使用,可能有办法询问System.Drawing.dll本身

不幸的是,我无法想出一种方法来实现任何这些方法.有谁有想法吗？

为了消除任何混淆,System.Drawing 在ASP.NET和Services下工作,它只是不受支持.可能存在高负载(耗尽非托管资源),内存或资源泄漏(执行不当或称为处置模式)和/或在没有桌面显示时打开对话框的问题.

测试将负责后者,监控将提醒您前者.但是,如果/当您遇到问题时,不要期望能够拨打PSS并要求修复.

那么,你有什么选择？好吧,如果你不需要一个完全支持的路由,并且你不期望极端负载 - 很多人已经忽视了MSDN警告并成功使用了System.Drawing.他们中的一些人被咬了,但是比失败的故事还要多得多.

如果你想要支持的东西,那么你需要知道你是否以交互方式运行.就个人而言,我可能只是将其留给托管应用程序在某处或其他地方设置非交互式标志.毕竟,应用程序处于最佳位置,以确定它们是否处于托管环境中和/或想要冒GDI +问题的风险.

但是,如果你想自动检测你的环境,我认为答案比在这里提供的服务更糟糕.总而言之,您可以检查EntryAssembly以查看它是否从ServiceBase继承,或尝试访问System.Console.对于ASP.NET,沿着相同的路线,检测HttpContext.Current应该就足够了.

我认为有一种托管或p/invoke方式来寻找一个桌面(这是所有这一切的真正决定因素,我认为)和/或AppDomain之外的东西,这会让你知道.但是我我不确定它是什么,MSDN对它的启发不那么有启发性.

编辑:Trolling MSDN,我记得它实际上是一个Window Station(它托管一个桌面),这是重要的一点.通过该信息,我能够找到GetProcessWindowStation(),它返回当前窗口站的句柄.将该句柄传递给GetUserObjectInformation()将获得一个USEROBJECTFLAGS结构,如果你有一个可见的桌面应该有一个带WSF_VISIBLE的dwFlags.

或者,EnumWindowsStations将为您提供可以检查的站点列表 - WinSta0是交互式站点.

但是,是的,我仍然认为只是让应用程序设置属性或东西是更容易的路线....

再次编辑:7年后,我进入了Environment.UserInteractive,其中MS 完成了我上面描述的GetProcessWindowStation舞蹈 ....我仍然建议委托给托管应用程序(他们可能想要更快,但略有风险较高的System.Drawing路径),但UserInteractive似乎是一个很好的默认值,没有它自己pinvoke它.