siskinds
asked on
ASP.NET Word Mail Merge
I hope that this is a quick solution.
I have a new asp.net intranet application that retrieves data from a SQL Server DB based on user generated filters created on various aspx web pages. I have a Word Mail Merge document stored on the same webserver that already has its fields "mapped" to the fields that will be returned from this query. I have used the following link: http://www.codeproject.com/aspnet/wordapplication.asp to create the code required to perform the merge. However, when I run it I get the following error: "COM object with CLSID ###### is either not valid or not registered". This error is generated by the following line: "wrdApp = new Word.ApplicationClass();"
During development, this application was originally being hosted on my development machine which has Office 2003 installed and the merge was working, however it had to be moved to a server that does not have Office/Word installed. Even though I know that the application was instantiating the Word instance and performing the merge on the client machine and not the server (from when my dev box was hosting it) it seems that Word needs to be installed on the webserver regardless since it is not working now. This involves a fair bit of messing around so I just want to confirm before trying it...
Thanks,
John.
I have a new asp.net intranet application that retrieves data from a SQL Server DB based on user generated filters created on various aspx web pages. I have a Word Mail Merge document stored on the same webserver that already has its fields "mapped" to the fields that will be returned from this query. I have used the following link: http://www.codeproject.com/aspnet/wordapplication.asp to create the code required to perform the merge. However, when I run it I get the following error: "COM object with CLSID ###### is either not valid or not registered". This error is generated by the following line: "wrdApp = new Word.ApplicationClass();"
During development, this application was originally being hosted on my development machine which has Office 2003 installed and the merge was working, however it had to be moved to a server that does not have Office/Word installed. Even though I know that the application was instantiating the Word instance and performing the merge on the client machine and not the server (from when my dev box was hosting it) it seems that Word needs to be installed on the webserver regardless since it is not working now. This involves a fair bit of messing around so I just want to confirm before trying it...
Thanks,
John.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Installed Word 2003 on the webserver but not sure about the project references. I tried both referencing my local COM Word 11.0 Object Library and received an Access Denied error and then browsed to the Word.olb file on the webserver and received the same error.
Any ideas are much appreciated,
Thanks,
John.
Any ideas are much appreciated,
Thanks,
John.
ASKER
Sorry, forgot to mention this was also on the "wrdApp = new Word.ApplicationClass();" line....
ASKER
Okay this is getting complicated and I'm starting to get some "encouragement" from the powers that be to get ths thing running so I'm up'ing the points.
I have gone into Component Services on the server hosting the app and given ASPNET, IUSER & IWAM launch permissions to the Microsoft Word Document component with no luck. I also added the same permissions to winword.exe itself, again nothing. One post I read said something about applying the same permissions to the Word.Application component which is not there, another said something about the component being called Word Document and not Microsoft Word Document, but again it is not in Component Services.
Any help would be enormously appreciated!
Thanks,
John.
I have gone into Component Services on the server hosting the app and given ASPNET, IUSER & IWAM launch permissions to the Microsoft Word Document component with no luck. I also added the same permissions to winword.exe itself, again nothing. One post I read said something about applying the same permissions to the Word.Application component which is not there, another said something about the component being called Word Document and not Microsoft Word Document, but again it is not in Component Services.
Any help would be enormously appreciated!
Thanks,
John.
John I'm a little out of my league on this one - I've done a few projects with OLE word automation from asp (not .net) and VB (again not .net) What you're trying to do is call a windows executable from .net.
I think I've got something like this in one of my .net books, I'll see what I can find.
I think I've got something like this in one of my .net books, I'll see what I can find.
Ok I started poking around in the "How Do I" Help section of visual studio
I don't profess to know the answer, but I dug up a how to: Install Office Primary Interop Assemblies topic
(the link below goes into your Help system, not in internet explorer)
ms-help://MS.VSCC.v80/MS.M
Start with the info on that page and see if it gets you in the right direction.
I'm assuming that your application worked on your workstation, and we're still trying to get that same application working on the server.
I don't profess to know the answer, but I dug up a how to: Install Office Primary Interop Assemblies topic
(the link below goes into your Help system, not in internet explorer)
ms-help://MS.VSCC.v80/MS.M
Start with the info on that page and see if it gets you in the right direction.
I'm assuming that your application worked on your workstation, and we're still trying to get that same application working on the server.
ASKER
Hmmm, what version of help are you looking at? I've checked MSDN and VS2003 help and can't find these pages. Most of the "How Do I" stuff that I can find seems to be all XML stuff.
Hmm, I'm in Visual Studio 2005, I think all that help is new in there.
Im not sure if it applies to 2003, but here's the text of the help topic I found:
==========================
You must install the Microsoft Office 2003 primary interop assemblies in the global assembly cache (GAC) before you can create or run a Microsoft Visual Studio 2005 Tools for the Microsoft Office System solution. The interop assemblies enable managed code to interact with an Office application's COM-based object model.
The primary interop assemblies are automatically installed during a Complete installation of Office if the Microsoft .NET Framework 1.1 or later is installed. You can elect to install them during a Custom installation by following the procedure below, starting with step 5.
During a Typical installation of Office, the primary interop assemblies are set to be installed on first use if the .NET Framework is installed. This installation option works on development computers during project creation and on end user computers when an end user runs an Office solution.
The primary interop assemblies for Office 2003 products are also available in a redistributable Microsoft Windows Installer package. This package is available for download from the Microsoft Download Center (http://www.microsoft.com/downloads/details.aspx?FamilyId=3C9A983A-AC14-4125-8BA0-D36D67E0F4AD&displaylang=en).
There are six primary interop assemblies that are required for most Visual Studio Tools for Office solutions. If you install the primary interop assemblies manually, make sure that you include these:
Microsoft Office Excel 2003
Microsoft Office Word 2003
Microsoft Office Outlook 2003
Microsoft Forms 2.0 (under Office Tools)
Smart tags (under Office Tools)
Microsoft Graph (under Office Tools)
Note
When you add these assemblies, referenced assemblies such as Office.dll and microsoft.vbe.interop.dll are added automatically.
The primary interop assembly options, called .NET Programmability Support in Office Setup, only appear if the Microsoft .NET Framework 1.1 or later is already installed on the computer. The Microsoft .NET Framework is installed with Visual Studio, or is available for download from the Microsoft .NET Framework Developer Center (http://msdn.microsoft.com/netframework/downloads/updates/default.aspx?_r=1).
To install Office primary interop assemblies
In Control Panel, choose Add or Remove Programs.
Select Microsoft Office in the Currently installed programs list.
Click Change.
Select Add or Remove Features, and then click Next.
Select Choose advanced customization of applications, and then click Next.
Expand Microsoft Office Excel, click the box next to .NET Programmability Support, and then click Run from My Computer.
Expand Microsoft Office Outlook, click the box next to .NET Programmability Support, and then click Run from My Computer.
Expand Microsoft Office Word, click the box next to .NET Programmability Support, and then click Run from My Computer.
Expand Office Tools, click the box next to Microsoft Forms 2.0 .NET Programmability Support, and then click Run from My Computer.
Under Office Tools, click the box next to Smart Tag .NET Programmability Support, and then click Run from My Computer.
Under Office Tools, expand Microsoft Graph, click the box next to .NET Programmability Support, and then click Run from My Computer.
Follow the same procedure to install primary interop assemblies for any other Office applications you want.
Click Update.
The primary interop assemblies are installed in the global assembly cache.
See Also
Tasks
How to: Target Office Applications Through Primary Interop Assemblies
How to: Install Visual Studio Tools for Office
Reference
Office Primary Interop Assemblies
Concepts
Office Solutions Development Overview
Other Resources
Getting Started (Visual Studio Tools for Office)
Im not sure if it applies to 2003, but here's the text of the help topic I found:
==========================
You must install the Microsoft Office 2003 primary interop assemblies in the global assembly cache (GAC) before you can create or run a Microsoft Visual Studio 2005 Tools for the Microsoft Office System solution. The interop assemblies enable managed code to interact with an Office application's COM-based object model.
The primary interop assemblies are automatically installed during a Complete installation of Office if the Microsoft .NET Framework 1.1 or later is installed. You can elect to install them during a Custom installation by following the procedure below, starting with step 5.
During a Typical installation of Office, the primary interop assemblies are set to be installed on first use if the .NET Framework is installed. This installation option works on development computers during project creation and on end user computers when an end user runs an Office solution.
The primary interop assemblies for Office 2003 products are also available in a redistributable Microsoft Windows Installer package. This package is available for download from the Microsoft Download Center (http://www.microsoft.com/downloads/details.aspx?FamilyId=3C9A983A-AC14-4125-8BA0-D36D67E0F4AD&displaylang=en).
There are six primary interop assemblies that are required for most Visual Studio Tools for Office solutions. If you install the primary interop assemblies manually, make sure that you include these:
Microsoft Office Excel 2003
Microsoft Office Word 2003
Microsoft Office Outlook 2003
Microsoft Forms 2.0 (under Office Tools)
Smart tags (under Office Tools)
Microsoft Graph (under Office Tools)
Note
When you add these assemblies, referenced assemblies such as Office.dll and microsoft.vbe.interop.dll are added automatically.
The primary interop assembly options, called .NET Programmability Support in Office Setup, only appear if the Microsoft .NET Framework 1.1 or later is already installed on the computer. The Microsoft .NET Framework is installed with Visual Studio, or is available for download from the Microsoft .NET Framework Developer Center (http://msdn.microsoft.com/netframework/downloads/updates/default.aspx?_r=1).
To install Office primary interop assemblies
In Control Panel, choose Add or Remove Programs.
Select Microsoft Office in the Currently installed programs list.
Click Change.
Select Add or Remove Features, and then click Next.
Select Choose advanced customization of applications, and then click Next.
Expand Microsoft Office Excel, click the box next to .NET Programmability Support, and then click Run from My Computer.
Expand Microsoft Office Outlook, click the box next to .NET Programmability Support, and then click Run from My Computer.
Expand Microsoft Office Word, click the box next to .NET Programmability Support, and then click Run from My Computer.
Expand Office Tools, click the box next to Microsoft Forms 2.0 .NET Programmability Support, and then click Run from My Computer.
Under Office Tools, click the box next to Smart Tag .NET Programmability Support, and then click Run from My Computer.
Under Office Tools, expand Microsoft Graph, click the box next to .NET Programmability Support, and then click Run from My Computer.
Follow the same procedure to install primary interop assemblies for any other Office applications you want.
Click Update.
The primary interop assemblies are installed in the global assembly cache.
See Also
Tasks
How to: Target Office Applications Through Primary Interop Assemblies
How to: Install Visual Studio Tools for Office
Reference
Office Primary Interop Assemblies
Concepts
Office Solutions Development Overview
Other Resources
Getting Started (Visual Studio Tools for Office)
ASKER
Okay, here's the latest...
One of our Network Admins told me in passing that as of our last system maintenance Kerberos was no longer working correctly. Thus, when I was going into Component Manager and giving launch permissions to ASPNET it wasn't doing a thing as I was authenticating as NETWORK SERVICE.
He has now been installed into a server rack of his own...
So, after giving NETWORK SERVICE launch rights I can now create the Word.Application object. However, I get a document creation failure on the following line: wordDoc = WordApp.Documents.Add(ref missing, ref missing, ref missing, ref missing);
The error isn't actually thrown until the line after wordDoc.Select(); but its the "object ref not set..." error so I figure that's what it is.
Thanks fruhj for the Interop stuff - it was all good on my dev box, but as I custom installed Word onto the WebServer the Interops had not been installed. From what I can tell it hasn't made any difference thus far, but I feel better for it!
One of our Network Admins told me in passing that as of our last system maintenance Kerberos was no longer working correctly. Thus, when I was going into Component Manager and giving launch permissions to ASPNET it wasn't doing a thing as I was authenticating as NETWORK SERVICE.
He has now been installed into a server rack of his own...
So, after giving NETWORK SERVICE launch rights I can now create the Word.Application object. However, I get a document creation failure on the following line: wordDoc = WordApp.Documents.Add(ref missing, ref missing, ref missing, ref missing);
The error isn't actually thrown until the line after wordDoc.Select(); but its the "object ref not set..." error so I figure that's what it is.
Thanks fruhj for the Interop stuff - it was all good on my dev box, but as I custom installed Word onto the WebServer the Interops had not been installed. From what I can tell it hasn't made any difference thus far, but I feel better for it!
ok
sounds good so far.
what do you think is up with the missing references?
Did that all work on your test box?
How are you using that in your code?
If it's code you can copy and paste here, I'll drop it on a page and see if I can get it working.
sounds good so far.
what do you think is up with the missing references?
Did that all work on your test box?
How are you using that in your code?
If it's code you can copy and paste here, I'll drop it on a page and see if I can get it working.
ASKER
Another update...
I haven't forgotten about this, just was moved on to something else that is taking up time...
While I had never specified the impersonation attribute in the web.config file, I explicity set it to false and things "kind of" worked. Both the application and document objects are being created now at least! I was still getting various errors in the event log - one of which kept trying to install Access. The original merge document used Access to create the merge fields, even though during runtime the fields would be filled via a sql 2000 query that creates a Word data document. So I ended up recreating the merge document using a design time version of this data document and things really cleared up.
So as far as I can tell, the merge is working now on the webserver, however nothing happens at the client at all. You click the button and that's it - you sit there! I'm not sure if this is the correct behaviour or not?? If it is, I thought I'd try to display a link on the client page to the newly created merge document so Word would open up client side and map to this document for printing.
Thoughts?
I haven't forgotten about this, just was moved on to something else that is taking up time...
While I had never specified the impersonation attribute in the web.config file, I explicity set it to false and things "kind of" worked. Both the application and document objects are being created now at least! I was still getting various errors in the event log - one of which kept trying to install Access. The original merge document used Access to create the merge fields, even though during runtime the fields would be filled via a sql 2000 query that creates a Word data document. So I ended up recreating the merge document using a design time version of this data document and things really cleared up.
So as far as I can tell, the merge is working now on the webserver, however nothing happens at the client at all. You click the button and that's it - you sit there! I'm not sure if this is the correct behaviour or not?? If it is, I thought I'd try to display a link on the client page to the newly created merge document so Word would open up client side and map to this document for printing.
Thoughts?
ASKER
Thanks!