Click here to Skip to main content
15,885,176 members
Articles / Productivity Apps and Services / Microsoft Office / Microsoft Word
Tip/Trick

My experience with ASPOSE

Rate me:
Please Sign up or sign in to vote.
5.00/5 (5 votes)
22 Oct 2014CPOL2 min read 11.9K   4  
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:

C#
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:

C#
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.

C#
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:

C#
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, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


Written By
Chief Technology Officer
United States United States
Chief Technology Officer of a software development firm in Chandler, AZ. I enjoy all aspects of my job, especially when I get to flex my creative side on the UX front. Life's not all about 1's and 0's.

Personally I enjoy spending time with my wife and 8 kids, and gaming when I get the chance. I can usually still beat the kids, so I like to stay sharp.

Comments and Discussions

 
-- There are no messages in this forum --