Monitoring Print Spool Without Using Interop/Unmanaged Code

Question

Background:

I'm writing an application in C# using .NET 4.0. It prints a bunch of documents in a certain order. The documents are of all different types and are actually printed using ShellExecute with the "print" verb.

To make sure the order doesn't get jumbled, I'd like to examine the print queue for the printer involved. My main loop would look like:

1. Invoke "print" action on the document
2. Wait for document to show up in print queue
3. Repeat until done

How Can I Monitor The Print Queue Using Managed Code?

I found some great examples of doing similar things using unmanaged calls (Like: http://blogs.msdn.com/b/martijnh/archive/2009/08/05/printmonitor-a-c-print-spooler-monitor.aspx). Also, I know how to look at the spooled files under c:\windows\system32\spool... and figure things out that way.

Howver, none of those solutions are very satisfying ... with amount of unmanaged cod I'm calling I feel like I should just be writing the app in C++. (And not have the .NET dependency/overhead.)

Main Question: Is there really no way to monitor a print queue using only managed calls?

More general question: I come from the java world, and typically only use .NET languages when I want to do something OS specific or something that needs to interact with other things in the MS world. (For example SSIS components.)

It seems like every time I start a project I end up in this same mess: all kinds of calls to native functions, COM stuff, etc, etc.

Secondary Question: Is there something I'm missing about the .NET philosophy or implementation? (Am I just not looking hard enough for managed libraries to do things? Is .NET the wrong choice for anything that needs to do Windows-Specific things like manipulate the print queue?) I get (or think I get) that .NET is theoretically supposed to be OS-independent.. but surely most modern operating system have printers and print queues and things like that. (So if you had generic calls for doing these kinds of things, they could be implemented on each platform's version of the framework..)

Solution

Main Question: Take a look at the PrintQueue and LocalPrintServer class in the System.Printing namespace.

Secondary Question: .NET was not written to be OS-independent (sans Mono), it was written to be Windows version independent. While it would be nice only deal with managed objects and managed calls, I see this as a somewhat unrealistic expectation. The sheer size and volume of existing C and COM functions exposed by Windows makes wrapping everything a daunting task. While i'm sure Microsoft has tons of developers on the payroll, I would say that the return on investment is quite low for such an undertaking, considering the relatively easy to use COM & P/Invoke support available.

Comments

[Cody Gray]

This is precisely why the COM and P/Invoke support was made so available and easy to use. They only wrap the most common features.

[user426724]

That, works, thanks for the answer. @Cody Gray: Doesn't that negate the windows-version-independent goal though? Or are they assuming that most apps can be constructing using only the common features they wrap?

[Cody Gray]

@user: The .NET Framework was not written to be OS-independent; that part of the answer is correct. As far as dependent on particular versions of Windows, I don't see the problem. If something you want is available on all of the versions of Windows you wish to support, you just P/Invoke it. If it's not available on all the versions of Windows you wish to support, how do you propose to make it available, regardless of the framework? If the underlying OS doesn't support it, it's not supported. If you want to use new features, you have to write a fallback mechanism for their absence.

[Cody Gray]

And yes, I suspect that the theory is applications can be written using only these common features. Somewhere between 90 and 99% can, as demonstrated empirically. It's strange to me why so many people here on SO are trying to avoid using P/Invoke.

[user426724]

@Code Gary Where was this demonstrated empirically? I guess I'm trying to understand what the real goals behind the .NET framework are. Yes you can be careful about how you use P/Invoke and have fallback mechanisms (just like you can be writing your app in C++). Personally I was intent on avoiding using P/Invoke because I was under the impression .NET framework imparted all kinds of benefits to managed code -- type safety, security, some degree of platform independence. If managed code is much better than unmanaged, I'd rather use it where possible.