-2

after updating to WINDOWS 11 getting silly error from Compiler (Compiler do not want compile line which contains Microsoft.Interop.Word). But before update everything worked just fine (I mean on Windows 10 ) . Is someone get same error . Thank you in advance

Code:

    Object oMissing = Missing.Value;
    string exp = "";
    MemoryStream stream = new MemoryStream();
    var app =new Microsoft.Office.Interop.Word.Application();
    app.Visible = true;
    var doc = app
            .Documents
            .Open(docLocation);

enter image description here

More Details about error :

Eugene Astafiev
  • 47,483
  • 3
  • 24
  • 45
FarHard112
  • 35
  • 4
  • Which version of Microsoft Office is installed on your machine? – Pranav Bilurkar Mar 02 '23 at 19:00
  • Microsoft Office Professional Plus 2019 – FarHard112 Mar 02 '23 at 19:06
  • 1
    According to [Considerations for server-side Automation of Office](https://support.microsoft.com/en-us/topic/considerations-for-server-side-automation-of-office-48bcfe93-8a89-47f1-0bce-017433ad79e2): _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_ – Tu deschizi eu inchid Mar 02 '23 at 19:08
  • try updating to the latest version of Office – Pranav Bilurkar Mar 02 '23 at 19:11
  • Read the knowledge base article that @user09938 references, and then give up on what you are trying to do. Running any Office app in a server process (like an ASP.NET app) is a ticket to having your app do _bad things_, generally at the worst possible time. There's really no way to get it to work – Flydog57 Mar 02 '23 at 19:15
  • 1
    You are lucky if you had such code working previously without issues. Do not ever use automation on the server-side, consider the Open XML SDK if you deal with open XML documents or any thord-party components designed for the server-side execution. – Eugene Astafiev Mar 02 '23 at 22:20
  • You also have to install the version of office that matches the x32 or x64 settings on your project. If you installed office x32, then you need to FORCE your project to x32 (don't use ANY cpu, and don't use x64). And then in web settings, make sure you set the web settings to run as x32. And of course if you have office x64, then of course your project thus has to be forced to x64 bits. However, as pointed out, automation of office from a web server is not a good idea. It not thread safe, but worse while your dev box will and can have office installed, your web server likely will not. – Albert D. Kallal Mar 03 '23 at 05:28
  • Worse yet, you OFTEN find that on a server, the web pool does NOT have sufficient permissions to automate (use) office as a COM object. So, suggestions here that this is a poor idea is good advice. – Albert D. Kallal Mar 03 '23 at 05:29
  • Any working solution? I ended up with the same problem after upgrading Win11 upgrade to 22H2. – Tom C. Jun 06 '23 at 13:05

1 Answers1

1

Using Office automation on the server-side (Asp.net) is not really a good idea. 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 for more information. Otherwise, consider using any third-party components designed for the server-side execution that don't require Office applications installed on the server.

Here is what MS states for such scenarios like yours:

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.

Eugene Astafiev
  • 47,483
  • 3
  • 24
  • 45
  • Open XML SDK is definitely better option if it satisfies your requirements. However, Office as COM object offers e.g. reliable DOC(X)->PDF or XLS(X)->PDF conversion. – Tom C. Jun 07 '23 at 10:47