在我们的LOB应用程序中，有一个非常重要的打印字母使用案例，这些使用案例随后将从邮件打印并张贴出来（每天数千个）。目前的情况是在Word 97中创建字母模板，并且字段是使用基本上使用字自动操作的VB.Net应用程序从数据库中的值合并的邮件。但取决于Word 97今天不是一个好主意。我们只有一对夫妇有Word 97中安装该公司的其余部分已经转移到Office 2007的你使用什么软件进行信件模板和打印？
电脑用什么软件或技术（与.net兼容）是当今最适合这个场景。做同样的事情是更好的，但转移到Word 2007或PDF或其他东西。价格可能不是一个因素。重要的是，信函模板必须由商业用户和数据来设计，以填充来自数据库的占位符。
奖金将导入数以百计的现有的Word 97信函模板不用从头重写它们。
那么，对于各种我用水晶报表，它允许您轻松地从数据库中获取信息，并在表格报告的。您可以使用PDF或HTML格式。
这不完全是报告。我正在谈论非技术性业务人员自己创建信函模板，而不涉及IT部门。 – softveda
我公司最近刚刚处理了这个问题，我们使用更近字2003
首先，在一个服务器风格环境中使用Office产品不支持由Microsoft和我的经验，会导致你很多的痛苦。难道一个客户端机器，其中用户可以用该程序进行交互或中央服务器上（你提到的专用机）
在Vb.net应用程序运行，但这并不意味着你不能使用Office创建的模板。办公文件（.docx）是一个zip /压缩的xml文件，可以通过文本操作进行处理。
假设这个过程是基于服务器的或者没有被监控，我会推荐 a）将所有的模板升级到office文件（.docx）。 b）使用office 2007来维护模板 c）要么编写或找到一个可以获取（.docx）文件的程序，将它们解压缩并替换合并字段。 NOte这个答案取决于你的模板的复杂性。有很多程序可以处理文本替换等。 d）运行一个程序，可以将docx转换为pdf。假设文档不需要后续修改。找到一个docx到pdf是可能的。
是你的模板简单吗？还是你有嵌套的数据，文档中的条件格式和其他这样的复杂性？
几个月前，我们在公司建立了非常类似的东西。我们使用了一个名为DocIO by Syncfusion的库。用户使用带有标准邮件合并字段的MS Word（2003或2007）创建普通文档。这些文件然后被上传并存储在应用程序的数据库中。然后，我们使用DocIO库做邮件合并，传入值的数据表合并上：
byte[] templateDocument = . . .
DataTable data = . . .
Stream templateDocStream = new MemoryStream(templateDocument);
mailmergeDoc = new DocIO.WordDocument(templateDocStream);
mailmergeDoc.MailMerge.Execute(data);
我们可以再往下文档发送到浏览器这样
Response.AddHeader("Content-Disposition", "attachment; filename=merged.doc");
doc.Save(Response.OutputStream, Syncfusion.DocIO.FormatType.Doc);
Response.End();
我组织也在寻求解决类似这样的问题，我可以与你分享我发现的一些事情。我们还没有这样做，仍然处于设计阶段，所以请牢记以下几点。
您的情况还取决于邮件所需的格式 - 目前他们必须接受Word 97文档，他们是否也可以接受XML，DOCX，PDF或其他内容？
有一个叫Intelledox的商业产品，可以让你使用Word 2003（可能早于Word 2000？）作为模板设计器，然后从可以是数据库，Web服务等的数据源汇编文档。看起来像一个非常有趣的产品，取决于你的预算。这可能会对您的最终用户模板设计标准高度评价。
您可以查看Open XML SDK，它允许您以编程方式生成DOCX（Word 2007）文件。您的业务用户将在Word中生成一个模板并将其提供给开发人员，然后开发人员可能会创建一个XSLT。然后在运行时使用此XSLT以编程方式替换基本Word文档模板的内容。这不需要服务器上的Word，只是作为SDK一部分的.NET DLL。不利的一点是，每次生成新模板时都需要一些开发人员处理。
我也考虑过报告方法 - 我们使用SQL Server Reporting Services，可以用来生成合并文档。它支持Word，Excel，PDF和其他导出格式。这样做的缺点是它通常也需要开发人员来设计报告。您可以部署SQL Server Reporting Services Report Builder，这是为高级用户生成他们自己的报告。如果你考虑这个方法，确保它是SQL Server 2008（Report Builder 2.0），显然Report Builder v1.0很差。
如果邮件服务器接受XML，您可以向邮件中心提供一个XSLT文件并发送数据，而不是汇编的文档。不确定您使用的印刷厂是否接受该标准，或者是否需要在内部保存已完成文档的副本才能进行审核。
最后可能值得一看XPS format。不确定这些模板是如何设计的，它可能也是编程繁重的。
无论如何，希望这有助于您的思考！
Microsoft ReportViewer。
Office 2007 SDK是否可以处理这种开箱即用的情况？
或者，您可以通过商业Rich文本编辑器直接浏览办公室和使用wpf。
根据字母布局的复杂性，WPF可能是一个不错的选择。
它是.NET框架的一部分，因此您不必依赖任何未来可能未更新的第三方库或应用程序。这有望避免重复使用Office 97所带来的问题。
我知道你说价格不是问题，但它也是免费的。
Xpertdoc需要Word文档并运行（合并）他们有效地服务器端，内部或从云，交互和批量字母的生成。 CGU是一家大型保险集团，每天用于生成，审核，打印和邮寄数百封信函。以下是他们对此的看法： http://www.youtube.com/watch?v=xbqWiFt5dUA&feature=channel&list=UL Symetra人寿保险将其与客户关系管理（Dynamics CRM）整合在一起，在3周内整合了450封信件模板。
除非您真的想重新编码所有这些，否则我会建议创建一个安装了Word 97的虚拟机，然后将该VM分发给需要运行字母打印的人员。 –
这就是它的有效性。我们没有VM，而是安装了装有Word 97的真正的专用机器。创建虚拟机是微不足道的，问题依赖于单词97，并在将来继续使用它创建新模板。 – softveda