1

I have an azure VM running as a server for my site. The site launches another VB.NET process in the backend which creates an excel and performs some formulas on them. The exe when double clicked and run on the VM works fine so there seems to be no environmental or installation issue. But when launched from the site I see that the process starts and the excel file is created, the task manager shows the process is running but it seems to go on a halt state. The exe doesn't perform any formulas and calculation that it had to do on the excel after creation. And it doesn't give any error either. The front end site just keeps waiting.

The code for launching the process is as follows.

        var proc = new Process
        {
                StartInfo = new ProcessStartInfo("App.exe")
        };
        proc.Start();
        proc.WaitForExit(); 

I don't think its a permission or rights issue as the exe does launch and start. I have given my IIS AppPool the rights to the folder as well.

Any idea what I can do to make the exe launched from the backend to work?

Cleptus
  • 3,446
  • 4
  • 28
  • 34
A I
  • 63
  • 5
  • I'm guessing that it has something to do with the user account under which the application runs. If it's run by a web application then it will be running under the same identity as the app pool for that site. You might need to look at permissions for that account or running the app under a different account. One thing I have done before is create an application as a Windows service and then use a `FileSystemWatcher` to have it act when an appropriate file appears. Not sure whether that might be of any use to you. – jmcilhinney Feb 08 '21 at 04:06
  • Web to interface and automate Excel is considered a bad practice. However, the web site in most cases will be running as a x64 bit process. As a result, you have to ensure that you install + use x64 bit version of Access. - so I would check the bit size and setup of office on that machine. So the stand alone .exe probably works since you have office x32, but when your .net code is launched from the web server, it is looking for a x64 bit version - it not clear if you using shell() to launch the .exe or using automation. You can force this issue by compiling as x86 and not use "any cpu" – Albert D. Kallal Feb 08 '21 at 04:44
  • Can App.exe run normally if it is not deployed in IIS? What is the identity of your application pool? – Ding Peng Feb 08 '21 at 05:26
  • Thank you all for your comments. Office installation is x64 bit and application is also built in Release x64 configuration. Issue still persists. Identity is ApplicationPoolIdentity. And the whole folder is given full access to the AppPool user. The app runs completely fine when run manually (double clicking the exe) Let me know if I'm missing any step to try out. – A I Feb 08 '21 at 07:20
  • 1
    Scrap the whole thing and use EPPlus to create your Excel file without Office Interop. Interop in a server context is 100% a bad idea. It'll allow you to ditch the VM too and use Azure WebApps – Caius Jard Feb 08 '21 at 12:06

0 Answers0