Surveillance de la bobine d'impression sans utiliser de code interopnulant / non géré

Question

Arrière plan:

J'écris une application en C # en utilisant .NET 4.0. Il imprime un tas de documents dans un certain ordre. Les documents sont de tous les différents types et sont en fait imprimés à l'aide de Shellexcucute avec le verbe "imprimer".

Pour m'assurer que la commande ne se mélange pas, je voudrais examiner la file d'attente imprimée pour l'imprimante impliquée. Ma boucle principale ressemblerait à:

1. Invoquez une action "imprimer" sur le document
2. Attendez que le document apparaisse dans la file d'attente imprimée
3. Répéter jusqu'à ce que

Comment puis-je surveiller la file d'attente d'impression à l'aide du code géré?

J'ai trouvé d'excellents exemples de faire des choses similaires en utilisant des appels non gérés (comme: http://blogs.msdn.com/b/martijnh/archive/2009/08/05/printmonitor-ac-print-spololer-monitor.aspx). De plus, je sais comment regarder les fichiers spoulés sous C: Windows System32 Spool ... et comprendre les choses de cette façon.

Howver, aucune de ces solutions n'est très satisfaisante ... avec une quantité de morue non gérée que j'appelle, je pense que je devrais simplement écrire l'application en C ++. (Et ne pas avoir la dépendance .NET / les frais généraux.)

Question principale: n'y a-t-il vraiment aucun moyen de surveiller une file d'attente d'impression en utilisant uniquement les appels gérés?

Question plus générale: je viens du monde Java et n'utilise généralement que les langues .NET lorsque je veux faire quelque chose de spécifique ou quelque chose qui doit interagir avec d'autres choses dans le monde de la SEP. (Par exemple les composants SSIS.)

Il semble que chaque fois que je commence un projet, je me retrouve dans ce même gâchis: toutes sortes d'appels vers des fonctions natives, des trucs com, etc., etc.

Question secondaire: Y a-t-il quelque chose qui me manque dans la philosophie ou la mise en œuvre .NET? (Suis-je tout simplement ne cherche pas assez fort pour que les bibliothèques gérées fassent les choses? .Net est-il le mauvais choix pour tout ce qui doit faire des choses spécifiques à Windows comme manipuler la file d'attente imprimée?) Je reçois (ou je pense que j'obtiens) que .NET est théoriquement censé être indépendant du système d'exploitation .. mais le système d'exploitation le plus moderne a sûrement des imprimantes et des files d'attente imprimées et des choses comme ça. (Donc, si vous aviez des appels génériques pour faire ce genre de choses, ils pourraient être implémentés sur la version de chaque plate-forme du cadre ..)

Answer 1

Question principale: jetez un œil au File d'attente d'impression et Printersserver local classe dans le System.printing Espace de noms.

Question secondaire: .NET n'a pas été écrit pour être indépendant du système d'exploitation (sans mono), il a été écrit pour être indépendant de la version Windows. Bien que ce ne soit bien que les objets gérés et les appels gérés, je vois cela comme une attente quelque peu irréaliste. La taille et le volume des fonctions C et COM existantes exposées par Windows font un emballage tout une tâche intimidante. Bien que je sois sûr que Microsoft a des tonnes de développeurs sur la masse salariale, je dirais que le retour sur investissement est assez faible pour une telle entreprise, compte tenu du support COM & P / invoque relativement facile à utiliser.