Récemment, j’ai réalisé un projet de regroupement de papiers en ligne. Les principales fonctions sont la composition de textes, l’aperçu et la création d’examens. Au début, en ce qui concerne les opérations de Word, une chose qui me vient à l’esprit est la composante COM de bureau pour opérer Word. Il a fallu environ deux semaines pour écrire le code de l’ensemble du système. Ensuite, j’ai commencé à tester à plusieurs reprises, je me sentais bien localement, j’ai pu générer un texte de test de texte sans problème, et les performances étaient correctes. J’avais donc hâte de le sortir sur le serveur.
La première est qu’un composant avec CLSID {000209FF-0000-0000-C000-000000046} dans l’usine COM échoue à cause de l’erreur suivante : 8000401a Le système ne peut pas démarrer le processus serveur car l’ID de configuration est incorrect. Veuillez vérifier le nom d’utilisateur et le mot de passe. (Exception à HRESULT :0x8000401A).
Tout d’abord, tous ces problèmes sont causés par les permissions, et la solution est simplement de configurer les permissions. Non seulement utile pour Excel et Word, mais aussi pour tous les produits Office.
Pour en venir au fait, d’abord, entrez dcomcnfg dans l’exécution, ouvrez le gestionnaire de service componente->component service->mon ordinateur->DCOM-> trouvez l’application Microsoft Excel/document Microsoft Word 97-2003 correspondant, puis faites un clic droit sur l’attribut pour activer l’autorisation de démarrage suffit pour le donner à OK. -------- pas de problème, ce problème est résolu.
Parlons de la deuxième situation « problème de performance » : puisque notre système est le sous-système suivant de notre site web. Il y a donc une certaine base d’utilisateurs. Le système a été consulté par un grand nombre d’utilisateurs dès sa mise en ligne. Au début, quatre ou cinq cents articles étaient regroupés par jour, et peu à peu, le volume des articles s’est alourdi de plus en plus, ce qui a marqué le début de problèmes avec le système. La première est qu’il y a de nombreux processus winWord.exe dans ce processus. Ça ne peut pas finir. Bien que le code système contienne le processus Quit et recycle les ressources, le problème n’est jamais résolu. La conséquence d’un grand nombre de processus winword.exe est que le serveur ralentit. Cela devrait être particulièrement gourmand en mémoire pour ce composant.
Il n’y a aucun moyen de résoudre le problème. Le dernier voyou devait écrire un service de timing qui a tué le processus winword qui ne tournait pas. Cela traite les symptômes mais pas la cause profonde. 、
Je tiens à préciser ici que Microsoft Office est un logiciel d’application bureautique de bureau principalement développé pour les utilisateurs ordinaires, il possède des éléments d’interface utilisateur riches et constitue un ensemble de logiciels purement locaux ou clients. L’interface d’automatisation Word est principalement conçue pour faciliter les appels d’applications fenêtres. Par exemple, des applications natives développées par Delphi, VB, C#, Winform, etc. Bien qu’il soit possible de forcer Visible à être faux et que Word puisse fonctionner en code côté serveur, cela pose tout de même de nombreux problèmes complexes.
1. ASP.NET est basée sur l’architecture B/S. Dans l’architecture B/S, l’accès utilisateur est simultané, ce qui signifie que N utilisateurs effectuent souvent des requêtes à une page serveur en même temps. Dans ce cas, l’appel d’automatisation Word s’arrête souvent de temps à autre.
2. En raison du fonctionnement de l’interface cachée, certaines interfaces impliquant des interfaces pouvant être appelées avec succès dans le programme fenêtre échouent à appeler côté serveur, voire plantent, ce qui conduit souvent à des processus morts.
3. Parce que Word est un programme de bureau complexe et ne répond pas aux normes des services Web généraux en termes de simplicité et d’efficacité, il est lent à exécuter côté serveur, consomme beaucoup de ressources (CPU, mémoire), notamment s’il ne peut pas supporter un grand nombre d’utilisateurs à accéder simultanément, et les ressources seront rapidement épuisées.
4. La plupart des développeurs sont relativement peu familiers avec la technologie COM, et il y a souvent des erreurs de code lors de la programmation et de l’appel de l’interface Word, ce qui rend difficile de vérifier le problème, ce qui est un facteur fréquent causant des processus morts. Les processus Word dead consomment non seulement les ressources du serveur, mais font souvent que les pages serveur échouent à créer de nouveaux objets d’automatisation Word et à continuer de fonctionner. Certains internautes ont proposé une solution à processus mort : programmer pour tuer le processus mort de Word, qui consiste à traiter les symptômes mais pas la cause profonde ; le processus mort de Word a disparu, mais la fermeture anormale de Word empêchera de nombreuses ressources d’être libérées à temps. Il est difficile de dire combien de temps un tel serveur web durera.
Pour résoudre ces problèmes, après des recherches approfondies et des comparaisons, l’auteur a découvert qu’il existe un composant composant aspose.words sur Internet, qui élimine complètement les problèmes ci-dessus et il est recommandé de partager avec vous.
Ci-dessous, je partagerai avec vous une partie du code d’opération du composant aspose.words dans l’espoir qu’il sera utile à ceux qui en auront besoin
Lien original : http://blog.csdn.net/fraing/article/details/8989736
|
Publié sur 08/04/2016 16:44:24
|
|
|
Publié sur 03/05/2020 09:07:08