Monitoring Print Spool Without Using Interop/Unman

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:

Invoke "print" action on the document
Wait for document to show up in print queue
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..)

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.