用于从Excel报告创建PDF文件的体系结构(Architecture for creating PDF files from Excel reports)

用于从Excel报告创建PDF文件的体系结构(Architecture for creating PDF files from Excel reports)

我有1个例程，结构如下：

C# console C打开xl工作簿A. C然后运行A的宏M，它使用VBA将目标工作表保存为PDF C然后使用PDFsharp加密PDF文件。 C然后通过电子邮件发送此文件

目前此过程适用于一个报告，因此如果体系结构不是教科书则没有问题。

我想在未来可能会有许多不同工作簿中的许多目标工作表都会出现在许多不同的收件人身上。 如果是这种情况，则需要执行步骤2，因为我不希望将此VBA代码复制到每个目标工作簿中！ 我可以想象的唯一选择，因为我的经验有限，如下：

从Excel中取出当前的VBA代码，并使用对Excel.Interops的引用将其移动到Excel.Interops

假设目标工作表是完成的文章，即在转到PDF之前不需要进一步操作，上面是将此步骤移出VBA并进入控制台的正确方法，还是应该使用不同的库创建PDF？

I have 1 routine that is structured like this:

C# console C opens xl workbook A C then runs A's macro M which saves the target worksheet as a PDF using VBA C then uses PDFsharp to encrypt the PDF file. C then emails this file.

Currently this procedure is for one report so no problem if the architecture isn't textbook.

I imagine in the future there may be many target worksheets in many different workbooks all going to lots of different recipients. If this is the case then Step 2 will need to go as I will not want to have to copy this VBA code into every target workbook! The only alternative I can imagine as my experience is limited is the following:

Take the current VBA code out of Excel and move it into C using a reference to Excel.Interops

Assuming that the target worksheets are the finished article i.e. no further manipulation is required before going to PDF is the above the correct approach for moving this step out of VBA and into the console, or should I create the PDF using a different library?

最满意答案

最省力的选项是通过删除所有工作表/数据将代码从工作表移动到VBA加载项，然后使用“另存为”将工作簿转换为加载项，然后可以将其加载到excel和将一直可用。 根据您的编写方式，可能需要进行一些更改，但它们不会像c＃的端口那么大。

也就是说，将代码集中在一个地方将使整个过程在未来更容易被照顾。 另外，你已经有了自动化excel的C＃代码来启动VBA，所以如果你有时间的话，现在可以做得更好。

The least-effort option is moving the code from the worksheet into a VBA add-in by deleting all the sheets/data out and then use 'save as' to turn the workbook into an add-in which you can then load into excel and will be available all the time. Depending on how you've written it some changes may be required but they won't be as big as a port to c#.

That said, having the code all in one place will make the whole process easier to look after in the future. Plus you've already got C# code automating excel to fire the VBA so it may be better to do it now if you have time.