Клиенты Windows, использующие кэшированную копию .Net 4.0 exe, расположенную на сетевом общем диске

1866
Kishore A

У нас есть исполняемый файл .Net 4.0 ( MyProg.exe ) и связанные библиотеки, которые развернуты в общей сетевой папке с помощью XCopy. MyProg.exe и его dll все неподписаны.

Они установлены на общем сетевом ресурсе, поэтому несколько пользователей могут использовать одну и ту же версию программы и упростить ее обновление. Это работало хорошо для многих наших клиентов уже много лет.

Для недавнего клиента папка на виртуальной машине Windows Server 2012 является общей сетевой папкой. Пользователи запускают программу с другого терминального сервера (Windows Server 2012).

Когда мы обновили MyProg.exe (до версии 2.0 с 1.0), сервер терминалов не запускает новый исполняемый файл, пока он не будет перезапущен. Он продолжает загружать версию 1.0, даже если этот exe больше не доступен. Кажется, что работает кешированная версия MyProg.exe V1.0 .

  1. Шаги, которые я попробовал:
    1. Закройте все экземпляры программы
    2. Скопируйте новый MyProg.exe в папку и перезапишите файлы (обновленная версия exe с 1.0 до 2.0)
    3. Проверьте версию 2.0 файла MyProg.exe на странице « Свойства» >> «Сведения» как на файловом сервере, так и на сервере терминалов.
    4. Убедитесь, что MyProg.exe V2.0 запускается при запуске с файлового сервера с использованием файла ярлыка (цель: \\ Server \ MyProg \ MyProg.exe )
    5. Запустите тот же файл ярлыка (цель: \\ Server \ MyProg \ MyProg.exe ) с сервера терминалов, и MyProg.exe V1.0 запустится
    6. Переименуйте \\ Server \ MyProg в \\ Server \ MyProg1 и убедитесь, что терминальный сервер не может запустить ярлык, поскольку эта папка больше не существует.
    7. Создайте новый файл ярлыка (Traget: \\ Server \ MyProg1 \ MyProg.exe ) и убедитесь, что MyProg.exe V2.0 работает на клиенте
    8. Переименуйте папку \\ Server \ MyProg1 обратно в \\ Server \ MyProg, и при запуске исходного файла ярлыка продолжается загрузка MyProg.exe V1.0 до перезапуска сервера терминалов.
    9. Я проверил, что автономные файлы отключены на терминальном сервере
    10. Я подтвердил, что не могу перезаписать исполняемый файл MyProg.exe, когда программа работает на сервере терминалов.

Что еще можно проверить, чтобы выяснить причину, по которой исполняется более старая версия исполняемого файла, даже если этот файл больше не существует?

1
Ваше предположение о кеше было бы неверным. В Windows нет механизма, который бы кэшировал такой файл. Ramhound 10 лет назад 0

1 ответ на вопрос

0
Kishore A

Contacted Microsoft Technical Support team. They mentioned it could be caused by these settings for SMB. We modified these settings and will keep an out during the next update.

http://technet.microsoft.com/en-us/library/ff686200(v=WS.10).aspx

The settings from the above link did not work.
More details that helped us to figure out the issue: Client Computer is a Windows Terminal Server

This knowledge base article gives more information in this regard:
https://support.microsoft.com/kb/2536487

Applications may crash or become unresponsive if another user logs off Remote Desktop session in Windows Server 2008 or Windows Server 2008 R2

Symptoms:

When running an application from a mapped drive, the application may become unresponsive or crash for a user (or multiple users) when another user logs off. For example:

  1. One server is a file server and another is a Remote Session Host server (terminal server).
  2. A folder on the file server is mapped for use by remote users connecting to the RDS server.
  3. An application on the mapped share is launched by multiple users.
  4. One user logs off, and this causes the other users of the application to experience an application crash or unresponsiveness.

Specifically, the behavior is caused when either the first user or the last user of the application logs off, depending on version. Windows Server 2008 will experience this issue when the first user logs off; Windows Server 2008 R2 will experience this issue when the last user logs off.

Cause:

This occurs due to the way in which the redirector handles the FCB (File Control Block) for the binary in question. In Windows Server 2008, the FCB is owned by the user who first opened the file and this FCB is used by subsequent users. When the first user logs off, the FCB is orphaned which caused the subsequent users of the application to crash or become unresponsive. In Windows Server 2008 R2, the FCB is owned by the last user to open the file and prior users experience the issue if the last user logs off

Workaround :

Install the application locally on terminal server instead of on a network share

У меня такая же проблема, как вы ее решаете? Alejandro-2988924 7 лет назад 0
@ Alejandro-2988924 Я должен был установить программу локально. Я не нашел решения. Установка программы локально была официальной рекомендацией Microsoft. Kishore A 7 лет назад 1