É uma boa prática colocar o executável em um servidor de arquivos?

Question

Supondo que os componentes como * .dll, * .ocx estejam instalados e registrados nos clientes, existe a possibilidade de colocar o * .exe e alguns arquivos relacionados no servidor de arquivos. Para iniciar o aplicativo, há links nos desktops do cliente que executam o \fileserver\AppPath\exe .

Você concorda com esse layout? E se "o cliente" for um servidor de terminal e "os clientes" significarem um farm de servidores de terminais?

    

Answer 1

Não tenho problemas em ter executáveis no servidor de arquivos. Eles não executam lá, eles são executados no cliente, portanto, não representam um risco maior do que qualquer outro arquivo que possa estar naquele servidor. Esses arquivos são simplesmente servidos como arquivos, não como programas executáveis.

Quando se trata de servidores de terminal, é uma questão diferente. Os executáveis então são executados no servidor, não no cliente. No entanto, como os servidores de terminal foram projetados exatamente para essa função, não haverá problemas além de garantir que quaisquer aplicativos que precisem ser instalados, em vez de simplesmente serem copiados, sejam instalados usando a metodologia correta.

    

Answer 2

SE o aplicativo é tão simples quanto um único arquivo .exe (talvez com um monte de arquivos de suporte que também podem residir no mesmo diretório) e não Não é necessária uma configuração adequada no cliente, isso pode ser feito e funciona bem; Ele também tem o benefício adicional de não ter que se preocupar em implantar / manter / atualizar o aplicativo em cada cliente.

É claro que, se os computadores clientes perderem a conectividade da rede e / ou o servidor de arquivos ficar inativo, o aplicativo ficará inutilizável.

    

Answer 3

A separação de papéis é um conceito importante a ser aplicado aqui. Se você tiver um compartilhamento de rede que esteja hospedando documentos do usuário, poderá aplicar determinadas abordagens de backup, disponibilidade e segurança a esse compartilhamento, dependendo de como os tipos de arquivos que ele hospeda e em que horas durante o dia os usuários precisarão acessá-lo. Você também sabe que, se precisar levar o servidor que o mantém offline durante o dia para manutenção, basta notificar seus usuários para fechar todos os documentos abertos enquanto durar.

Agora, considere que você adicionou algum software a esse compartilhamento de arquivos, que os usuários executam diretamente do compartilhamento. De repente, você está fazendo backup dos dados do programa juntamente com os dados do arquivo do usuário. Agora você tem complicações extras se precisar desativar o servidor para manutenção (o que acontece se o servidor ficar offline enquanto o aplicativo estiver em execução?). Este é um exemplo de muitos, onde suas necessidades de administração do programa e suas necessidades de administração do restante do compartilhamento de arquivos podem gerar conflitos diferentes. Você nem sempre pode prever esses tipos de conflito antes do tempo, mas é uma daquelas coisas que, na maioria das vezes, leva a dores de cabeça administrativas.

Portanto, é por isso que você deve separar funções e papéis sempre que possível, se suas características forem diferentes ou se houver probabilidade de divergir no futuro. É mais elegante e suportável, com surpresas menos desagradáveis.

Para um exemplo do mundo real: em uma empresa em que trabalhei anteriormente, tínhamos um arquivo geral & servidor de impressão, e nós rodamos o Lotus Notes / Domino para o groupware. A instalação do Lotus Notes para todos os usuários foi hospedada em um compartilhamento de arquivos no arquivo & servidor de impressão e execute diretamente a partir dele. Acredito que isso tenha sido feito originalmente com a intenção de poder atualizar o Notes uma vez e ter todos os clientes atualizados automaticamente. Talvez em um momento isso funcionou.

A realidade da situação era que um único sinal de rede, talvez uma vez por semana, acionaria todos os usuários do Notes por e-mail e geraria um arquivo de bloqueio no compartilhamento que precisaria ser excluído manualmente por um administrador. As pessoas realmente notam quando "o e-mail está inativo". O software carregou lentamente também, especialmente no início da manhã, quando você tinha 150 usuários simultaneamente tentando carregar um único .exe. Para completar, as atualizações do Notes ainda exigiam visitar cada PC. O benefício líquido acabou sendo zero ou negativo, embora eu ache que parecia uma ótima maneira de economizar tempo, originalmente.

Quanto ao seu problema específico ... o que você está realmente tentando fazer ao fazer isso? Se o seu .exe é um que está sendo criado internamente e atualizado com freqüência, e seus desenvolvedores só querem uma maneira mais rápida de publicar suas atualizações .. tenha cuidado. Trocar um EXE enquanto os usuários ainda o acessam pode causar dores de cabeça e inconsistências de dados. Além disso, o carregamento de aplicativos em um servidor de terminal deve ser feito de uma maneira específica, usando o comando set user / install no TS antes de instalar, depois definir user / execute quando instalado e pronto para ser executado. Ignorar esse processo pode levar a resultados imprevisíveis.

    

Answer 4

Dependendo de como o aplicativo foi criado, isso pode ser muito mais complicado do que parece, algo que é apenas um único exe pode precisar de alguma ajuda para permitir que ele seja executado a partir de uma unidade não-local. Veja esta Pergunta de estouro de pilha na segurança de acesso a código .Net para uma discussão sobre um tipo de problema que você pode enfrentar.

Existem algumas soluções de streaming de aplicativos muito capazes que oferecem a mesma facilidade de benefícios de gerenciamento para você (o Citrix XenApp pode fazer isso, o VMware ThinApp ..). Estes fornecem soluções gerenciáveis para aplicações complexas, mas a um custo. Para aplicativos simples que sejam bem comportados, sua solução pode ser conveniente, mas você terá que ter cuidado com essa parte bem comportada.