title: Monitoring Print Spool Without Using Interop/Unmanaged Code
body: <p><strong>Background:</strong></p>
  
  <p>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.</p>
  
  <p>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:</p>
  
  <ol>
  <li>Invoke "print" action on the document</li>
  <li>Wait for document to show up in print queue</li>
  <li>Repeat until done</li>
  </ol>
  
  <p><strong>How Can I Monitor The Print Queue Using Managed Code?</strong></p>
  
  <p>I found some great examples of doing similar things using unmanaged calls (Like: <a href="http://blogs.msdn.com/b/martijnh/archive/2009/08/05/printmonitor-a-c-print-spooler-monitor.aspx" rel="noreferrer">http://blogs.msdn.com/b/martijnh/archive/2009/08/05/printmonitor-a-c-print-spooler-monitor.aspx</a>).  Also, I know how to look at the spooled files under c:\windows\system32\spool... and figure things out that way.</p>
  
  <p>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.)</p>
  
  <p><strong>Main Question: Is there really no way to monitor a print queue using only managed calls?</strong></p>
  
  <p>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.)</p>
  
  <p>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.</p>
  
  <p><strong>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?)</strong>   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..)</p>