We Keep Coding

Are the benefits to using background workers in ASP.NET if there isn't app recycling?

Background: I have a simple ASP.NET Core 3.1 site. Very rarely (three or four times per week), a user might fill out a form that triggers an email to be sent.
I don't want to delay the page response while running the 'send email' operation (even though it only takes a second or two), so from everything I've read, it seems like the code that should handle the email should be a background worker/hosted service, and the Razor pages code should place the data object to be sent in a collection that gets monitored by the background service.
What I'm not fully understanding is why this is necessary in modern ASP.NET Core.
If I was doing this in a normal C# application (not ASP), I'd simply make the 'send email' method async (it's using MailKit, which has async methods), and call the async method without awaiting, allowing the the work be done on the threadpool while allowing the response thread to continue.
But existing answers and blog posts say that calling an async method without an await in ASP is dangerous, due to the fact that IIS can restart ASP processes (application pool recycling).
Yet, most things I've read say Application Recycling is an artifact of old ASP when memory leaks were common, and it's not really a thing on .Net Core. Additionally, many ASP applications aren't even hosted in IIS anymore.
Further, as far as I can tell, IHostedService/Background Worker objects aren't doing anything special - they don't seem to add any additional threading; they just look like singletons that have additional notification for environment startup and shutdown.
So:
Is calling a fire-and-forget async method in ASP.NET Core still considered poor practice, especially if the fire and forget task is short-lived? If so, why? [see edit below for clarification]
Other than notifications for shutdown, is there any reason why a background service is considered better than borrowing a managed threadpool thread (via Task.Run or QueueBackgroundWorkItem)? Wouldn't waking a background service (if it was awaiting on object to be placed in a collection) consume a pool thread in the same way?
Edit: I acknowledge that starting a task, and reporting success to the user, when there's a chance that operation could be terminated, is poor form. There's benefit to being notified of a shutdown and being able to finalize tasks.
Perhaps a better question is, does the old behavior of cycling still exist in modern ASP (on IIS or Kestrel)? Are there other reasons an orderly shutdown might be triggered (other than server shutdown/manual stop)?

I would still call it a poor practice.
The main concern here as well as in the referenced post is mainly about the promise of task completion.
Without being aware of the ghost background tasks, the runtime will not be able to notify the tasks to gracefully stop. This may or may not cause serious issues depending on the status of the tasks at the point the termination occurs.
Using fire forget task often means, your task is at the risk of having to start all over again when the process restarts. And sometimes this is not possible due to loss of context. Imagine your fire-forget task is calling another web API with parameters provided by a web request. The parameters are likely to get wiped out from memory if the process restarts.
And remember, the recycling is not always triggered by IIS / server. It could also be triggered by people. Say when your application runs into a memory leak issue, and you may want to recycle the app process every 1 hour as a temporary relief. Then you need to make sure you don't break your background tasks.
In terms of hosting - it is still possible to host ASP.Net Core applications in-process, in which the app pool gets recycled by IIS after a configured time period, or by default 29 hours.
In terms of lifetime - hosted services are types you register to DI, so DI features could be used, for example, this built-in hosted service implements IDisposable, which means proper clean up could be done upon shutting down.
Frankly, background tasks and hosted services both allow you to do fire and forget. But when you need reliability and resilience, hosted services win.

To answer the second half of your question, the app will wait for all hosted services' StopAsync methods to finish before shutting down. As long as you await your Tasks in the hosted service, this effectively means you can assume your Tasks will be allowed to finish running before the app shuts down. The app could still be force-shutdown, which in that case, nothing is guaranteed anymore.
If you need more guarantees about your background tasks, you should move them to run in a separate process. You could use something like Runly to make it easier to break out functionality into background jobs. It also makes it easy to provide real-time feedback to the user so that you are not lying to the user when you say "everything is done" while something is still running in the background.
Full disclosure: I cofounded Runly.

IIS background process

I have IIS server which runs few WCF REST services I created.
Now I need to add some kind of process that will run on the server and do some work for me once in a while.
I guess the IIS should initiate some kind of a background process or something, but I'm not sure what is the technology I should use in this case?

After reading at least three other similar questions, it appears the best practice is to avoid running background threads and allow a windows service app to do the processing. You could drop rows into a database table or append a line to a file to start the windows service work.
See any of these threads...
Can I use threads to carry out long-running jobs on IIS?
What are some best practices for managing background threads in IIS?

As an alternative to Windows Task Scheduler, as mentioned by others, you could also:
In your global.asax file, in your application_start() method, you can spin up a new Thread to do whatever you want, and shut it down in the application_end() method.

Check out the window task scheduler
You can schedule a process to come to life and then check to see if any component has queued up work for it to do. The work could be stored in a file (which would need to be locked) or a database table (that's my preference).

Windows Scheduled Tasks would typically be the way to do this.

Automatic code execution in ASP.NET

My task is to create an ASP.NET application with a piece of code which will automatically run every half an hour. This code must append a record to the file every half an hour. It should not depend on users requests(whether they happen or not).
1) I'm writing my code in Application.Start method of Global.asax file. Am I right?
2) Do I have anything to do with the hosting (IIS) settings (e.g. change permissions to write the file, etc)?
I have already tried just putting the code to write to file into a loop in Application.Start method and then just copied the project directory to the server. However, it didn't work.

