blocks|key|357324|text|您可以改用TextRenderer。我知道在ASP.NET中使用来自System.Windows.Forms的东西有点奇怪，但它似乎没有关于ASP.NET不支持的相同警告。我使用过TextRenderer和Graphics.MeasureString来测量ASP.NET应用程序中的字符串，所以它们都可以工作。我从来没有在ASP.NET中看到过关于System.Drawing不可取的警告。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|357325|TextRenderer比Graphics.MeasureString慢得多。|357326|entityMap|0|LINK|mutability|MUTABLE|url|http://msdn.microsoft.com/en-us/library/system.windows.forms.textrenderer.aspx^0|5|C|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

You could use <a href="http://msdn.microsoft.com/en-us/library/system.windows.forms.textrenderer.aspx" rel="nofollow noreferrer">TextRenderer</a> instead. I know it's weird to use something from System.Windows.Forms in ASP.NET, but it doesn't appear to have the same warning about not being supported in ASP.NET. I have used both TextRenderer and Graphics.MeasureString to measure strings in ASP.NET applications, so they both work. I had never seen the warning about System.Drawing not being advisable in ASP.NET.

TextRenderer is a lot slower than Graphics.MeasureString, FWIW.

blocks|key|3350165|text|您可以将System.Drawing.dll复制到应用程序的bin中，然后以这种方式使用它。这可能会保证它的可用性。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3350166|只需右键单击应用程序中的引用，并将Copy+Local的选项更改为true。|offset|length|style|BOLD|3350167|我可能误解了这个问题...|3350168|entityMap^0|0|H|A|X|4|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@$D|N|E|O|F|G]|$D|P|E|Q|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|R|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|K|$]]

You might be able to copy the System.Drawing.dll to the bin of your application and then use it that way. That might guarantee its availability.

Just right click on the reference in your application and change the option for Copy Local to true.

I may be misunderstanding the question though...

blocks|key|357370|text|这可能与需要STA线程的GDI子系统有关。如果是这样的话，研究一下在@PAGE指令中为所涉及的aspx页面指定ASPCOMPAT=TRUE。这将在STA线程IIRC中运行aspx页面。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|357371|-Oisin|357372|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

It might be something to do with the GDI subsystem needing an STA thread. If this is the case, investigate specifying ASPCOMPAT=TRUE in your @PAGE directive for the aspx page involved. This will run the aspx page in an STA thread, IIRC.

-Oisin

