2

I have some code that prints a document using the System.Drawing.Printing namespace. This now needs to be moved into a windows service. The documentation states that this is not possible, which would support my findings so far (in that it doesn't work). I'm working under the assumption that I can get this to work by using the System.Printing namespace instead.

Here is the code that I have so far:

private Metafile myDoc;

myDoc = GetEmfDoc();

PrintServer ps = new PrintServer("\\server1\printer1");
EnumeratedPrintQueueTypes[] flags = { EnumeratedPrintQueueTypes.Local };
PrintQueueCollection queues = ps.GetPrintQueues(flags);

PrintQueue pq = queues.First<PrintQueue>();                
pq.AddJob("JobName", ?);

So I want to pass myDoc to pq.AddJob(), but this doesn't seem to be possible. Using System.Drawing.Printing it was possible to simply render this on a page by page basis in the PrintDocument.PrintPage event.

Is what I'm trying to do possible, and if so, could someone point me in the right direction?

user247702
  • 23,641
  • 15
  • 110
  • 157
Paul Michaels
  • 16,185
  • 43
  • 146
  • 269
  • Have you tried to configure the service to logon as "Local System Account" + check the "Allow service to interact with desktop" box? – Simon Mourier Apr 14 '12 at 16:38
  • So far, this is the closest I've come to a solution. Using the System.Drawing.Printing.PrintDocument works if this flag is set, and no call is made to PrintSettings.IsValid. – Paul Michaels Apr 16 '12 at 19:31

3 Answers3

3

Classes within the System.Drawing.Printing namespace are not supported for use within a Windows service or ASP.NET application or service. Attempting to use these classes from within one of these application types may produce unexpected problems, such as diminished service performance and run-time exceptions.

It is important to understand what "not supported" means in this context. It literally means what it says, it you try to print from a service and discover a problem then you cannot call Microsoft Support and ask for help.

This is not a problem that's induced by System.Drawing, it is a generic problem with printer drivers. Chunks of code that are supplied by the printer manufacturer, not Microsoft. A significant problem with them is that they are invariably designed to be used from a desktop program. Word, Acrobat, etcetera. They readily take advantage of that, they often pop up a window to let you know that they are Working On It. Not in the least to spam the manufacturer name and reminding you that the toner cartridge is half empty. These drivers are likely to misbehave in a service. The "runtime exceptions" phrase mentioned in the note.

The worst problem with them is that they use a popup window to let you know that there's a problem. These windows are not visible when you use the printer driver from a service. So you'll have to deal with print jobs that for no discernible reason refuse to print. The "diminished service performance" phrase in the note. That's very difficult to deal with, IT staff is just powerless to have a shot at fixing the problem when they can't see any diagnostic.

Your approach doesn't solve that fundamental problem. If you really want to pursue this then contact the printer manufacturer and ask for specific advise. Don't get your hopes up, getting good answers out of hardware companies is pretty difficult.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
1

This is a combination of permission issues and Session 0 isolation...

The following might solve the problem you face although I do NOT recommend it:

IF you really want/need to make this work you will need to make a logon (beforehand!) to the remote server (in your example server1) from inside Session 0 (NOT from the "normal" user session) - either interactively (you can switch to the session 0 desktop via rundll32 winsta.dll,WinStationSwitchToServicesSession) OR via some calls (for example using WNetAddConnection2 with the proper credentials to the remote machine, unfortunately this is usable from .NET only via p/invoke or COM using WScript.Network). The credentials used for this logon need to have full permissions regarding printing on the remote machine.

Yahia
  • 69,653
  • 9
  • 115
  • 144
  • The server in question is Windows Server 2003 – Paul Michaels Apr 16 '12 at 10:31
  • @pm_2 thanks for the information BUT I don't seem to understand what this information shall tell me regarding the problem you described... perhaps you can elaborate... – Yahia Apr 16 '12 at 11:05
  • I understood that session 0 isolation didn't apply to Win Svr 2003 – Paul Michaels Apr 16 '12 at 13:19
  • @pm_2 IIRC this is not entirely true (depending on service pack/bitness etc.) – Yahia Apr 16 '12 at 14:07
  • @pm_2 another point is the rest of the problems still applies (i.e. you need to have an already authenticated connection inside the session your Windows Service is running in)... – Yahia Apr 16 '12 at 14:12
0

Are you running your service in an account that has the necessary rights to use the printer? More details in the Windows Services FAQ.

CoreTech
  • 2,345
  • 2
  • 17
  • 24