Générer par programme des documents Word éditables à partir d'ASP.NET?

Question

Le but est de générer des documents de proposition qui peuvent être modifiés manuellement dans Word après le fait, mais avant de les envoyer aux clients.

Une grande partie du contenu de la proposition serait tirée du contenu du site HTML existant (support du CMS) et aussi de l'injection personnalisée (non HTML) pour certains scénarios. Bien sûr, la logique conditionnelle pourrait entrer dans ASP.NET côté serveur pour varier le contenu de manière appropriée.

Je suis ouvert aux outils tiers si la manipulation brute de l'API Word est ardue. En fait, un bon outil tiers pourrait être la réponse.

Answer 1

Utilisez le composant Aspose Words pour .Net.

Aspose Words Component Link

Le composant comprend nativement le format de fichier Microsoft Word sans avoir à installer des produits Microsoft Office sur votre environnement d'application. Vous pouvez ensuite partir d'un modèle de mot existant ou créer par programme un document Microsoft Word entier à partir de zéro. Le modèle d'objet Word vous permet ensuite d'exporter vers doc/docx, etc. et de l'enregistrer en tant que fichier Word natif où vous le souhaitez.

Ils ont beaucoup de démos mis en place sur leur site web.

Answer 2

Je n'avais jamais utilisé d'outils tiers, car je n'ai écrit que des applications Office Automation pour les PC sur lesquels Office est déjà installé.

Créer des documents à partir de zéro, ou en les basant sur un modèle, est assez simple. Avec les modèles, vous pouvez définir des signets et des champs de fusion et publipostage pour faciliter la recherche et le remplacement des éléments de document.

Voici un certain nombre de choses que vous pouvez trouver utiles:

Arguments nommés et en option
Le modèle d'objet Word est assez facile à travailler. VB.NET était plus facile à utiliser que C#: comme les API Office Automation ont été écrites à l'origine avec VB, vous pouvez tirer parti des paramètres facultatifs. Dans les versions antérieures de C#, vous deviez spécifier chaque argument dans les appels API, ce qui était assez fastidieux. Je comprends que cela a changé dans Visual C# 2010:

Comment: utiliser Named et arguments facultatifs en programmation Bureau (C# Guide de programmation) http://msdn.microsoft.com/en-us/library/dd264738.aspx

Tutoriels
J'ai trouvé ces tutoriels très pratique:

Bureau Automatiser programmes avec VB.NET
http://www.xtremevbtalk.com/showthread.php?t=160433

VB.NET Au Bureau tomation FAQ
http://www.xtremevbtalk.com/showthread.php?t=160459

Présentation du modèle d'objet Word à partir de a.Point de vue de NET Developer
http://msdn.microsoft.com/en-us/library/aa192495%28office.11%29.aspx

précoce et la liaison tardive
Un point à mentionner: est normalement recommandé liaison tardive contre, mais il peut être très utile si vous ne savez pas quelle version d'Office sera déployée sur l'hôte de l'application. Liaison précoce a tendance à fonctionner plus rapidement, et a l'avantage de IntelliSense dans votre IDE:

utilisant une liaison anticipée et liaison tardive dans l'automatisation
http://support.microsoft.com/kb/245115

début par rapport à la liaison tardive
http://word.mvps.org/faqs/interdev/earlyvslatebinding.htm

Rechercher et remplacer
Une chose à savoir est que les objets find et replacement peuvent ne pas fonctionner comme vous le souhaitez. Plutôt que de chercher tout le document, il recherche seulement le texte principal. Si vous avez des cadres de texte dans le document, ceux-ci seront ignorés. Au lieu de cela, vous devez parcourir toutes les StoryRanges et rechercher le contenu de chacune. Voici ce que je fais dans VB.NET pour rechercher l'histoire de texte et cadres texte:

Private Sub FindReplaceAll(ByVal objDoc As Object, ByVal strFind As String, ByVal strReplacement As String) 
    Dim rngStory As Object 

    For Each rngStory In objDoc.StoryRanges 
     Do 
      If rngStory.StoryType = wdMainTextStory Or rngStory.StoryType = wdTextFrameStory Then 
       With rngStory.Find 
        .Text = strFind 
        .Replacement.Text = strReplacement 
        .Wrap = wdFindContinue 
        .Execute(Replace:=wdReplaceAll) 
       End With 
      End If 
      rngStory = rngStory.NextStoryRange 
     Loop Until rngStory Is Nothing 
    Next rngStory 
End Sub 

StoryRanges Collection Object
http://msdn.microsoft.com/en-us/library/bb178940%28office.12%29.aspx

Answer 3

Vous pouvez regarder dans XSL to generate some WordML.

Cette technique est sans aucun doute alambiquée mais vous donne beaucoup de puissance dans votre mise en page.

Answer 4

Vous ne avez pas besoin de contrôles 3ème partie pour créer un document Word. À partir de 2007, Word peut lire html en tant que document Word. Vous enregistrez simplement n'importe quelle page Web avec l'extension ".doc" et Word le triera.

Créez simplement votre page Web avec le formatage que vous voulez, puis enregistrez-la avec une extension .doc.

J'utilisé HttpWebRequest appeler l'URL (avec parmaters) à ma page, puis utilisé WebResponse et Stream pour obtenir ma page dans un tampon, puis StreamReader et StreamWriter pour enregistrer un document réel. J'ai ensuite ma propre fonction personnalisée pour télécharger le fichier.

Si quelqu'un veut mon code laissez-moi savoir

Answer 5

J'ai une longue histoire en ce qui concerne la génération de documents et publipostage. Autrefois, nous utilisions largement Office COM, même dans les applications côté serveur (ASP). Depuis des années, nous avons appris que cette approche causait beaucoup de problèmes et aujourd'hui, je préconise toujours d'utiliser Office COM (Word Automation) dans presque tous les cas. Avec l'introduction du SDK Open XML par Microsoft, nous avons réussi à créer un solide composant de fusion et publipostage beaucoup plus rapide et beaucoup plus robuste que la ou les solutions avec Office COM. Dans mon expérience, Open XML SDK permet à un développeur de créer une solution solide, mais cela demande beaucoup d'efforts et de temps pour la rendre utile et robuste.

Il y a plusieurs bons documents génération/bibliothèques de traitement sur le marché.Nous avons fini par en acheter un et, à mon avis, créer votre propre solution (basée sur Open XML SDK ou Office COM) ne rapporte jamais rien.

Actuellement, nous utilisons Docentric Toolkit qui est une bibliothèque de traitement de document à usage général et encore mieux toolkit basé sur un modèle/mail-fusion pour .NET. Il permet la conception de modèles dans MS Word, puis leur remplissage avec des données d'application et la production de documents finaux dans différents formats.