问Windows或ASP.NET服务中的System.Drawing

EN

为了澄清任何混淆，System.Drawing可以在ASP.NET和服务下工作，只是不受支持。可能会出现高负载(耗尽非托管资源)、内存或资源泄漏(实现不佳或称为处置模式)和/或在没有桌面显示对话框时弹出对话框的问题。

测试将处理后者，而监控将提醒您注意前者。但是，如果/当你遇到问题时，不要期望能够呼叫PSS并要求修复。

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

如果你想要一些支持，那么你需要知道你是否正在交互运行。就我个人而言，我可能只会让托管应用程序在某个地方设置一个非交互式标志。毕竟，应用程序处于最佳位置来确定它们是否在托管环境中和/或想要冒GDI+问题的风险。

但是，如果你想自动检测你的环境，我想有比为服务提供right here on SO更糟糕的答案。总之，您可以检查EntryAssembly以查看它是否继承自ServiceBase，或者尝试访问System.Console。对于ASP.NET，按照同样的思路，检测HttpContext.Current应该就足够了。

我认为会有一种托管或p/invoke的方式来寻找桌面(我认为这是所有这一切的决定性因素)和/或AppDomain之外的东西，这会给你提供线索。但我不确定它是什么，MSDN对此缺乏启发性。

编辑:浏览MSDN时，我回想起它实际上是一个Window Station (托管桌面)，这才是这里的重点。有了这些信息，我就能够找到GetProcessWindowStation()，它返回当前窗口站的句柄。将该句柄传递给GetUserObjectInformation()将得到一个USEROBJECTFLAGS结构，如果您有一个可见的桌面，那么它应该有一个带有WSF_VISIBLE的dwFlags。

或者，EnumWindowsStations会给你一个可以查看的电台列表-- WinSta0是交互式的。

但是，是的，我仍然认为让应用程序设置一个属性或其他东西是更容易的方法……

再次编辑:7年后，我进入了Environment.UserInteractive，上面我为你描述了MS does the exact GetProcessWindowStation dance的地方……我仍然建议委托主机应用程序(他们可能想要更快，但略有风险的System.Drawing路径)，但UserInteractive似乎是一个很好的默认设置，而不是让它自己调用它。

尽管没有得到官方的支持，但多年来我在高容量web服务器( web应用程序和web服务)上广泛使用了System.Drawing类，没有造成任何性能或可靠性问题。

我认为确定代码是否可以安全使用的唯一方法是使用{}语句测试、监视和包装任何具有外部资源的对象。

您可以改用TextRenderer。我知道在ASP.NET中使用来自System.Windows.Forms的东西有点奇怪，但它似乎没有关于ASP.NET不支持的相同警告。我使用过TextRenderer和Graphics.MeasureString来测量ASP.NET应用程序中的字符串，所以它们都可以工作。我从来没有在ASP.NET中看到过关于System.Drawing不可取的警告。

TextRenderer比Graphics.MeasureString慢得多。