Le chemin d'impression XPS, dans System.Printing, est-il pris en charge côté serveur?

Question

C'est une question en deux parties:

1.

Les cours d'impression .NET d'origine (en System.Drawing.Printing) ne sont pas pris en charge sur le côté serveur. (Voir http://msdn.microsoft.com/en-us/library/system.drawing.printing(VS.80).aspx)

Je pense que les nouvelles classes d'impression basées sur XPS (dans System.Printing) sont supportées côté serveur, par ex. dans les applications ASP.NET et les services Windows, mais je ne peux pas le prouver. Et Microsoft n'a pas répondu à mes questions à ce sujet.

Quelqu'un sait-il ici?

La nouvelle impression à base XPS parfois faire une conversion interne à GDI. C'est le cas lorsque le seul pilote disponible est un ancien pilote, même si l'application imprime avec les nouvelles classes d'impression. Voir http://msdn.microsoft.com/en-us/library/ms742418.aspx. Les nouvelles classes sont-elles sécurisées pour une utilisation côté serveur dans cette situation?

• Pour clarifier - il s'agit entièrement de l'impression de serveur. Aux fins de cette discussion, il n'y a aucun navigateur Web impliqué du tout. Un serveur, service Windows ou asp.net, doit imprimer directement un document sur une imprimante connectée au serveur.

Merci.

Answer 1

Comme indiqué dans mon commentaire ci-dessous, il n'existe aucune solution prise en charge pour l'impression côté serveur dans le code managé pur. Mais, Aspose vient de publier du code qui vous permet d'imprimer des documents XPS à partir de code managé (en utilisant PInvoke avec succès pour appeler l'API d'impression XPS). [Pour mémoire, je crois que la recommandation initiale de Microsoft contre l'utilisation de PInvoke pour appeler XPS print était simplement parce que c'est une API difficile à interagir avec PInvoke. Mais Aspose semble avoir réussi, ce qui est une bonne nouvelle, car cela supprime le besoin d'impliquer une DLL séparée non managée.]

Dans l'ensemble, la solution Aspose semble être la manière la plus simple d'imprimer des documents complexes depuis Services ASP.NET et Windows.

Détails ici: http://www.aspose.com/documentation/.net-components/aspose.words-for-.net-and-java/howto-print-a-document-on-a-server-via-the-xpsprint-api.html

Answer 2

Si vous essayez d'obtenir l'impression du navigateur de l'utilisateur à partir du code du serveur, oubliez-le. Le mieux que vous devriez espérer est d'envoyer une page au navigateur avec du code javascript qui appelle window.print().

Answer 3

Le support .Net XPS fait partie de WPF. L'utilisation de WPF dans les services Windows n'est pas prise en charge (voir MSDN). Par conséquent, l'impression XPS avec .Net, y compris l'utilisation de System.Printing, n'est pas non plus prise en charge pour les services. La même réponse s'applique à la partie "conversion au GDI" de la question car ce processus se produit automatiquement (dans le cas où le contenu XPS est imprimé dans une file d'attente où le pilote n'est pas XPS, l'infrastructure convertit automatiquement le contenu XPS aux appels DDI attendus par le pilote si une application basée sur GDI était en cours d'impression). Pour le développement côté serveur (services) où l'impression XPS est requise, des API Win32 sont disponibles dans Windows 7. Spécifiquement, consultez l'API XPSPrint qui fournit un accès au chemin d'impression XPS et prend en charge la conversion automatique pour les files d'attente d'impression non-XPS ainsi que les API disponibles pour manipuler le contenu XPS et travailler avec des tickets d'impression.

Answer 4

Je ne pense pas que vous avez besoin de ces API ASPnose.

Il est un exemple de code pour faire exactement cela ici:

https://groups.google.com/forum/?fromgroups#!msg/pdfnet-sdk/fOuGOvx06Tk/EckAX-ga2i8J