We Keep Coding

I want to create a web API in ASP.NET C# that needs to run scheduled jobs from the app lets A with the inputs present in B(external system)

Since, A and B are two different system altogether, there is no way to connect these two apps directly. So, I want to create my app in such a way that It will connect to an azure function and that azure function will act as a mediator that can get inputs(Payload) from the external system B and run the jobs of A. On this, the complexity of the Payload generation & API Call is shared by the Azure & On-premise EXE. The EXE will call the right Azure Job and the Job workflow is handled by Azure . Please help me the way to build the API/console app in C#.
Without Azure function, I am not getting any options to connect to any external app to get the payloads. Need to know about the way to connect to Azure so that azure can act as a mediator to connect these two external apps.

Run a single while(true) on Azure

I'm new to Azure and I need to DoSomeWork() in Azure. This DoSomeWork() should be running periodically, every N minutes or so. However, DoSomeWork() can't be executed twice at the same time. In other words, any DoSomeWork() execution can't start before a prior DoSomeWork() execution finished.
I've been taken a look at Azure Web Jobs, particularly Continuous Azure Web Jobs. This seems the way to go but it's not clear on how to start, especially with the starting code that you get in VS:
static void Main()
{
var config = new JobHostConfiguration();
if (config.IsDevelopment)
{
config.UseDevelopmentSettings();
}
var host = new JobHost(config);
// The following code ensures that the WebJob will be running continuously
host.RunAndBlock();
}
There is also Functions class that takes an input a QueueTrigger decorated parameter, but I don't want the code to be triggered by any queue message or so.
How can I get a simple Console.WriteLine("hello world") running e.g. every minute but without overlapping? If Azure Web Jobs is not the way to go, what should I use instead (should be Azure-based)?

As mentioned in the comment, azure webjobs supports TimerTrigger feature(scheduled WebJob) which can be ran every xxx minutes as per your need.
It's quite simple when using azure webjob. For example, in visual studio, just create a console project -> Add this line of code: Console.WriteLine("hello world") -> then build the project -> then zip all the necessary files including the .exe into a .zip file -> at last, upload the .zip file into your webjob, and set the schedule(like execute the code every 5 minutes).
Please refer to this doc for more details about creating a scheduled WebJob.
You can also consider using other azure services which supports timerTrigger feature, like azure function.

WebJobs can be complicated to set up and maintain. Especially when dealing with a CI/CD pipeline. I have a few running right now and am getting ready to move them into one of the following more dependable and maintainable solutions:
The way we set up scheduled work is to use an Azure Function that runs via CRON schedule. It's super dependable and durable since it's managed by Azure. You just set it up, throw your code up and the rest is up to Azure to make sure it fires off when you configured it to.
If you want to do this in your own application, take a look at running a background service in an ASP.NET Core application. You can run a timer in the background service that will fire off and do some work. Keep in mind that if your app scales horizontally, you will be running two timers, which probably isn't good in your situation.
You could do something fancy like setting up a Azure Function to hit an endpoint on your WebAPI at a scheduled time. Then you could send the work to a BackgroundService which is singleton, so you could block a second request if you are currently running your job.
We tend to go the last route. Azure fires off a timer, the function executes, sends a message to an endpoint, the endpoint places work in the background.
There are tons of options outside of what I mentioned, but these are the only ones I have had the privilege to architect.

Appservice for UWP Onrequestrecieved

I am wondering when i create an appservice and create the on requestrecieved event handler is this even handler used if i use a timer trigger as well or is it only used when connected to by an appserviceconnection externally
What i am trying to do is create one app service that is run off a trigger(to update live tiles) and also allow an application to send it information to create targeted live tiles by using an appservice connection.
If this is answered somewhere i have been unable to find it

You will have to declare both AppService and BackgroundTask extensions separately in your appxmanifest. If you declare them both to be in-proc they will run in the same process and your scenario can then be seamlessly accomplished.
You should think of it as two different triggers though: one triggers periodically on a timer, and one triggers from an app connecting to the service. Both can trigger the same code/action of course.
Also note that the AppService doesn't need to be running in order for clients to connect to it. The operating system will start it up as needed (and shut it down when no longer needed).

Is there a way to have code run on a time schedule in an ASP.NET web app?

I have an ASP.NET web app providing access to a database on the server. What I need is a way to run code in the background on a given schedule that auto-updates the server database from another source.
I know how to do this in a windows app by adding a timer, linking up a function to the timer tick event and starting the timer. I do not know how to do this in a web app.
Is there a start-up event for a web app or somewhere where I can start this background process regardless of whatever any users are doing on the site?

