I have a c# application that is on a shared folder in which I have 3 or 4 people who all run the same .exe file. I need to be able to count all instances of the running process.
So far I've tried mutex and:
Process.GetProcessesByName(Process.GetCurrentProcess().ProcessName).Length;
those work if I'm trying to compute the number of instances of the .exe file I have running on my machine, but this will be running on multiple machines all pointing back to the same shared executable.
I don't want to create a file that increments and decrements depending on if a user opens or closes it for that would be unreliable.
--------edit--------------
Does anybody know how Excel does it? If the 2nd person opens the file it says that it is in use and tells you who is using it
Thank you for your help!!!
There isn't any way other than to implement some form of a licensing service or if you have privileges to the running machines.
You can tell who has a share open:
open computer management (right click my computer and select manage)
then from the tree view on the left select:
system tools> shared folders> sessions
this lists who is accessing files through shares.
there is an SO answer about sdoing this programatically:
https://stackoverflow.com/a/2418657/359135
If you really wanted to take it further and you have the admin rights you could use this info to interrogate running processes on connected machines:
tasklist.exe /S SYSTEM /U USERNAME /P PASSWORD
http://www.watchingthenet.com/how-to-view-and-kill-processes-on-remote-windows-computers.html
I am not suggesting you do any of this.. more to highlight what would be required. I would run a server somewhere that received a open, close and ping notification from your app.
the ping notification would let you identify instances that had crashed, lost connectivity or for any other reason not sent a close notification to the server app.
I have seen this done just by having a table in a DB of open session that gets written to every minute or so. I don't know how this would work for millions of users but i have seen it working well for tens of users (up to about a hundred).
EDIT:
more on pinging..
if you have server side code you can actively look for missing pings, however I would be tempted to just use a DB table and add a where clause to your select when reading open sessions:
Select
*
FROM
Session
WHERE
LastPing > DATEADD(second,-60,Now())
and I would check for an old record on insert, so that you don't get lots of old rows hanging around.
EDIT: just to be clear if you used the crazy techniques listed at the start of this answer you would have no way of knowing that someone had copied the file to their machine locally and run it. If you make the program insist that it has a connection to a particular DB or server then you have much more control.
A process on one computer cannot detect processes running on a different computer unless you set up some kind of communication between them.
You could set up a shared file as you suggest, but yes it will be unreliable.
You could run a service on some central computer and each instance has to report back to the server, but of course that will have similar reliability issues. (If one instance dies without notifying the server, the server won't realize it's still running.)
When each instance runs, it could listen at a port, record its IP and port number in a central file, and when you need a count you try to connect to each of those ports to confirm that instance is still running.
There are lots of ways you can do it, but the work is up to you. No help from the OS like you get when they're all on the same machine.
Related
Hello all,
I just created a C# application that connects to a server database, it can insert, update, search, delete the files from the database, more than this I can view all the files in a listview.
I have encountered the following problems:
1) I don't want the application to be instaled on every PC from work, I want it to be instaled on a shared drive and every PC can open the application from a folder inside that drive (I don't want them to connect remoutly to my PC). I heard that there would be an another solution, that I can put my app into a Site (I have no idea how.. never did that before);
2) I have no idea how many PC can use the application at the same time ( but somehow I don't think that should be a problem because I tried inserting into the database through SQL manager at the same time with a mate and there were no problems) but if I put the application to be shared from the same drive it could cause problems;
3 I would love some tips how to make my application work nicer ( it started getting laggy after a few show/hide text boxes and labels..
Well the most important for me would be point (1), I have no idea how can I do this, I am sure that it is possible somehow, I accepted doing this C# app without knowing like anything but now it makes me curious like hell!
Thank you in advance! (sorry for bad english)
Image:
my first C# applicatipon
You can use something like ClickOnce so the users can download and execute your app.
From the site:
You can publish a ClickOnce application in three different ways: from
a Web page, from a network file share, or from media such as a CD-ROM.
A ClickOnce application can be installed on an end user's computer and
run locally even when the computer is offline, or it can be run in an
online-only mode without permanently installing anything on the end
user's computer.
Either that or convert to windows forms application to a web based application using ASP.Net.
i created a windows application using c# and vs2008 and access2007 database .the program runs properly in my computer but when the setup is installed in the client system i get the error "your network access was interrupted access to continue close the database "
Thoughts:
Assuming the access2007 database is on a network drive... Is the drive mapped to a drive letter? If so, does that drive always show up 'enabled', or does it ever show 'disconnected'?
Is more then 1 user trying to access the DB at the same time. Usually only one user is allowed read/write access, making Access databases unpractical sometimes.
Does the Client have a wired connection? Does the network connection appear to perform well (when doing other things)?
Yesterday I faced this same problem, and I was not able to find anything useful in the Internet. I got it SOLVED! so I write here to share my case and solution:
The reason why I was getting this misleading error message was THE USER running my application: My application is a SERVICE, so user is not the one logged on the computer, but, according to the task manager, user is SYSTEM.
My service is written in Java, and it was trying to connect to a MS Access 2007 .accdb database, getting the error message "Your network access was interrupted. To continue close the database and then open it again".
If I run my service changing "log on as" from "local system account" to "this account" and I enter the user & password used to log on Windows, the problem disappears! As you see, it has nothing to do with closing database and opening it again, and it has nothing to do with network access interruption. An ERROR_ACCESS_DENIED (0x5) would have been much much clearer... ;-)
I hope this hint helps...
Our app running on client server A and creates a file on the server 2008 R2 file-server using:
CreateFile(LockFileName,
GENERIC_READ or GENERIC_WRITE,
FILE_SHARE_READ, nil,
CREATE_ALWAYS,
FILE_FLAG_WRITE_THROUGH or FILE_FLAG_DELETE_ON_CLOSE,
0);
The client is testing a disaster situation and powering off 'server A' and leaving it off.
They're reporting that our app running on 'server B' using the same filename and the same code fragment above fails (ie the file continues to exist) for at least 15 minutes until, we believe, they browse to folder containing the file in Windows Explorer at which point the file is deleted automatically.
Is anyone aware of how this is supposed to behave in this situation, where the creating server has gone away, should the handles be released and the file removed automatically? And why does looking at the file cause it to delete?
Interestingly, on another supposedly similar setup the issue does not occur.
[...] where the creating server has gone away, should the handles be released and the file removed automatically?
Eventually yes, but not immediately. As you are running Windows Server 2008 R2 (and thus SMBv2, note that I assume that both server and client are running on Windows Server 2008 R2) the client will request a durable file handle. According to the SMBv2 specification, section 3.3.6.2 and 3.3.7.1 the server must start the durable open scavenger timer (set to 16 minutes on Windows Server by default). Once the timer expires the server must examine all open handles and close those that have not been reclaimed by a client.
In your scenario of course, an open question is whether the server detects the connection loss to the client at all, as the client (i.e. the whole server, not just the process) according to your description is killed immediately.
Now assume that another client is trying to open the file while the durable timeout is still running/the server still considers the file to be open by the first client. Then it is supposed to send an oplock break notification (section 2.2.23.1) to the client that initially opened the file. As the client is unable to respond (it has been killed) the server will wait for the oplock break acknowledgment timeout to expire (section 3.3.2.1, 35 seconds by default) before it will grant the new client access to the file.
There is one other thing to note: The behavior will be different if the second client accesses the file via a local path rather than via an UNC path. In this case the client won't have to wait for the oplock break ack timeout to occur. Windows will grant him access to the file immediately while it will try to send a close request to the first client.
This is how the system is supposed to behave. As to why you are experiencing the issues described I cannot tell. I wouldn't be surprised if you'd stumbled upon a bug in the Fileserver implementation of Win Server 2008. I would try to troubleshoot the issue using the tools mentioned in the other answers (procmon is really nice) and Wireshark helps a lot too.
There is nothing to say there should no longer be any handles when the creating servers goes down. In order for a handle to be removed, something has to initiate that removal. If a server abruptly goes down, it cannot remove its handles, so those handles remain open. As far as the server still up is concerned, all is good and well, and no file handles should be forcibly closed.
Until you actually try to act upon the file handle. Suddenly, the server notices that the host of the file handle is gone, because it tries to initiate communications with said host. Once it realizes this, the file handle gets forcibly closed.
Thus, to answer your question, this seems like perfectly predictable and expected behavior to me.
The reason file handles get closed immediately in another environment probably has to do with something keeping those servers in constant communication: something is constantly accessing a remote file. That's just a guess, though.
Update
Sysinternals, bought out by Microsoft a few years ago, has a great tool called Process Explorer that allows you to search processes' open file handles. This might be of use to you in determining which program(s) are refreshing the file handle(s).
Sysinternals also has Process Monitor, which allows you to see in real-time as programs act upon file handles. This could be another useful program in troubleshooting the issue.
Edit: Oh, and if you really want to have fun, there's Handle, too.
This looks so far like a non issue to me. Or one that can not be handled outside of Microsoft's programming AND one that has side effects when hnandled. Basically you ahve to account for small disruptuons of communication between client and server and optimize network traffic, so the server can not permanently exchange packets with the client just to see whether the client is still around.
Computer programming must take that into account as far as possible, but timeouts like that are normal unless the client application handles that properly. THe main question (totally not answered) is whether this is an issue at all - so far it looks like "standard behavior".
Is anyone aware of how this is supposed to behave in this situation, where the creating server has
gone away, should the handles be released and the file removed automatically?
How would the server know?
And why does looking at the file cause it to delete?
P9ossibly it is the reading that triggered a refresh that timed out, so - at the end - this tirggered the defined behavior (DELETE_ON_CLOSE).
I would hint that any access to certain elements of the file would trigger this, but the tester did not do that excpt just refreshing the explorer.
I have made a simple application in C# and WHITE, which click on a button to clear the logs.
I use to connect to my test machine using Remote Desktop Connection and execute that application. It works fine when my session is connected but whenever i disconnect my session, it stops working.
Is there any way to execute that application when windows session is disconnected?
You could write a Windows Service.
You could also use the task scheduler.
You may not need the C# wrapper, you can add yourself the required entry within the scheduler.
It works fine when my session is connected but whenever i disconnect my session, it stops working.
This is by design. When you disconnect your session, it is locked. When your session is locked, UI automation won't work.
You could hack around this by never locking the session, possibly via different remote desktop tools (VNC/PcAnywhere). But this is definitely a hack.
Instead I suggest a different approach. I recommend avoiding UI automation whenever possible. I have always found UI automation to be flaky and unreliable.
In the comments on your question you said your app is simply UI automation to click a button to clear a log. The logs are generated by the DebugView application.
I suggest you log to a file instead. This feature is mentioned on the web site for DebugView:
http://technet.microsoft.com/en-us/sysinternals/bb896647
You could also look into using remote monitoring.
If size is an issue, you can also look into the "Log file wrapping" and "log-file rollover" features.
Taken from
https://www.ranorex.com/help/latest/ranorex-remote/remote-faq#c13444
Create a batch file on your remote machine and insert the code below:
for /f "skip=1 tokens=3 usebackq" %%s in (
`query user %username%`
) do (
%windir%\System32\tscon.exe %%s /dest:console
)
Save this batch file on the desktop of your remote machine and name it: 'KeepSessionOpen.bat'.
If you need to disconnect the RDP session, you can now simply run this batch file using administrator privileges and your remote machine will remain unlocked.
I need to save a text file on the client side possibly without permission. The case is that I need to save this text file in a shared folder in this or in another machine in the lan. This text file is going to be read automatically by the fiscal printer which will print the fiscal invoice. I have a asp .net web application and the server is not on the same lan with the fiscal printer, so I have to write it on the client-side. Any idea how to do this without asking to the user every time for the security issue.
I need a cross browser solution.
I can accept a solution like, the client is asked only one time a the first printing, but not every time he wants to print a bill. Some kind of asking permission to the client for allowing this website, in order to not repeat the permission asking.
Obviously - this would be a major security breach to download files to the user's computer without them knowing. All browsers have precautions in place to prevent this from happening.
No, you can not do this. Saving a file to a computer without permission in a public folder is not allowed.
You can, however, have your Client install your application which will have the ability to read and write where you want.
A common way that Trojan viruses to this is by giving the Client some goofy program to run that displays a fireworks show or something else quite trivial. While the Client is busy wondering what he's looking at, your virus is installing quietly in the background.
Now, you are probably saying to yourself, "But I am not installing a virus." However, there is no way for a Browser to know if your application is a virus or not. That is why it is not allowed and why you can not do it.
The more applicable scenario for me is:
1- Do your work inside your web application.
2- Get the information that you need to print.
3- Send it to another computer directly (or to a hosted web service) and this computer will act as a host for these files.
4- let your server access this shared folder, and print what you want
You could use a cookie, which won't ask permission. Of course that would only work when cookies are enabled and can store limited amounts of data.