0

I am working with a client's WinForms application to wrap it up as a Web Service - this is not ideal, but the only choice I have for the moment.

The WinForms app can be called via the command line with some parameters that enable it to generate some output files that I can then process and return the user. This command line interface basically launches the GUI, pre-populates some input fields (provided via command line params), generates the output files, and exits.

From my web service I am using Process.Start() to run the application, wait for it to exit, and then process the output files to return back to the client. (Although the GUI shows itself on the server, I am not expecting any user to see this).

When running in debug mode (Visual Studio 2017) using IIS Express, the code works as expected - I make the appropriate call to the web service, the WinForms application starts-up (I can see it on the screen) and does it thing, it then closes automatically, and the expected output files are found in the expected place. Basically, it all runs exactly as designed.

However, when I deploy to the same server but host under IIS (rather than IIS Express), it no longer works. When I make a call to the web service, I can see, in Task Manager, the WinForms app starting up... however it stalls immediately the UI itself does not show up. After this the memory associated with the WinForms app stays the same (at a level much lower than it is when working properly), and the API call eventually times-out.

I have changed the AppPool in IIS to use my Admin account, and all folders associated with the WinForms app have "Full Control" permission for that same Admin Account. When the WinForms app starts-up it is also associated with the same Admin account (which is also the same as the one IIS Express uses).

Could it be some thing like IIS not having the permissions to start-up an app with a GUI, but IIS Express does?

I've searched SO for similar issues, but none help with this problem (most deal with the usual folder access permissions that can arise when accessing files not under the Web Service's root directory).

The web service is being hosted on Windows Server 2016 Datacenter.

EDIT

I've made a little progress - as per one of the answers at IIS7 does not start my Exe file by Process Start but it's running in task bar I changed the app pool settings to Load User Profile = True (https://i.stack.imgur.com/2pIyr.png). Now when I try, I can see the WinForms app in Task Manager, the memory changes similar to what I'd expect, and the app seems to exit. The GUI does not show up, the expected output files are not created, and the web service process.WaitForExit() does not seem to receive the exit event (it throw an error because of the process instance is lost when the WinForms apps exits).

EDIT

Just a clarification that this is for a demo so the solution needn't reflect best practice for production.

ProfNimrod
  • 4,142
  • 2
  • 35
  • 54
  • Have you configured the "World Wide Web Publishing Service" to "Allow service to interact with the desktop"? (On my Win10pro machine, this is on the "Log On" tab, but only available when the "Local System" account is selected. – theGleep Oct 20 '17 at 21:14
  • Thanks for the suggestion. I hadn't tried that. I changed the setting and performed a reboot. This doesn't seem to have made any difference. I wonder if there is another service that needs similar permissions. – ProfNimrod Oct 20 '17 at 21:33
  • There is something called "session isolation". Learn that and understand what is the barrier between system session and your logon session, then you will see what should be done. – Lex Li Oct 20 '17 at 21:47
  • Launching a GUI process from IIS is going to be more trouble than it is worth. My guess is that the process you are starting is crashing because of permission/API restrictions that it is running into because it is running under the app pool user in a service. Add error handling/logging to that app to see what the issue is, but I would suggest rewriting that utility as a console app or DLL that you can consume from the IIS process. – John Koerner Oct 20 '17 at 22:58
  • Re-writing is not an option at the moment - it is a highly complex application for optimizing satellite communications loading. In the longer term, I totally agree. In the short term, this is the best approach as far as I can tell at this point. The App Pool is running under my admin account, so I'd be surprised if it was a simple permissions problem. As I said it works perfectly fine hosting in IIS Express. – ProfNimrod Oct 20 '17 at 23:25
  • 1
    Given that it works hosting with IIS Express, but not IIS, I wonder if self-hosting using OWIN would work... – ProfNimrod Oct 20 '17 at 23:38

1 Answers1

0

Given that the problem seems related to IIS (which I am far from fully understanding), and that running in debug mode with IIS Express works OK, and that this is for a demo (not production), I decided to simply host in IIS Express and use the Conveyor plug-in for VS 2017 (https://marketplace.visualstudio.com/items?itemName=vs-publisher-1448185.ConveyorbyKeyoti) to allow remote calls (which are not allowed with IIS Express by default).

Once Conveyor was installed and the appropriate ports opened on the server firewall (and added to the Network Interface on the Azure VM I'm using for this demo), everything worked as hoped.

This is not a long-term solution, and is certainly not a production solution, but it fits the current purpose. I can easily reject any requests that come in while the WinForms application is running.

ProfNimrod
  • 4,142
  • 2
  • 35
  • 54