Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles
(untagged)

My experience with ASPOSE

0.00/5 (No votes)
22 Oct 2014 2  
Switching from native Word to Aspose's .Words component stabilized our server, and improved the speed of our product.

Introduction

When dealing with Word Automation in an unattended manner on the server, developers are familiar with the infamous KB article stating

Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.

After a Word install "went bad" on our server, we found a better way.

Background

A key component of our software is allowing an end user to upload a word document to the server so that sales people (generally non-technical people) can simply select the document and it merges and prints a contract, giving them a PDF of one or more selected documents.

Keeping the administrative users in control of the content is crucial. Lawyers often change verbiage on these contracts, so we need them to maintain the template within Word since it's a tool everyone knows.

We use custom document properties to store the merge fields.

Using the Code

We've been using Word on the server for many years. When used in smaller loads, using native Word worked fine most of the times. But as you can see from the quote above, stability plagued us. Over time, we had to put in a fair amount of "stability" code to handle the various instances of Word locking up on the server. Code went from:

var ids = Process.GetProcessesByName("winword").Select(p => p.Id).ToList();
var mobjApplication = new Microsoft.Office.Interop.Word.Application();

dynamic mobjDocument = null;
Type objClassType = null;

string cFormat = null;

var docs = mobjApplication.Documents;
mobjDocument = docs.Open(localFilename);

mobjApplication.Visible = false;
var newIds = (from p in Process.GetProcessesByName("winword")
              where !ids.Contains(p.Id)
              select p.Id).ToList();

System.Threading.Thread.Sleep(200);

mobjDocument.ActiveWindow.View.ShowFieldCodes = false;

to:

var tempWordPath = "/Temp/" + Guid.NewGuid().ToString() + Path.GetExtension(localFilename);
System.IO.File.Copy(localFilename, svr.MapPath(tempWordPath));
var doc = new Aspose.Words.Document(svr.MapPath(tempWordPath));

...just to open the document.

Once the doc was opened, to ensure it displayed properly in Word, we not only told it to select everything and update it properly, which worked 99% of the time, but that 1% will get you. So, we wrote additional code to find each field and update it individually.

mobjApplication.Selection.WholeStory();
mobjDocument.Fields.Update();


mobjApplication.Selection.MoveStart();
mobjApplication.Selection.MoveLeft();

foreach (var s in mobjDocument.Sections)
{
    foreach (var h in s.Headers)
    {
            foreach (var f in h.Range.Fields)
            {
                if (f.Type == (int)WdFieldType.wdFieldDocProperty)
                {
                    f.Update();
                }
            }
    }
    foreach (var h in s.Footers)
    {
        foreach (var f in h.Range.Fields)
        {
            if (f.Type == (int)WdFieldType.wdFieldDocProperty)
            {
                f.Update();
            }
        }
    }
}

While ASPOSE.Words was simply an update command:

doc.UpdateFields();

Points of Interest

As the title of this tip suggests, with continuing lockups occurring with Word on our server, switching to ASPOSE.Words really stabilized our server environment. We still don't know what's wrong with that Word installation, we can readily duplicate the problems that the automation encountered; and each time we attempt a repair or uninstall/reinstall, the problems continue and it exhausts our maintenance window.

One unforeseen benefit was that the fully merged documents are returned to our end users in a fraction of the time it previously took. Multiple documents merged into a single 100+ page PDF is displayed in less than 20 seconds from the time the print command is executed. Simply loading the Word application for a single document can take this long.

DISCLAIMER

The code provided here is incomplete and displayed simply as an example of time saved using this 3rd party application.

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here