0

We've created a .Net Core Web Application and are deploying it as a stand-alone exe. The main reason for deploying it stand-alone was to not be dependent upon the version of .Net Core installed on the target Windows server. We'll be creating many instances of these environments.

This Web App will act as a service for a client Web App; it's critical for the service App to be up.

The question I have is: Apart from calling Process.Start() from the dependent Web App and perhaps monitoring its health is there a more appropriate way to host this exe?

Improve this question
5
  • 3
    "Apart from calling Process.Start() from the dependant Web App" this seems super bad. why would you do this? – Ewan Aug 5 '19 at 9:52
  • Is this intended to work only on the same machine where it will be accesed from (e.g. from 172.0.0.1)? Or, alternatively, it should work as a server for multiple machines? – Theraot Aug 5 '19 at 13:03
  • @Ewan thanks for the cautionary word. – user3167162 Aug 5 '19 at 23:39
  • @Theraot the Service App will probably need to be accessible from multiple machines in the future, but not immediately. – user3167162 Aug 5 '19 at 23:40
  • 1
    I have to believe that this isn't the problem it used to be. – Robert Harvey Aug 6 '19 at 4:24
0

The following makes sense: and application that launches an standalone web server alongside to a browser pointing to it. Then the application can hide, perhaps placing an icon in notification area to allow to stop the server. The application may also monitor the server for crashes, backing up logs and restarting the server if needed.

And yes, that same thing will work if you want to access the server from another machine. However, I will throw to you some extra requirements:

  • Have it start with the machine. You probably can do it by a script on start or registry configuration.
  • Ease deploying new versions. I suggest blue-green deployment (look it up).
  • Monitor the activity of the server

Ah activity... you know what? if the server deal with concurrent requests from different clients on different threads, it does not make sense to put all logs in a single file. If you do, you would be introducing synchronization among the threads to access the file, and that will slow it down. So, have a log per thread... which also brings me to: pool your threads. Futhermore, capture exceptions at request level. A broken request should not bring down the server.

Now, your server could open logs files sharing the right to read them, and then to monitor the activity you can open them for read and take statistics of reported exceptions and requests served.

Finally, I would vow for developing a service. I am assuming we are talking of Windows. Instead of doing all that work in the application that monitors the server, have a service monitor the server, then the application just issues commands to the service. You can use an EvenLog to send the monitor data.

Now, a crash in the application is no problem. There is tie between monitoring the server and any UI. In fact, you can have simple command line application to issue commands to the service, which are useful if you want to write scripts to automate tasks (for example to run from scheduled tasks). If you think that is not useful, ask an IT Admin near you.

Oh, one more thing. Your server can be the service. It can register itself as service, then start itself, and on entry it can check if it is running as service or not. However, that could make blue-green deployment harder, so plan it ahead.

Improve this answer
0

Answering my own question, a Windows Service looks appropriate here. And .Net Core supports running under it with a Nuget extension.

Here's a how to article: https://dotnetcoretutorials.com/2018/09/12/hosting-an-asp-net-core-web-application-as-a-windows-service/.

@Theraot thanks for your answer, however a Windows Service is preferable as it works out of the box.

Improve this answer
1
  • A Windows Service is what I meant at the second half of my answer. I suppose I could have been more specific. – Theraot Sep 8 '19 at 6:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.