Excel Interop/DCOM to OpenXml/EPPlus

Question

Excel Interop/DCOM to OpenXml/EPPlus

Alain PAPET 20

Hi,

In our server side application, clients can upload .xlsm files (after they modified a macro).

Then the server is using these .xslm as a model to create new file, add data in sheets and run the macro.

(server is doing that as jobs at night because macros are big).

Until now, we were using Excel Interop/DCOM to manage the Excel files.

But it is no longer recommended.

Its better to use OpenXml, EPPlus or any other third-party library to modify Excel file.

Unfortunately, only Excel Interop/DCOM can open the files and run the macro.

I would like to know if someone already had this problem and if there is any solution ?

Thanks for your help.

Alain.

P.S. : re-coding macros using OpenXml seems difficult as each client modify its own macro.

AgaveJoe 31,361 Reputation points

2026-06-04T18:31:46.02+00:00

Libraries cannot run VBA: Tools like OpenXML and EPPlus only read and write file data/structure. They cannot execute macros. Only the Microsoft Office desktop application has the engine to run VBA.

Massive Security Risk: Allowing clients to upload arbitrary VBA code and executing it on your server is a severe security vulnerability, alongside being completely unscalable.

You are dealing with an "XY Problem." You need to stop using Excel as a server-side calculation engine. If clients need to submit custom logic, transition them to writing Python or JavaScript, and execute those scripts on your server inside secure, isolated Docker containers.
Alain PAPET 20 Reputation points

2026-06-05T08:23:24.3366667+00:00

Hi AgaveJoe,
Thanks for your answer.
You are right security is also a big issue.
We are trying to fix all this thecnical debt on a "old" system.
Regards.
Alain.

Answer accepted by question author

0 additional answers

Your answer

AgaveJoe 31,361 Reputation points

2026-06-04T18:31:46.02+00:00

Libraries cannot run VBA: Tools like OpenXML and EPPlus only read and write file data/structure. They cannot execute macros. Only the Microsoft Office desktop application has the engine to run VBA.

Massive Security Risk: Allowing clients to upload arbitrary VBA code and executing it on your server is a severe security vulnerability, alongside being completely unscalable.

You are dealing with an "XY Problem." You need to stop using Excel as a server-side calculation engine. If clients need to submit custom logic, transition them to writing Python or JavaScript, and execute those scripts on your server inside secure, isolated Docker containers.
Alain PAPET 20 Reputation points

2026-06-05T08:23:24.3366667+00:00

Hi AgaveJoe,
Thanks for your answer.
You are right security is also a big issue.
We are trying to fix all this thecnical debt on a "old" system.
Regards.
Alain.

Answer 1

Danny Nguyen (WICLOUD CORPORATION) 7,105 Microsoft External Staff Moderator

Hi @Alain PAPET ,

Yes, this is a known limitation with server-side Office automation. Microsoft does not recommend or support automating Office applications from unattended/server-side code such as ASP, ASP.NET, DCOM, or Windows services.

Reference: Considerations for server-side Automation of Office

The document explains that Office applications are designed for interactive desktop use and may become unstable or deadlock when used in a server-side environment. It also highlights the security risk of opening uploaded files and running macros on the server, especially because macros could run with high privileges depending on the server context.

Because of that, I would generally avoid a design where customer-uploaded .xlsm files are opened and their VBA macros are executed on the server. Open XML/EPPlus can help with reading or modifying workbook data, but they are not a supported replacement for running VBA macros.

A safer approach would be to move the processing logic outside Excel, or redesign the flow so macro execution happens client-side or in a controlled/isolated environment.

Hope this helps. If you found my response helpful or informative, I would greatly appreciate it if you could follow this guidance or provide feedback.

Thank you.

Alain PAPET 20 Reputation points

2026-06-05T08:20:01.4966667+00:00

Hi Dany,
Thanks for your answer.I agree with you : client processing logic should be outside Excel.
I post my questions because our system is running since years.
And now we need to fix this debt.
And we need to do it as smoothly as possible for clients.That's why opinions/comments/ideas from other people (like you) are important for us.

Regards.

Alain.
Danny Nguyen (WICLOUD CORPORATION) 7,105 Reputation points Microsoft External Staff Moderator

2026-06-05T10:10:12.36+00:00
Hi @Alain PAPET

While I cannot give a specific example, your approach should be to keep Excel as the client-facing template/report format for now, but stop using it as the server-side calculation/execution engine. For example:

Use Open XML/EPPlus only to read/write workbook data.

Move common business logic from VBA into server-side code.

For client-specific logic, replace free-form VBA macros with a controlled model, such as configuration rules, predefined formulas, or a limited scripting interface.

If custom scripting is still required, run it in a restricted and isolated environment rather than executing uploaded VBA inside Excel on the server.

This would let clients keep a similar Excel-based workflow at first, while you gradually move the risky part — macro execution on the server — into a more controlled design.

Share via

Excel Interop/DCOM to OpenXml/EPPlus

0 additional answers

Your answer