I have written an application that is used company wide. A lot of users have the tendency to leave the application open 24-7. This application is under development constantly as the Marketing department's needs change. Most changes are minor but often times need to be implemented quickly. Salesmen are often away from their desks or on the phone, so an intercom announcement does not always do the trick. The application is housed on a network file share and shortcutted to.
What I envision is something like a message popping up something like "The program will exit for an update in five minutes, please save your changes now." Is there a way to display this message and kick them from the exe remotely? I thought of maybe just having a database value that it checks periodically to see if an update is pending, but that seems like a cheap hack to me.
Your database check is as good as any other; I personally would recommend polling some service to which it subscribes that would do the same thing. If your app connects directly to the database, however, you're probably better off making the check in the database.
You'd be best off going with a ClickOnce deployment method, however. That would require a major architectural change, but would be best in the long run, IMO.
Pity it's not a web application. Deployment would be a snap!
Anyhow what I'd do is this. Make the application log users out after several minutes of inactivity.
Two approaches to unsaved work. Do nothing and therefore they loose it if unsaved when they are inactive and it logs them out.
As they work, a local journal of changes is kept. When they are logged out due to inactivity, logging back will use the journal to open things back up as they were.
EDIT: To prevent users from using the old version. Write a database field with a version or build number. If running version < version in db field then refuse login, and/or restart program to load new image.
You can set up a central server that the .exe sends requests to to find out when updates are available.
I would recommend that you look into WCF as a framework for your solution; there are many great references for the framework as well as posts on sites like this one. You can probably spin up a separate thread in your application that checks for updates every X minutes.
As for your specific question, "Is there way to display this message and kick them from the exe remotely?", yes it is possible, but it is more feasible to make the program automatically query for the update.
If you want to shut them down for update remotely, then you have to know where they are on the network. If the program periodically contacts a central database, then there is no need for the server to know where the program is on the network, the program can automatically reach out to the server from wherever it is.
You could use a messaging system such as RabbitMQ, or any other one, and have the applications listen to a channel in the system. Then an administrative application could send a message to the user applications forcing them to shut down.
If the changes aren't breaking changes, you might want to look at something like ClickOnce which allows you to publish updates to applications while the users are running them, though users will be running old versions of the application until it restarts.
I didn't get what you got stuck on. Just create a timer, and on user interaction, reset the timer, to e.g. 5 minutes. Then, when the timer fires, show the message box, and create another timer, when that one fires, just kill the current process.
Rather tangential answer but if the issue is people leaving workstations up and logged on then take a look at something like nightwatchman from www.1e.com that powers down the PC after x period of inactivity. Sell it to your company as "doing your bit for the environment" and saving wasted electricity costs.
Related
I want to build an application to email field workers in our company when their passwords have expired. I'll be using some type of C# application while communicating with Active Directory.
I also want to ensure that users do not get emailed every single day/night, as this sounds a bit obnoxious. The idea I have is to create a web application with no UI, and have a global list of emailed users that never gets reset, just gets updated (user gets added when they are emailed, and get removed when their password is no longer expired). So I'll fill that list with a user object containing their samaccountname and the day they were emailed. If they are in the list, I don't want to email them again.
However, upon doing some reading, I found that multiple sources said that having a non-interactive web application to be executed on a schedule isn't a good way to do it. Instead, it seemed people were fond of Windows Services, which is something I don't know a lot about.
What would best practice to implement something like this? My ideas might also be completely off. Thanks for any insight.
Edit: New idea - Perhaps using an SQL table would be a better idea than a global list.
Yes, you're absolutely right about the storage, sql or nosql should do the job.
My advice is to store the the information you have describied in some database, this way you will have secure and long-living storage about the data (scenarios like power-cut, network drop or even simple restart of the server won't lead to loosing the information about the send emails).
Using the task scheduler with simple console application will be just fine. It sound more close to your needs (executing checks and notification at periods).
How do I send email on daily, weekly and monthly bases using c#.net?
I was thinking of creating a windows service application but I don't know how to do it and if it's the right way to take.
Your thoughts are greatly appreciated.
A windows service is probably the best option.
In your service have a timer that fires with whatever resolution you need (every minute/hour/day etc) and on the timer tick even send your emails.
There are many tutorials for creating windows services with .NET.
A Windows service will do the trick. A good benefit of a Windows service is that it starts up when Windows starts up (or can be set to, anyway). So the machine can be left fairly unattended (as a good server should) and doesn't need anybody logged into it for the service to run. So if that's an important consideration for your scenario then perhaps a Windows service would be the way to go.
If you just want to create a console application instead (which can generally be easier to create/test/debug) then you can schedule it with the native Windows task scheduler. However, unless I'm mistaken, I think a user needs to be logged in to the machine in order for it to run. At least under certain circumstances. So a Windows service is probably your best bet for an unattended task.
As for creating the service, Visual Studio should have a project template for that. The scheduling would be handled with a Timer.
You could also use the Windows Task Scheduler. Quartz.Net seems to be the right tool, too (never used it though).
Windows Service is a good choice.
Remember to save state to disk (file or database) because service restart (for example, due to a reboot) is possible. For example, your next email delivery is a week in the future, you have to save that date to disk. So when your server is down due to a power failure 3 days later and recover after another day, your Windows Service can still set the right timer according to the date saved to disk.
Create a console application, which would be launched from the Windows task scheduler. Creating a windows service is unnecessarily complex, IMO, since you are simply having the program execute in response to time intervals; not other unpredictable external events where you would need a 'listener' type application. KISS!
I have a number of Windows servers. I want to run one copy of the same Windows Service (written in .NET) on each of the servers such that at any one time only one of them is "active" and all the others are passive. If the active windows service dies then a very short time later one, and only one, of the remaining passive windows services becomes active.
Any ideas of simple ways to achieve this?
Well you need to keep them in sync, the easiest way to go would be to have an entry somewhere in a database that they can all access. Have the active service update a particular row etc. every so many minutes. If an update isn't found within a specific amount of time, the other services can take that as the active one has gone offline. Of course your problem here is that if the database goes off line, then the services will have problems, so that is potentially a single point of failure. You can alleviate this by having the db clustered as well though.
You could have them all communicate with each other like a peer to peer network too, but that will be more work, for essentially the same outcome, although this approach does have it's benefits.
It has become apparent that where I work needs, internally, a "notification system". The issue being that we are very spread out throughout multiple buildings and the bulk of the work force regularly keeps there email closed for hours at a time.
I need to create a simple way to be able to push out a message and have it "pop up" on everyones computer(or a single computer).
My first thought was to write a windows service that calls a winform/wpf app that resides on each computer that simply pops up with the message. Not sure how viable an idea that is but this is just brain-storming.
A different route, I thought, could be an app that resides in the systray on each computer that polls a db table and using the Query Notifications could pop up a message each time a new row is added. Then simply create an insanely basic app for writing a row to that table.
So, what I am asking is if any one else has walked this path. If so, how?
What things did you take into
consideration?
Are either of my ideas valid starting
points or are "egg and my face in
perfect alignment"?
Is there a different way that is even
simpler?
Thanks
Some simple requirements --> Must be "One Way" as I cannot give our user base a "chat" system. Must be, somewhat, hidden so as to discourage users shutting it off. A la system tray or service.
Wouldn't net send save you reinventing the wheel?
I've never done this but I've worked in a call-centre that did use something similar and they're insanely useful. I remember once when everyone got a message saying "does anyone know Mandarin? HELP ME!!" Brilliant. (Luckily someone did.)
Anyway your ideas are perfectly fine. Personally I'd do this as a client/server application. A windows forms or WPF application that sits in the systray could link to a server using a TCP/IP duplex connection using WCF. Perhaps get the client to register to certain groups depending on the department of the PC it's sitting on.
Then when someone wants to send a message they select which group it needs to go to (or all groups), the message hits the server which sends out to all connected clients, and the WPF app on the computer receives the message and pops it up. You don't even need a database except to store the users/groups, and the message history if you need to.
This might be a ridiculous answer but have you considered implementing a chat system? It's simple to implement and well tested.
Here are some possibilities:
http://messenger.softros.com/
http://en.wikipedia.org/wiki/Instant_messaging#User_base
Article on building your own:
http://www.computerworld.com/s/article/9002059/How_to_build_your_own_corporate_IM_system_
The easiest way to do this is to have a simple client on each machine polling a central service for alerts. Each alert should have a unique id so each client can deal with idempotency (you don't want the central service keeping tabs on which clients have "popped up").
I also recommend having a reasonably short lifespan for each alert, so the client only needs to know a very short list of alerts it has displayed and so if a machine was re-started, only a small history of alerts would be displayed.
With 300 subscribers, you'll want the polling to involve a nice long gap too - you don't really want 300 checks every 10 seconds - so you'll have to balance the technical desire for long gaps between checks with the business requirement to get an alert within a certain timeframe.
You could easily achieve this with a NET/TCP WCF service being polled by either a WINFORM / WPF application that is added as a start up program, or a windows service that then spawns a UI to display the notification.
I did something like this a long time ago to coordinate smoke breaks. I simply sent a broadcast packet out on the LAN at a specific port. Worked relatively well, although since anybody could broadcast and everybody would get a popup, it got abused a lot.
I would recommend you SPARK. We have same problem in my firm and finally decided to save time and do not reinventing the wheel and use existing (freeware) solution. SPARK does the job for us.
"Spark is an Open Source, cross-platform IM client optimized for businesses and organizations. It features built-in support for group chat, telephony integration, and strong security. It also offers a great end-user experience with features like in-line spell checking, group chat room bookmarks, and tabbed conversations."
If you cannot use / install existing IMs you might thing about implementing simple "chat" protocol in your app.
It is quite easy do that base on sockets and many articles available.
For example:
http://www.codeproject.com/KB/IP/TCPIPChat.aspx
http://www.codeproject.com/KB/miscctrl/SimpleMessenger.aspx?display=Print
If you need something advanced (eg. receive historical notification, users status management etc) you can consider using openSource Jabber API:
Eg http://www.codeproject.com/KB/gadgets/googletalk.aspx
i want to implement a windows service that functions as a simple license security feature for a software X. The service is meant to run independently from software X.
The rough idea:
The service is like a timebomb for a software Z installed on the machine...
Whenever the user runs software X, the service pops up a window every 30 minutes to remind the user to register software X.
If the user doesnt register the software after 1 month, the service will change the license code in a file and kill the software X process.
On the next start up, software X will read the wrong license code and starts in demo mode.
The service backs up the license code first before changing it.
When the user do register, a exe or bat file will be given for the user to run. The file restores the original license file and permanently removes the service.
Additional info:
Is it possible that if the user tries to kill the service, the service will automatically change license code and kill software X before being killed itself?
If the user changes the license code manually in the file after the service changes it, then the service will automatically change it back and kill software X.
I'm quite the newbie in programming... so i wanna ask for advice first before jumping into the project... Any advice, tips or issues/concerns i should be aware of based on your experience?
I'll most probably code it in C++ but might do it in C#(never used it before) after reading the following discussion:
Easiest language for creating a Windows service
I'm quite the newbie in programming...
so i wanna ask for advice first before
jumping into the project... Any
advice, tips or issues/concerns i
should be aware of based on your
experience?
The best advice I can give you is "newbies to programming should not attempt to write security systems". Developing a security system that actually mitigates real vulnerabilities to real attacks is incredibly difficult and requires years of real-world experience and both practical and theoretical knowledge of how exactly the operating system and framework class libraries work.
The second-best advice I can give you is to construct a detailed, accurate and complete threat model. (If you do not know how to do thread modeling then that'll be the first thing to learn. Do not attempt to rollerskate before you can crawl.) Only by having a detailed, accurate and complete threat model will you know whether your proposed security features actually mitigate the attacks on your vulnerabilities.
Whenever the user runs software X, the service pops up a window every 30 minutes to remind the user to register software X.
This is not possible. A service cannot display a window due to being on another desktop then the user. (Since Vista this is mandatory, XP did allow for showing a window.)
Is it possible that if the user tries to kill the service, the service will automatically change license code and kill software X before being killed itself?
No. A service is just another program running in the system, which can be killed at any point in time. (Only you have to be in the administrator group).
If the user changes the license code manually in the file after the service changes it, then the service will automatically change it back and kill software X.
The conclusion is, that when you break your license check into 2 parts, you get another point at which the user can break your check. You cannot prevent the user from working around your service, if it is not mandatory for your program to work.
Is it possible that if the user tries to kill the service, the service will automatically change license code and kill software X before being killed itself?
Not in general, no. If I shut down the process unconditionally (e.g. using taskkill /f command), it won't get any chance to react.
If the user changes the license code manually in the file after the service changes it, then the service will automatically change it back and kill software X.
It's possible - you can use ReadDirectoryChangesW function to watch the file and react to changes (or FileSystemWatcher class if your service is implemented in .NET). Of course, in light of the first answer above, user can just kill your service and then alter the file...
NEVER make a service for something unless it's really a system service. If you are creating an application, then you have NO BUSINESS EVER running code on the system when the application is closed unless the user explicitly requested that operation. Ideas like this are the reason we (nerds) have to deal with so much crap when people ask us to "fix my computer, it's running so slow."
I would walk from a 6-figure salary before I would ever become a part of an abomination like that.
Edit: I suppose first I'd need a 6-figure salary... some day some day