One of the analytics that I had to have on my program was How much time do users spend on my program? It is basically a measure of how useful the users find my program that they actively keep on using it. and used to promote users to actively start using the application.
I initially thought of using Time Span between when they start the application to when they close it but the problem was that users could just keep the application open and not use it.
I currently use TotalProcessorTime (C#/VB .Net) to let management know how much time users actively spend on the application. TotalProcessorTime give the amount an application uses the CPU but this does not translate well to management because even when a user actively uses the application for a few minutes the TotalProcessorTime would be far less.
Any out of the box thinking / suggestions?
Since you want to know how much people use your software as opposed to how long your software uses the CPU (they aren't always the same thing), the way I'd do it (and I actually used this before) is to use GetLastInputInfo.
You can have a timer in your application and check every say.. 500ms if your application is the active application and GetLastInputInfo returns the system has been idle for less than some threshold (5-10sec depending on what your application does). As long as both of these two conditions hold, you can add 500ms to your application active usage.
Of course, you can still track total CPU usage as a separate statistic, but I think my way provides a more... focused usage counter for your application.
Related
How can I get the total time this application spent in the foreground, measured in milliseconds? When in the foreground, the user is actively interacting with the application. I need it for all windows installed applications every hour.
The closest solution that I found - https://learn.microsoft.com/en-us/dotnet/api/system.diagnostics.process.totalprocessortime?view=net-5.0
But this solution is per process and without consideration process state (background/foreground)
It sounds like you want to monitor end-user application use. For that I'd recommend a global hook, however, global hooks in .Net are either extremely limited or blocked. Here's a old project that uses a C++ DLL from .Net to create the actual hook: https://www.codeproject.com/articles/6362/global-system-hooks-in-net
I don't think there is a hook for when a Application / Window becomes active though. So what you might want to do is add a Mouse Hook, and then use something like http://pinvoke.net/default.aspx/user32/GetForegroundWindow.html to get the handle of the current Active Foreground Window.
Compare that handle to the last handle you retrieve. If different, record a start date/time, and then use other functions get more info about the Window in question (such as Title bar and exe name).
Then every time you detect a change, record a end date/time, calculate the difference between the start / end time, and put that into a Dictionary<Handle, Long> that tracks total ticks for each Handle.
One caveat is Alt+Tab. You might need a keyboard hook as well.
One alternative to maybe check out is this article I found:
https://www.c-sharpcorner.com/article/active-application-watcher-in-net-using-windows-forms/
Seems to also be doing what you want, but instead of it being a Mouse / Keyboard hook, it just has a Timer that fires every half second, and grabs the active foreground Window. The downside of that approach is accuracy (course even the hook isn't going to 100% precise).
If you go for the latter, I'd recommend swapping out the Timer control for something else. The System.Windows.Forms.Timer class is not precise - so it might fire every half second, but it might not - especially if the CPU Usage spikes cause of another app. Course other types of Timers are going to have issues with CPU Usage spikes, but Forms.Timer is probably the least precise of all the options available.
I have developed a .NET program for a SCADA solution to control a heavy machine but I have some problem related with time management on the application and I am looking for some wise advisory.
I use a Winforms timer to check regularly and record the values of some variables related with the process being controlled. The application spends about 40h turned on without interruptions. At the beggining the timer does it's job, at a 5 minutes time interval, it records the values to the database. But at the end of the 40 hours, the same timer without changing it's configuration is invoked only 1 time per hour.
So my question basically is "What's the best way to ensure a certain code is run on fixed periodic intervals in a program developed in C#?" I don't really need a pure real time solution, just ensure a function is called always in fixed time intervals. But those intervals are not quite critical, we are talking about 5 minutes length. Is not important how long it takes to run the code but it is important that the code is always executed on the same period of time.
Is it better option to run the application as a service rather than a regular user-space program? Is it better option to develop in C++ the "time critical" part and communicate with the C# code via sockets or so?
At the beggining the timer does it's job, at a 5 minutes time interval...
I don't really need a pure real time solution...
Windows Task Scheduler is built for this in mind. With it you can simply have it run an .exe of your choosing with optional arguments. If the schedules are static you are arguably better off setting up the schedule in the TS UI or if complex, via the COM API.
Much better than having a another process hanging about counting down when TS already does it.
I found good advice how to change system time here.
It's ok... But what is the best strategy to change system local time for the WPF client application then?
For example my application periodically gets some data from server and I can pass the server time with it.
Or may be is better to use additional thread to ask server about the server time and change local system time always...
So I don't know which approach is better...
Thanks for any clue.
It is better not to do it at all - it requires admin privileges to change system time, so your program will have to run as admin (may be acceptable in your case, but normally not a good idea).
It is also requires some effort to correctly adjust for network latency when setting time. Please check out how it is normally done, i.e. starting with NTP - Network Time Protocol.
One option is to configure windows to check time more often itself instead doing it by hand as it already implements the functionality.
I have an application which uses Active Directory intensively. I want to know if there is a way to know exactly what queries are sent and how much time they take on server side.
I can always do some sort of very basic profiler by measuring the time elapsed during the queries through Stopwatch, but it don't help neither to see the queries, nor to know if the time spent is the time the server takes to process the query, or the time lost sending and receiving data through the network or doing stuff on client side.
So is there a profiler for Active Directory similar to the one for SQL Server, or something within .NET Framework which enables to get this data?
That data isn't available - there's no profiling API for Active Directory directly. What you could perhaps do is get the time for it indirectly. If you make a similar network request to the right machine, but one for which you know there will be no processing time at all (or minimal), then you can measure the effect of network overhead.
You can then come at it from the other end. If you use Event Tracing for Windows (not supported by many profilers, but is in there for some, eg ANTS Performance Profiler), then you can track the AD events as they happen, and so separate out the time that is taken with the application from the time for these events to happen. You should then have all the bits you need in order to figure out what's going on, I think.
I have to create an app that will read in some info from a db, process the data, write changes back to the db, and then send an email with these changes to some users or groups. I will be writing this in c#, and this process must be run once a week at a particular time. This will be running on a Windows 2008 Server.
In the past, I would always go the route of creating a windows service with a timer and setting the time/day for it to be run in the app.config file so that it can be changed and only have to be restarted to catch the update.
Recently, though, I have seen blog posts and such that recommend writing a console application and then using a scheduled task to execute it.
I have read many posts talking to this very issue, but have not seen a definitive answer about which process is better.
What do any of you think?
Thanks for any thoughts.
If it is a one per week application, why waste the resources for it to be running in the background for the rest of the week.
A console application seems much more appropriate.
The typical rule of thumb that I use is something along these lines. First I ask a few questions.
Frequency of Execution
Frequency of changes to #1
Triggering Mechanism
Basically from here if the frequency of execution is daily or less frequent I'll almost always lean towards a scheduled task. Then looking at the frequency for changes, if there is a high demand for schedule changes, I'll also try to lean towards scheduled tasks, to allow no-coding changes for schedule changes. lastly if there is ever a thought of a trigger other than time, then I'll lean towards windows services to help "future proof" an application. Say for example the requirement changes to be run every time a user drops a file in X folder.
The basic rule I follow is: if you need to be running continuously because events of interest can happen at any time, use a service (or daemon in UNIX).
If you just want to periodically do something, use a scheduled task (or cron).
The clincher here is your phrase "must be run once a week at a particular time" - go for a scheduled task.
If you have only one application and you need it to run once a week may be scheduler will be good as there is no need to have separate service and process running on the system which will be idle most of the time.