You should not do this in an ASP.NET website - this is a major no-no. You are correct in thinking to use a timer on a background .exe. You should look into creating either a Windows Task (a console .exe executed by the server task timer), or a Windows Service. I would suggest the Windows Service as that is standard practice.

If you have access to the computer hosting your site I would write a little app that was run from the Task Scheduler.
The web server is not meant to handle long-running background tasks. It's the wrong tool.
If you dont have access to the hosting computer then I would suggest building some kind of interface whereby another computer rebuilt the database and uploaded it. I'm using the terms "interface" and "upload" in the loosest, broadest sense - apply your own definition.

I was searching for a solution myself couple of months ago, and even though I haven't found enough time to try it so far, I guess I can share the link with you. Maybe you'll find it helpful.
If yes, please, let me know here.
http://quartznet.sourceforge.net/
How to use Quartz.net with ASP.NET

you can use Windows Service or use Timer Control (In the Ajax Category)
Or

As other answers have stated, doing this full function - updating a database and scheduling it as an ASP.NET app is using the wrong tool for the job.
ASP.NET can be used to update a database - that's perfectly valid. Where it breaks down is in the timer. ASP.NET apps aren't meant to be long-running, which is necessary for the timer to work.
If you can do it, I'd strongly suggest using the approach others have suggested - a Windows Service or a Scheduled Task.
However, if you have no access to the actual server, other than to post ASP.NET code - you can't install a service and you can't set up a Windows app to run on a scheduled basis, here's an out-of-the box idea.
Set up a web service or ASPX page that does the update, and then call that page from a scheduled task on a machine you DO control.
So if this was at http://www.someserver.net/updatedb.aspx, there's no reason you can't set a scheduled task on your own PC to call that URL.
I'd consider this a last-ditch solution to be used only if you can't do one of the other options.

The global.asax.cs file has a method that is fired when your application starts: Application_Start. You can hook up your timer method in that event. Just beware, depending on how IIS configured, your app pool may shutdown. For example, if no one hits the site in 20 minutes for example. Just make sure if you HAVE to have this run every X minutes that you have IIS configured to ALWAYS be running and start your app. This is harder than it sounds. In the end, you may want to go with a regular windows scheduled task.

Spawning and executing a Worker process in Azure

The google has really failed me on this one. I am new to Azure and am only intermediate at .NET
I have an Azure solution going and I've written some code in a Web Role which runs great. What I would like to do now is move some of this code into an Azure Worker, which will be initialized by a controller function in the Web Role
What on earth do I need to do to get this going locally? I have created the Worker project within the SLN. I just need to know how to fire it up and run it.
I think part of my problem is I am assuming these workers behave like Heroku workers... is this the case? Because what I need is something like a queue system (a bunch of "worker tasks" in one big queue).
A lot of the links I've found for tutorials seem to tap dance around how to actually initialize the process from a Web Role.

Workers in Windows Azure are not tasks; they're entire VMs. To make your life easier, memorize this little detail: Web Role instances are Windows Server 2008 with IIS running, and Worker Roles are the same thing but with IIS disabled.
When you added that worker role to your project, you actually now have a new set of virtual machines running (at least one, depending on the instance count you set). These VMs have their own OnStart() and Run() methods you can put code into, for bootstrapping purposes.
If you grab the Windows Azure training kit, you'll see a few labs that show how to communicate between your various role instances (a common pattern being the use of Windows Azure queues). There's a good example of background processes with the Guestbook hands-on lab (the very first lab).

More info on this, as I've gotten it going now..
If you're coming from a Heroku background, then an Azure Worker is more or less the function in Rails that you'd actually execute with the queue. Unlike Heroku queued operations, an Azure Worker just runs endlessly and keeps polling for new stuff to do... hence the templated sleep(10000) in the Run() function.
The most conventional way I've found to make a Web and Worker talk to each other is by queue messages via Azure ServiceBus which is currently NOT emulated, meaning you need a functioning Azure account to make this work, and it will work even if you are running locally. You just need internet access.
A ServiceBus message can pass an entire object over to the Worker (so long as the Worker proj has the right dependencies in it), so that's kind of nice.

I think you're just having trouble starting the azure emulator along with your worker/web roles? Just set the azure configuration project as the start up project and run that. It'll boot up the emulator along with all your roles.