blocks|key|354719|text|为了澄清任何混淆，System.Drawing可以在ASP.NET和服务下工作，只是不受支持。可能会出现高负载(耗尽非托管资源)、内存或资源泄漏(实现不佳或称为处置模式)和/或在没有桌面显示对话框时弹出对话框的问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|354720|测试将处理后者，而监控将提醒您注意前者。但是，如果/当你遇到问题时，不要期望能够呼叫PSS并要求修复。|354721|那么，你有什么选择？好吧，如果你不需要一个完全支持的路由，并且你不期望极端的负载-很多人已经忽略了MSDN的警告，并成功地使用了System.Drawing。他们中的一些人被咬了，但成功的故事比失败的故事多得多。|354722|如果你想要一些支持，那么你需要知道你是否正在交互运行。就我个人而言，我可能只会让托管应用程序在某个地方设置一个非交互式标志。毕竟，应用程序处于最佳位置来确定它们是否在托管环境中和/或想要冒GDI%2B问题的风险。|354723|但是，如果你想自动检测你的环境，我想有比为服务提供right+here+on+SO更糟糕的答案。总之，您可以检查EntryAssembly以查看它是否继承自ServiceBase，或者尝试访问System.Console。对于ASP.NET，按照同样的思路，检测HttpContext.Current应该就足够了。|offset|length|354724|我认为会有一种托管或p/invoke的方式来寻找桌面(我认为这是所有这一切的决定性因素)和/或AppDomain之外的东西，这会给你提供线索。但我不确定它是什么，MSDN对此缺乏启发性。|354725|编辑:浏览MSDN时，我回想起它实际上是一个Window+Station+(托管桌面)，这才是这里的重点。有了这些信息，我就能够找到GetProcessWindowStation()，它返回当前窗口站的句柄。将该句柄传递给GetUserObjectInformation()将得到一个USEROBJECTFLAGS结构，如果您有一个可见的桌面，那么它应该有一个带有WSF_VISIBLE的dwFlags。|354726|或者，EnumWindowsStations会给你一个可以查看的电台列表--+WinSta0是交互式的。|354727|但是，是的，我仍然认为让应用程序设置一个属性或其他东西是更容易的方法……|354728|再次编辑:7年后，我进入了Environment.UserInteractive，上面我为你描述了MS+does+the+exact+GetProcessWindowStation+dance的地方……我仍然建议委托主机应用程序(他们可能想要更快，但略有风险的System.Drawing路径)，但UserInteractive似乎是一个很好的默认设置，而不是让它自己调用它。|354729|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/200163/am-i-running-as-a-service#200183|1|http://alt.pluralsight.com/wiki/default.aspx/Keith.GuideBook/WhatIsAWindowStation.html|2|http://msdn.microsoft.com/en-us/library/ms683225(VS.85).aspx|3|http://msdn.microsoft.com/en-us/library/ms683238(VS.85).aspx|4|http://msdn.microsoft.com/en-us/library/ms686892(VS.85).aspx|5|http://msdn.microsoft.com/en-us/library/ms682644(VS.85).aspx|6|https://msdn.microsoft.com/en-us/library/system.environment.userinteractive(v=vs.110).aspx|7|http://referencesource.microsoft.com/#mscorlib/system/environment.cs,7d2f1469d916fc63^0|0|0|0|0|P|G|0|0|0|M|E|1|1U|P|2|33|Q|3|3Y|F|4|0|3|J|5|0|0|D|R|6|1G|18|7|0^^$0|@$1|2|3|4|5|6|7|1H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1J|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|1K|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|1L|8|@]|9|@$J|1M|K|1N|1|1O]]|A|$]]|$1|L|3|M|5|6|7|1P|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|1Q|8|@]|9|@$J|1R|K|1S|1|1T]|$J|1U|K|1V|1|1W]|$J|1X|K|1Y|1|1Z]|$J|20|K|21|1|22]]|A|$]]|$1|P|3|Q|5|6|7|23|8|@]|9|@$J|24|K|25|1|26]]|A|$]]|$1|R|3|S|5|6|7|27|8|@]|9|@]|A|$]]|$1|T|3|U|5|6|7|28|8|@]|9|@$J|29|K|2A|1|2B]|$J|2C|K|2D|1|2E]]|A|$]]|$1|V|3|-4|5|6|7|2F|8|@]|9|@]|A|$]]]|W|$X|$5|Y|Z|10|A|$11|12]]|13|$5|Y|Z|10|A|$11|14]]|15|$5|Y|Z|10|A|$11|16]]|17|$5|Y|Z|10|A|$11|18]]|19|$5|Y|Z|10|A|$11|1A]]|1B|$5|Y|Z|10|A|$11|1C]]|1D|$5|Y|Z|10|A|$11|1E]]|1F|$5|Y|Z|10|A|$11|1G]]]]

To clear up any confusion, System.Drawing does work under ASP.NET and Services, it's just not supported. There can be issues with high load (running out of unmanaged resources), memory or resource leaks (badly implemented or called dispose patterns) and/or dialogs being popped when there's no desktop to show them on.

Testing will take care of the latter, and monitoring will alert you to the former. But, if/when you have a problem, don't expect to be able to call PSS and ask for a fix.

So, what are you options? Well, if you don't need a completely supported route, and you don't expect extreme load - a lot of folks have disregarded the MSDN caveat and used System.Drawing with success. A few of them have been bitten, but there's alot more success than failure stories.

If you want something supported, then you need to know if you're running interactively or not. Personally, I'd probably just leave it up to the hosting app to set a non-interactive flag somewhere or other. After all, the app is in the best position to determine if they're in a hosted environment and/or want to risk the GDI+ issues.

But, if you want to automagically detect your environment, I suppose there's worse answers than are offered <a href="https://stackoverflow.com/questions/200163/am-i-running-as-a-service#200183">right here on SO</a> for a service. To summarize, you can either check the EntryAssembly to see if it inherits from ServiceBase, or try to access System.Console. For ASP.NET, along the same lines, detecting HttpContext.Current should be sufficient.

