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 right here on SO 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 Window Station (which hosts a desktop) that’s the important bit here. With that info, I was able to find GetProcessWindowStation() which returns a handle to the current window station. Passing that handle to GetUserObjectInformation() will get you a USEROBJECTFLAGS struct with should have a dwFlags with WSF_VISIBLE if you have a visible desktop.
Alternatively, EnumWindowsStations 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 Environment.UserInteractive where MS does the exact GetProcessWindowStation dance 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.