0

I am using Microsoft.Office.Interop.Excel nuget package with asp.net mvc project. I am trying to read excel files. Everything works perfectly on my localhost but when i publish them to my hosting it gives 500 error on this line;

Application xlUygulama = new Application();

Everything is ready for use, so i don't want to change framework.

Eugene Astafiev
  • 47,483
  • 3
  • 24
  • 45
Larches
  • 51
  • 7
  • The version of the Interop has to match the version of Office installed on machine I assume new Application is calling the Interop and cannot find the Interop. The error 500 indicates an internal error in server while processing the request. It can be anything in the code. When publishing check the all the executables in the bin folder on the build machine are also in the same folder as the executable on the deploy machine. You have a web application and often 500 errors are due to not having permission to access resources on server. It may not be the Excel App. – jdweng Sep 25 '22 at 05:17
  • hm thats sad. Cause its'a hosting, and i can't rdp connection. probably i'cant install excel. :S – Larches Sep 25 '22 at 11:10
  • Use OLEDB to read excel : https://www.connectionstrings.com/excel/ – jdweng Sep 25 '22 at 11:39
  • "it gives 500 error" - see https://stackoverflow.com/questions/5385714/deploying-website-500-internal-server-error to obtain the actual error, so you can research it further. Without the actual exception message, we can but guess. – CodeCaster Sep 30 '22 at 15:30

1 Answers1

1

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.

If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution.

Read more about that in the Considerations for server-side Automation of Office article.

If you deal with open XML documents only you may consider using the Open XML SDK instead, see Welcome to the Open XML SDK 2.5 for Office instead. In other cases consider using any third-party components designed for the server-side execution.

Eugene Astafiev
  • 47,483
  • 3
  • 24
  • 45