Windows Clients usando uma cópia em cache do .Net 4.0 exe localizado em uma unidade de compartilhamento de rede

Question

Temos um executável .Net 4.0 ( MyProg.exe ) e dlls associados que são implementados em um compartilhamento de rede usando o XCopy. MyProg.exe e suas dlls são todos não assinados.

Nós os instalamos no compartilhamento de rede para que vários usuários possam usar a mesma versão do programa e facilitar a atualização do programa. Isso funcionou bem para muitos de nossos clientes por muitos anos.

Para um cliente recente, uma pasta na Máquina Virtual do Windows Server 2012 é compartilhada como uma pasta de rede. Os usuários executam o programa de outro servidor de terminal (Windows Server 2012).

Quando atualizamos o MyProg.exe (para a versão 2.0 de 1.0), o servidor de terminal não executa o novo executável até que ele seja reiniciado. Ele continua a carregar a versão 1.0, mesmo que esse exe não esteja mais disponível. Parece estar executando uma versão em cache do MyProg.exe V1.0 .

1. Os passos que experimentei:
   1. Feche todas as instâncias do programa
   2. Copie o novo MyProg.exe para a pasta e sobrescreva os arquivos (Versão exe atualizada de 1.0 para 2.0)
   3. Verifique a versão 2.0 do MyProg.exe em suas propriedades > > Página de detalhes tanto do servidor de arquivos quanto do servidor de terminal
   4. Verifique se o MyProg.exe V2.0 é executado quando executado a partir do servidor de arquivos usando o arquivo de atalho (target: \\ Server \ MyProg \ MyProg.exe )
   5. Execute o mesmo arquivo de atalho (target: \\ Server \ MyProg \ MyProg.exe ) no servidor de terminal e MyProg.exe V1.0 inicia
   6. Renomeie \\ Server \ MyProg para \\ Servidor \ MyProg1 e confirme que o servidor de terminal não pode executar o atalho porque essa pasta não existe mais.
   7. Crie um novo arquivo de atalho (Traget: \\ Servidor \ MyProg1 \ MyProg.exe ) e confirme se MyProg.exe V2.0 é executado no cliente
   8. Renomeie a pasta \\ Server \ MyProg1 de volta para \\ Server \ MyProg e a execução do arquivo de atalho original continua a carregar MyProg.exe V1.0 até que o servidor de terminal seja reiniciado.
   9. Verifiquei que os arquivos off-line estão desativados no servidor de terminal
   10. Verifiquei que não posso sobrescrever o executável MyProg.exe quando o programa está sendo executado no servidor de terminal.

O que mais posso verificar para solucionar o motivo pelo qual uma versão mais antiga do executável está sendo executada, mesmo quando esse arquivo não existe mais?

    

Answer 1

Entrou em contato com a equipe de suporte técnico da Microsoft. Eles mencionaram que isso poderia ser causado por essas configurações para o SMB. Nós modificamos essas configurações e manteremos uma saída durante a próxima atualização.

link

As configurações do link acima não funcionaram.
Mais detalhes que nos ajudaram a descobrir o problema: Computador cliente é um servidor de terminal do Windows

Este artigo da base de conhecimento fornece mais informações sobre esse assunto: link

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