These are turn-based games. This means that everything that has to be updated regular basis (user's income and stuff), is normally handled by scheduled job that runs a script every so often. That's your "program".
Some things can still be handled instantaniously ofcourse, like buying soldiers, sending messages, etc.

You have a web server constantly running, which invokes code in response to user actions (For example, PHP, ASP, Java code etc).

Then you have a process which runs either autonomously and continuously, or via "cron" (or some similar scheduler), to process the "turns" of the game. It's a good idea to write these two pieces of software in the same language and share code for common bits between them.

Typically I think it's better to do as much as possible in the turn processor and as little as possible elsewhere. If the player buys some troops, they don't actually get bought until the next turn (or more maybe, if there is a lead time)

Mark

In ASP.NET, you could either start up a thread which runs your own scheduler, in Application.Start event (remember to stop it again! Ensure that your thread shuts down cleanly in all cases. Don't terminate the thread, just set a flag telling it to stop when convenient, then wake it up if it's asleep)

OR you could write a standalone .NET exe which is run by the Windows task scheduler.

Either way, make sure you log absolutely everything super intensively - so you can see what's going on.

In a ASPNET app I maintain, I've written my own mini-scheduler which runs various things in a separate thread which is started when the app starts and shuts down shortly after the app stop event.

This is moderately tricky as you have to make sure the thread sync works right.

If you write a standalone exe it will be simpler. Just make sure you put any shared code inside an assembly shared by both the web app and the scheduled process runner.

Personally, I'd make the .exe a thin wrapper which just sets everything up, then calls some method inside the shared assembly.

Mark