Clientes Windows usando uma cópia em cache do .Net 4.0 exe ​​localizada em uma unidade de compartilhamento de rede

Question

Temos um executável .Net 4.0 (MeuProg.exe) e DLLs associadas que são implantadas em um compartilhamento de rede usando XCopy. MyProg.exe e suas DLLs não estão assinadas.

Nós os instalamos no compartilhamento de rede para que vários usuários possam usar a mesma versão do programa e para 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 oMeuProg.exe(para a versão 2.0 a partir de 1.0), o servidor de terminal não executa o novo executável até que seja reiniciado. Ele continua carregando a versão 1.0 mesmo que o exe não esteja mais disponível. Parece estar executando uma versão em cache doMeuProg.exe V1.0.

1. As etapas que tentei:
   1. Feche todas as instâncias do programa
   2. Copie o novoMeuProg.exepara a pasta e sobrescrever os arquivos (versão exe atualizada de 1.0 para 2.0)
   3. Verifique a versão 2.0 doMeuProg.exena página Propriedades >> Detalhes do servidor de arquivos e do servidor de terminal
   4. Verifique se oMeuProg.exe V2.0é executado quando executado a partir do servidor de arquivos usando o arquivo de atalho (destino:\\Servidor\MyProg\MyProg.exe)
   5. Execute o mesmo arquivo de atalho (destino:\\Servidor\MyProg\MyProg.exe) do servidor de terminal eMeuProg.exe V1.0começa
   6. Renomear\\Servidor\MeuProgpara\\Servidor\MeuProg1e confirme se 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 queMeuProg.exe V2.0roda no cliente
   8. Renomeie a pasta\\Servidor\MeuProg1de volta a\\Servidor\MeuProge a execução do arquivo de atalho original continua a carregarMeuProg.exe V1.0até que o servidor de terminal seja reiniciado.
   9. Verifiquei que os arquivos offline estão desabilitados no servidor de terminal
   10. Verifiquei que não consigo sobrescrever o executável MyProg.exe quando o programa está sendo executado no Terminal Server.

O que mais posso verificar para solucionar o motivo pelo qual uma versão mais antiga do executável está sendo executada mesmo quando o 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 SMB. Modificamos essas configurações e manteremos uma saída durante a próxima atualização.

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

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

Este artigo da base de conhecimento fornece mais informações a esse respeito:
https://support.microsoft.com/kb/2536487

Os aplicativos poderão travar ou parar de responder se outro usuário fizer logoff da sessão da Área de Trabalho Remota no Windows Server 2008 ou no Windows Server 2008 R2

Sintomas:

Ao executar um aplicativo a partir de uma unidade mapeada, o aplicativo pode parar de responder ou travar para um usuário (ou vários usuários) quando outro usuário fizer logoff. Por exemplo:

1. Um servidor é um servidor de arquivos e outro é um servidor Host de Sessão Remota (servidor de terminal).
2. Uma pasta no servidor de arquivos é mapeada para uso por usuários remotos que se conectam ao servidor RDS.
3. Um aplicativo no compartilhamento mapeado é iniciado por vários usuários.
4. Um usuário efetua logoff e isso faz com que os outros usuários do aplicativo sofram uma falha ou falta de resposta do aplicativo.

Especificamente, o comportamento é causado quando o primeiro ou o último usuário do aplicativo faz logoff, dependendo da versão. O Windows Server 2008 enfrentará esse problema quando o primeiro usuário fizer logoff; O Windows Server 2008 R2 enfrentará esse problema quando o último usuário fizer logoff.

Causa:

Isso ocorre devido à forma como o redirecionador trata o FCB (File Control Block) do binário em questão. No Windows Server 2008, o FCB pertence ao usuário que abriu o arquivo pela primeira vez e esse FCB é usado pelos usuários subsequentes. Quando o primeiro usuário faz logoff, o FCB fica órfão, o que faz com que os usuários subsequentes do aplicativo travem ou parem de responder. No Windows Server 2008 R2, o FCB pertence ao último usuário que abriu o arquivo e os usuários anteriores enfrentarão o problema se o último usuário fizer logoff

Gambiarra :

Instale o aplicativo localmente no servidor de terminal em vez de em um compartilhamento de rede