I'd think there'd be a managed or p/invoke way to look for a desktop (which is really the defining factor in all this, I think) and/or something off the AppDomain which would clue you in. But I'm not sure what it is, and MSDN is less than enlightening on it. 

Edit: Trolling MSDN, I recalled that it's actually a <a href="http://alt.pluralsight.com/wiki/default.aspx/Keith.GuideBook/WhatIsAWindowStation.html" rel="nofollow noreferrer">Window Station</a> (which hosts a desktop) that's the important bit here. With that info, I was able to find <a href="http://msdn.microsoft.com/en-us/library/ms683225(VS.85).aspx" rel="nofollow noreferrer">GetProcessWindowStation()</a> which returns a handle to the current window station. Passing that handle to <a href="http://msdn.microsoft.com/en-us/library/ms683238(VS.85).aspx" rel="nofollow noreferrer">GetUserObjectInformation()</a> will get you a <a href="http://msdn.microsoft.com/en-us/library/ms686892(VS.85).aspx" rel="nofollow noreferrer">USEROBJECTFLAGS</a> struct with should have a dwFlags with WSF_VISIBLE if you have a visible desktop.

Alternatively, <a href="http://msdn.microsoft.com/en-us/library/ms682644(VS.85).aspx" rel="nofollow noreferrer">EnumWindowsStations</a> will give you a list of stations which you could check - WinSta0 is the interactive one.

But, yeah, I still think just having the app set a property or something is the much easier route....

Edit again: 7 years later, I get clued into <a href="https://msdn.microsoft.com/en-us/library/system.environment.userinteractive(v=vs.110).aspx" rel="nofollow noreferrer">Environment.UserInteractive</a> where MS <a href="http://referencesource.microsoft.com/#mscorlib/system/environment.cs,7d2f1469d916fc63" rel="nofollow noreferrer">does the exact GetProcessWindowStation dance</a> I described above for you....I'd still recommend delegating to the hosting app (they may well want the faster, but slightly riskier System.Drawing path), but UserInteractive seems a good default to have without having it pinvoke it yourself.

blocks|key|3137434|text|尽管没有得到官方的支持，但多年来我在高容量web服务器(+web应用程序和web服务)上广泛使用了System.Drawing类，没有造成任何性能或可靠性问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3137435|我认为确定代码是否可以安全使用的唯一方法是使用{}语句测试、监视和包装任何具有外部资源的对象。|3137436|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Even though it's not officially supported, I've used the System.Drawing classes extensively on a high-volume web server (both web application and web services) for years without it causing any performance or reliability problems. 

I think the only way to determine if the code is safe to use is to test, monitor, and wrap any object with external resources in using{} statements.

According to <a href="http://msdn.microsoft.com/en-us/library/system.drawing.aspx" rel="noreferrer">MSDN</a>, it is not a particularly good idea to use classes within the System.Drawing namespace in a Windows Service or ASP.NET Service. Now I am developing a class library which might need to access this particular namespace (for measuring fonts) but it cannot be guaranteed that the host process is not a service.

Now there is a less optimal method I can fall back to if System.Drawing is unavailable, but if it is possible, I would rather use classes in System.Drawing. So what I would like to do is to determine at runtume if System.Drawing is safe or not, and if it is, use it, otherwise fall back to the suboptimal option.

My problem is: How could I possibly detect if System.Drawing is safe to use?

I think I should either

<ul>
<li>Detect if the current process is a Windows Service or ASP.NET service</li>
<li>Detect if GDI is available</li>
<li>Or maybe there is a way to ask System.Drawing.dll itself if it is safe to use</li>
</ul>

Unfortunately, I cannot come up with a way to implement any of these approaches. Does anyone have any idea?

System.Drawing in Windows or ASP.NET services

根据的说法，在Windows服务或ASP.NET服务中使用System.Drawing命名空间中的类并不是一个特别好的主意。现在我正在开发一个类库，它可能需要访问这个特定的名称空间(用于测量字体)，但不能保证宿主进程不是一个服务。现在，如果System.Drawing不可用，我可以使用一种不太理想的方法，但如果可能，我...

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

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

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

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

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