La visionneuse qui alimente ce site est un composant .NET natif. Dans votre propre projet, c’est une référence, pas un service que vous appelez. Deux cibles de compilation : .NET Framework 4.0 et supérieur, et .NET Standard 2.0 et supérieur, ce qui la place dans .NET Core et tout ce qui suit. Le composant est Doconut.
Quelle cible vous utilisez
Choisissez en fonction de ce que le projet est déjà, pas de ce qui semble plus récent.
- WebForms ou MVC sur .NET Framework — la cible 4.0+. Aucun changement nécessaire.
- ASP.NET Core MVC ou Razor Pages — la cible .NET Standard 2.0.
- Blazor Server — la même cible .NET Standard 2.0. Le rendu se fait sur le serveur dans tous les cas, donc le modèle d’hébergement ne change pas les besoins du composant.
- Conteneurs Linux — pris en charge. C’est le chemin .NET Core, dans un conteneur.
Les deux cibles utilisent le même moteur de rendu. La cible détermine l'assembly que vous référencez, pas les formats que vous obtenez.
Ce que le navigateur installe
Rien. Pas d’ActiveX, pas de plugin, pas de Java, pas de lecteur. Le serveur transforme le document en quelque chose que le navigateur sait déjà afficher, puis l’envoie. C’est pourquoi la visionneuse se comporte de la même façon sur un poste de travail d’entreprise verrouillé que sur un téléphone : il n’y a rien du côté client qui puisse manquer ou être obsolète.
Ce que le serveur fait à la place
Tout. Le document est ouvert, mis en page et rendu sur votre machine, ce qui entraîne deux conséquences à prendre en compte.
- Office n’est pas nécessaire sur le serveur. Le moteur de rendu est natif .NET et lit les formats directement. Pas d’installation d’Office, pas d’Interop, pas de COM.
- Le rendu consomme du CPU et de la mémoire sur votre serveur. Un PDF de 200 pages et un dessin CAD de 40 Mo ne représentent pas la même charge. Dimensionnez la machine pour le plus gros fichier que vous accepterez réellement, et limitez les téléchargements à cette taille.
Ce que ce n’est pas
Ce n’est pas une bibliothèque JavaScript côté client qui ouvre les fichiers dans le navigateur, et ce n’est pas une API hébergée à laquelle vous envoyez des documents. Si vous avez besoin de l’un ou l’autre, ce n’est pas le bon composant et il vaut mieux le savoir dès le départ.
Vous voulez voir le résultat avant de référencer quoi que ce soit ? C’est le même moteur de rendu que celui de la visionneuse de ce site — téléversez un fichier et c’est ce que vos utilisateurs verront. Les licences, les paquets et la documentation API se trouvent sur Doconut.com.