I have an application that should send a log when it exits to a cloud function. This means it can take a long time to get an answer if I'm unlucky (sometimes minutes!). I don't want my application to stay in the background for that long so I just want to fire and forget the log message. I don't need 100% guarantees, but as close as possible is of course nice.
What's the best method to achieve this?
I've read the answers to this question, but it's aimed at ASP.Net applications. Is this still applicable for a WPF application that exits and disappears, potentially before there will ever be an answer from the server, or are there better ways in this case?
Thanks!
I need to create an application that will run on a server and be able to be configured to run commands at certain times. For instance, there will be a web interface allowing a user to set an engage time and a disengage time. Once those values have been saved by the user I need for the server to be able to fire off those commands precisely at the time specified each day.
I would also need to be able to set single use non recurring events that would occur... maybe 10 minutes from the time an event was triggered and have a command fired off when that 10 minute timer goes off.
I've already got a class library written that has the engage and disengage commands exposed. I would hope to be able to integrate this into whatever solution I end up with and simply be able to make calls directly to the class. Alternatively I could also compile the class library into an executable and have commands issued to it via command line. I'm hoping to not have to do the latter.
I've never written anything like this before. I've peeked a bit at Windows Services, but there is a lot of chatter out there saying that it isn't necessarily the best option. Can someone please guide me in the right direction please?
A windows service is not a bad idea, its perfect for this kind of application. Unless you end up using standard windows scheduled tasks as the trigger for your command, you need some sort of process that is always running to contain your scheduler. A windows service is an excellent candidate for this.
Using a windows service in conjunction with Quartz.NET and some sort of persistence layer so you can store your schedules (in case you need to restart the service or it crashes etc) would be a good way to go.
Alternatively, you could write an application that just adds and removes windows scheduled tasks, but considering you have existing class libraries, using Quartz.NET will fit in well with your existing libraries.
easiest solution:
make a console exe and run under scheduled task in windows.
Let web page to accept user input and modify a configuration file.
First of all sorry of asking such a dumb question, I am quite a newbie in asp.net.
So, I am supposed to do something periodically, say I am owner of site heartpatients.com (hypothetically) and I want that for each of my site user who visits the site, a message to be shown after 2hrs "Take your pills". so, basically this is all my question, how am I supposed to show this message after every 2hr (or 4, 6 whatever time)after, also how can I customize time.
One more thing, say if I have this method in a WCF service, that shows this message, how can I call that service at a particular time, and that even configured by user (say someone is taking pills after 10hrs?) So how to call that service (that particular method in service) after the time specified by user passes periodically?
I hope I made my question quite clear.
Any help is appreciated.
ASP.NET generally isn't suited as a task scheduler. The nature of the web is as a request/response system. So a web application should just sit and wait for a request, generate a response, and be done.
For any kind of back-end scheduled task, I'd recommend either:
A Windows Service
A console application scheduled to run (I think Windows comes with a task scheduler)
There are pros and cons either way. For example, a Windows Service will run from boot time and has no console UI, and is generally very manageable from a server perspective. While a console application is traditionally simpler to write and debug.
These can still share code from your web application. If your business logic and data access and all that good stuff are in their own projects/assemblies then these other applications can use those assemblies just as well. (Of course, if everything in your web application is UI-bound, that's another question entirely.)
What concerns me the most is... How do you plan to show this message to a user? Is the user just sitting on your website for hours at a time and you need to remind them to take their meds? Or do you plan to send an email or something? Maybe the example you gave doesn't really explain what you're trying to do? I'm not sure.
Running tasks in the background is one thing, but it seems to me that an entire half of your overall equation (displaying a message to the user) is sort of glazed over and not really thought through.
Check out Quartz.Net: http://quartznet.sourceforge.net/
It enables you to schedule tasks to run using cron expressions:
http://en.wikipedia.org/wiki/Cron
Lets suppose I have an .NET client application that connects to a WCF service, or perhaps a message queue. During the normal execution of the program it is possible that there might be connection losses or maybe the user has been forced to log off by the administrator, or the administrator sends a message to the app to change and login to another WCF server (e.g. some form of manual load balancing).
The client application would only know about this when any one of many low level methods ties to make a WCF call and it fails.
When such a thing happens I'd like the application and all its windows to somehow be disabled/hidden, for a dialog box / splash window to come up and do a reconnection, and once successful the windows get shown again.
How does one go about doing this? The problem I see is that the code which first finds out there is a problem is at the lowest level (i.e. maybe as a result of a button click on a dialog window that is on top of main windows). Sort of need the program to be inside out to handle it intuitively. Therefore I am assuming there are some patterns or frameworks that help with this?
Unfortunately there isn't a great way of doing this because the exceptions caused by it are going to start anyplace a WCF call can happen and go upward until something catches them. For the HTTP bindings you know when that will be because WCF only does anything when you make an explicit call, so you could catch any disconnect/timeout exceptions and deal with them appropriately.
For message queues or TCP bindings I think it might get a bit messier, but the tactic is the same. Anytime you're making a WCF call, you'll need to watch for the appropriate exceptions and then the application will have to call some function that can change the UI how you want.
I believe what you're looking for is called "exception handling". Exceptions are the way to get from the bottom to the top.
One of the possible solutions you may apply is you may call some kind of non-transactional method that will return minimal result in a fixed interval. Or if you can get the underlying socket object of the instantiated wcf client; the overhead of checking is not that huge. Though socket objects probably don't have some kind of event that is related to disconnection; you may check only if you try to communicate to the other end but I might be wrong about this.
We are making a Jabber client for our internal use in our company and somehow we need to catch the moment when the user tries to kill the program to actually restart it or just make impossible for the user to kill the client.
Is this possible?
Our Jabber client will be written in C#.
How would I go about accomplishing this?
What you are asking for has implications far beyond what you are being asked to accomplish. For example, if the process cannot be killed, how can Windows shut down normally?
I don't know your boss, so you will have to gauge their level of understanding for yourself. If a user/manager asked me for this, I would have to probe deeper to find what they really mean. My suspicion is that your users want the default close behavior to minimize to the system tray rather than exit the program, similar to most instant message clients, rather then not be able to ever close the program at all.
let me first say, this is a horrible idea.
but...if you must do it, the way I see malicious software and spam hounds do it is to create 3 running processes, one is the main process and the other two will monitor and restart any killed process. it's very difficult for the average user to kill 3 processes simultaneously.
Sounds like a virus.
Since this is internal, you could create a separate windows service that monitors the active processes. If the process of your jabber client isn't there, you could just relaunch it.
Then use permissions to keep them from accessing the Windows Service to disable it.
I think you should go ask the requirement designer what they mean by app that is impossible to "kill." What are they getting at with the word "kill"?
Not allowing a user to close their program
Prevent standard use of X button in window?
Minimize to task tray?
Not allow them to close the app in Task Manager?
Not allowing the OS to close their program
The requirement is ambiguous enough that I'd go talk to the requirement designer/boss to get a better idea of what they want.
Not only does this sound like a bad idea (it is abusive to your users) but you will not be able to prevent users from killing the process itself.
You would have to run two separate processes - one to run the application and a second one to monitor the first one and restart it if necessary.
You can't. You can make it harder, but not impossible. See The arms race between programs and users.
You'll have to reduce their user rights until they can't kill processes.
Control it with a Windows Service. Easy to do in C#. Lock down permissions to stop the service.
Note: I think the answers of "this is impossible/horrible/evil" are perhaps missing your point. A service is specifically designed 'keep going', which is what you're asking about.
More importantly, WHY are you rewriting a jabber client when so many good ones, like Miranda and Pidgin already exist? If it's for logging, you can easily do that server side on your Jabber server, and not rely on the clients.
If it's to prevent other IM services, robust firewall rules will help stop that (but it won't prevent it from the super geniuses who'll proxy AIM+Gtalk over https to their home servers).
You can catch most signals with handlers, except for SIGKILL.
You can create a watch dog windows process that respawns your application in the event it's terminated.
If you want, you can name this process something very innocuous sounding like "sysmon" so it doesn't look as sketchy.
I do hope this is a requirement for work, and not your way to bringing about the downfall of man.
sounds like you have access to the jabber client. Can you make it poll to a separate location with it's status and startup time? You aren't disabling the ability to kill it... but at least you can track it and respond from there.
Shouldn't this be controlled by your desktop group? We have PCs in a few kiosks that allow associates to check personal e-mail and stuff (Gmail, Yahoo, Hotmail, etc...), and the user permissions on those PCs will not allow users to kill processes.
Kind of annoying if IE locks up, but I can understand the reasoning.
Sounds like a case of this
Promise to suspend the users who kill your traffic logger Jabber client?
I agree that this is an awful idea.
Having said that, you'd create two programs (probably windows services). Both programs would monitor each other as well as functioning as the client. You would need shared memory that both processes could access to synch which client processes incoming requests.
You can prevent from the users to run TaskManager by GPO.
You can create your application as a Windows Service and prevent from the user kill the task manualy ( can be killed only from the services.msc )
Try to tie their hands :- )
go to actions and make a form closing event and in c# type e.cancel = true;
Unless you're really writing a virus, you should be able to block their ability to kill the process with permissions. Assuming they are all domain users and you are the admin.
I guess there would be a few cases where you would want to do this. You don't want users making security vulnerabilities. I can't exit or change any settings of Norton endpoint on my work computer, and it hasn't bothered me yet.
But if all the users are admins on their machines, and you want to make it impossible to close, and presumably impossible to start in safe made and remove... then you're asking: "How do I write malware?"