Interop Office (automatisation côté serveur)
Définition
Piloter Microsoft Office depuis le code pour ouvrir ou convertir des documents. Cela fonctionne sur un poste de travail et est explicitement découragé sur un serveur, tant par Microsoft que par tous ceux qui l'ont essayé.
Office a été conçu pour un seul utilisateur interactif au clavier. Sur un serveur gérant des requêtes concurrentes, cette hypothèse échoue de manière spécifique et familière : les processus se bloquent en attente les uns des autres, des boîtes de dialogue modales apparaissent sans que personne ne puisse les fermer, et les instances survivent à leurs requêtes jusqu'à ce que la machine manque de mémoire.
La position en matière de licences est tout aussi délicate. Un serveur qui rend des documents au nom de nombreux utilisateurs nécessite des licences de bureau qui n'étaient jamais destinées à cet usage, ce qui implique une discussion avec une équipe d'approvisionnement qui se passe rarement bien.
L'alternative est le rendu natif : une bibliothèque qui analyse le format directement et produit la sortie en processus. Pas de deuxième application, pas de couche d'automatisation, pas de processus orphelins à récupérer selon un planning.
Dans Doconut
Doconut rend nativement. Il n'y a aucune installation d'Office, aucune automatisation COM et aucune assembly d'interop partout dans le pipeline — ce qui rend également le déploiement de conteneurs simple.