You'll need to spawn another thread to have it execute without depending on users. Putting it in a loop in the Application.Start event will basically deadlock the app.
void Application_Start(...)
{
Thread thread = new Thread(CronThread);
thread.IsBackground = true;
thread.Start();
}
private void CronThread()
{
while(true)
{
Thread.Sleep( TimeSpan.FromMinutes( 30 ) );
// Do something every half hour
}
}

This would be the place to do this in an ASP.Net application (see Pauls post for more details on how you would do this), however running your task in this way has a number of drawbacks, not least of which is that your task will only start running when your application does (i.e. when the first user accesses your site) - if the ASP.net worker process stops and does not re-start your application for whathever reason then your "background task" will stop too.
This might be acceptable, however if it is not then my approach would be to either write this as a Windows Service or as a separate executable run every half hour by a scheduled task.
See this link for an example of how to create a simple windows service using C#:
Creating a Windows Service in C# (c-sharpcorner.com)

If you're forced to use ASP.NET, I'd recommend the technique found here, which uses the cache expiration to keep ASP.NET running and firing events on a timer. But there's always the danger that if your app dies, then the timer will not restart until a page is requested, starting the app.
There's really no way around it, so if you need something reliable, you'll need to do this differently, probably with a Windows service.

No, such code would not go in your Application_Start method. That method is called when the app first runs or when it resets and has nothing to do with "every half hour".
The best way to handle this, BY FAR, is to create a separate application, either on the same computer or on another computer that has access to "the file" (whatever that means). ASP.NET is not set up for timer events and any attempt to do that in ASP.NET will mostly likely affect the performance of your website.

Long running Windows Services

Folks,
I want to develop a long running windows service (it should be working without problems for months), and I wonder what is the better option here:
Use a while(true) loop in the OnStop method
Use a timer to tick each n seconds and trigger my code
Any other options ?
Thanks
Essam

I wouldn't do #1.
I'd either do #2, or I'd spin off a separate thread during OnStart that does the actual work.

Anything but #1
The services manager (or the user, if he's the one activating the controls) expects OnStart() and OnStop() to return in a timely fashion.
The way it's usually done is to start your own thread that keeps things running and ofcourse, listens to an event that might tell it to stop.

Might be worth considering a scheduled task with a short interval. Saves writing a lot of plumbing code and dealing with the peculiarities of Windows Services timers.

Don't mess with the service controller code. If the service wants to stop, you will only make matters worse by using #1. And BTW the service can always crash, in which case your while(true) won't help you a thing.
If you really want to have a "running windows service (it should be working without problems for months)", you'd better make sure your own code is properly and thoroughly tested using unit and integration tests before your run it as a service.

I would NOT recommend #1.
What I’ve done in the past for the exact same scenario/situation is create a scheduled task that runs ever N seconds, kicks off a small script that simply does these 2 things: #1 checks for “IsAlreadyRunning” flag (which is read from the database) #2 If the flag is true, then the script immediately stops end exits. If the flag is false, the script kicks off a separate process (exe) in a new thread (which utilizes a service to perform a task that can be either very short or sometimes really long, depending on the amount of records to process). This process of course sets and resets the IsAlreadyRunning flag to ensure threads do not kick off actions that overlap. I have a service that's been running for years now with this approach and I never had any problems with it. My main process utilizes a web service and bunch of other things to perform some heavy backup operations.

The System.Threading.Timer class would seem appropiate for this sort of usage.

Is it doing a
1 clean up task, or
2 waking up and looking to see if needs to run a task
If it is something like #2, then using MSMQ would be more appropriate. With MSMQ task would get done almost immediately.

To Thread or not to Thread when starting an external application in C#

I'm creating a win service that monitors ftp logs, when a file has been uploaded I want to start an external application, like a powershell script, to do stuff with the file. my Question is do i want to spin this off into another thread when i do it or should I just wait until it finishes before moving on.
This process is already going to be in a thread (the service is going to be monitoring multiple servers) and the idea of threads starting threads worries me. Is this something to be worried about or is this a case of too much tinfoil in my hat.

Well, code it in a modular fashion and don't worry about threads. If, down the road, you find that your application will benefit from a multi-threaded approach then address it then. If you have build your components orthogonally then the threading part will fit more naturally.
Addressing threading concerns at the very beginning of an application always feel like premature optimization to me. Build the components first and worry about how to thread them later.
[Edit] I am in no way advising you to not think about threading at all. Every component needs to be build with the potential for use by multiple threads - this is a defensive and intelligent practice in all applications. What I meant was don't worry so much about how the application will handle threads and how to set up the thread management of the application first.

I think the more important question is what do you get out of spawning another thread? If you don't need to have the code execute in parallel, then don't do it. If you do, there should be no problem. If you are concerned with the child thread creating its own thread, then delegate the thread creation to the ThreadPool.

The primary question: do you need to know the outcome of that process? If you can fire and forget, then do that - it's easier. If you need the outcome, then wait for it.
Also, have you considered using the FileSystemWatcher? It works remotely.

Although somewhat off-topic, since you mentioned that you'll be launching a powershell script, I wanted to point out the option to run the script in-process via a powershell "runspace". Here's a minimal example:
using System.Management.Automation;
static class PoshExec
{
static void Exec(string scriptFilePath)
{
(new RunspaceInvoke()).Invoke("& " + scriptFilePath);
}
}
add a reference to
c:\Program Files\Reference Assemblies\Microsoft\WindowsPowerShell\v1.0\System.Management.Automation.dll