There is an application that checks the folder on ftp by timing and if it finds a newer version of the files in it than that of the user, then updates them to those in the ftp folder, but before that asks a question about whether the user wants to update. So there is a problem, there are a lot of users on the local machine, the program is started for each user in the autorun and starts working synchronously with another user running it, because of this many errors occur, including with the update files, because both programs will update the same files. Hence the question of how can you suspend the execution of the code from other users other than the current one?

  • one
    If the update direction is from the FTP folder to the client, then I don’t see a problem that several users download the same files - this is normal for the server. Or are you also updating files from a client to an FTP folder? - nzeemin
  • @nzeemin, they copy information into the same folder. at the same time, the update \ error logs are dropped into the sql server tables, the records are duplicated depending on the number of running copies of the program on the local machine, i.e. 2-3 at a time - MiXaiL
  • one
    Probably, before checking for an update, you should use a synchronization primitive, such as a mutex. Only one instance of the application can capture it. He will install the update. And when other instances get access to the update code (by taking the mutex in turn), they will find the same version on FTP that has already been installed. - Alexander Petrov
  • @Alexander Petrov I already use mutex, but it does not work for other users, i.e. If you execute the code below, mutex will consider that it is the only running copy on the local machine, although parallel to it another user has already run this copy of the program: instanceMutex = new Mutex (true, @ "Local \" + Assembly.GetExecutingAssembly (). GetType () .GUID.ToString (), out createdNew); if (! createdNew) {instanceMutex = null; Current.Shutdown (); return; } - MiXaiL
  • one
    Local prefix needs to be changed to Global so that the mutex is visible in all sessions. - Alexander Petrov

1 answer 1

I think the easiest thing is this:

  1. Get over the fact that the old versions can run forever. For example, one of the users zasospendil his session, and went on vacation for six months, when he returns, his old version will still run. Well, or require a reboot for the installation, which in itself fe.
  2. Put each version in parallel with the old one. You will have a directory with the program, and in it subdirectories with versions.
  3. Download and install the new version using the service running from the administrator account. You will avoid having to display the user UAC-windows.
  4. When the new version is downloaded, change the autorun to the new version.
  5. It makes sense to also send running copies of the message that a new version is available, so that they offer the user a restart. However, do not press on the user, he may well want to work further with this version until the end of the session. (For example, it annoys me if the program requires me to update myself straightforwardly.)
  • Update the program through another utility that "brings down" all the running images and launches the new version. But there are other files that need to be updated periodically and they can be busy by the user, so you need to ask him whether they can be released, and the user decides whether he needs it or not. The update comes in the form of a zip, which needs to be copied and unpacked, with such actions no UAC windows appear - MiXaiL
  • @ MikhailKabakov: How does it not appear? Do you have a program, I hope, is in Program Files, and not in the user's local directory or C:\MyProg , available to every virus for writing? To access from the user account in Program Files you need UAC. - VladD
  • everything is much simpler, we gave full rights to access this folder for all users) - MiXaiL
  • one
    @ MikhailKabakov: Yeah, and this is terrible. This is a gaping hole. For all users = for all viruses. If one user picks up a virus, the virus will penetrate through your hole to all users. - VladD
  • I don’t understand what could be the problem of access sharing for all users, we don’t give them any administrator rights, we just allow them to write and read in this folder, the same virus could be copied into the user's documents with the same success to launch there as well and it will be much easier to release than to look for a folder in the program files, where you can register ... - MiXaiL