
Esta pergunta é uma continuaçãoPor que alguns administradores não gostam que exes sejam executados a partir de um compartilhamento de servidor? Desenvolvi um utilitário que facilita muito a vida dos desenvolvedores do Access. Uma opção que irei disponibilizar, devido ao feedback no link acima mencionado, é disponibilizar um arquivo MSI para instalação nos sistemas clientes pelo departamento de TI.
Uma opção que eu estava pensando era dar aos desenvolvedores a capacidade de copiar o exe do compartilhamento do servidor para a pasta Application Data do usuário. Outra possibilidade é um exe/msi que o usuário poderia executar, o que também colocaria o exe na pasta Application Data do usuário.
Comentários?
Percebo que o Google instalou o Chrome, o Google Talk e um monte de exes e dlls de atualização na pasta App Data. Bem como alguns outros programas. Não que eu esteja tentando usar isso como desculpa.
Adicionado
Recebi comentários de desenvolvedores afirmando que eles só precisam do meu utilitário em um pequeno subconjunto dos sistemas em uso. Os departamentos de TI passarão meses e meses avaliando as coisas e não querem lidar com esses programas, a menos que façam parte dos sistemas de imagem corporativos. Além disso, os desenvolvedores podem querer enviar atualizações do meu utilitário muito mais rápido do que o departamento de TI lidará com isso.
Responder1
Bem, no caso (bastante comum) de uma pasta pessoal em rede, você ainda terá todos os problemas associados à inicialização a partir de um compartilhamento de rede, porque na verdade é isso que está acontecendo.
Honestamente, eu não entendo. Existem certas maneiras pelas quais os programas devem ser instalados e executados na plataforma Windows. Por que você simplesmente não segue esses métodos comprovados? Na verdade, muitos dos problemas que enfrento com os aplicativos do Windows podem ser atribuídos a programadores que não sabem como se espera que os programas do Windows sejam instalados e se comportem ou que acham que é muito complicado e usam alguns atalhos ou algo parecido.
(É verdade que muitas vezes lido com programas científicos escritos por especialistas em seus domínios que não se importam com a plataforma ou até mesmo tentam escrever de forma independente da plataforma, mas ainda assim).
Responder2
Apoio os comentários de SvenW, os comentários no outro tópico e gostaria de adicionar alguns.
O que acontece se o usuário tiver um perfil móvel e eu estiver tentando instalar o MSI via GPO? Isso significa que o usuário ou a máquina o obtém? Qual é o caso de vários usuários usando a mesma máquina?
O que acontece se o perfil passar de um computador onde deveria executar coisas para um que não seja como um servidor de impressão em um laboratório da Uni? A aplicação seguirá?
Como faço para controlar versões se por exemplo foi instalado em outro computador, o perfil migrou para uma nova máquina? O msi não estará em um estado consistente e quando você lançar uma nova versão eu posso não capturá-lo ou algo pode quebrar?
Existem bons motivos de segurança para garantir que seus executáveis e seus dados estejam completamente separados. Além disso, em vários ambientes, você pode não esperar que o usuário tenha permissão de execução para sua pasta appdata.
Não sei o tamanho do seu aplicativo, mas realmente quero um backup dele para cada usuário quando executo as tarefas de backup dos perfis?
Seu aplicativo parece realmente portátil e independente, isso é ótimo e há soluções alternativas para cada um dos itens acima. Mas por que balançar o barco e forçá-lo a algum lugar onde não deveria ir quando é tão fácil colocá-lo onde é esperado? Não posso falar por mais ninguém, mas os casos acima fazem as coisas caírem na cesta do "imprevisível" e isso não é bom.
Quanto ao Google, depende do seu caso de uso, eles estão pressionando muitos usuários domésticos, talvez quem não se importe? Parece que você está pressionando a TI corporativa e não custa nada agradar as pessoas que testarão e implantarão seu aplicativo. Eles gastarão menos tempo pensando em maneiras de substituí-lo se o seu for estável, previsível e funcionar como qualquer outro que eles possuem.
Responder3
Também comum em ambientes Windows corporativos éPolíticas de restrição de software. Esse recurso subutilizado do Windows moderno permite que o administrador permita ou restrinja a execução de executáveis com base no caminho ou mesmo com base em uma assinatura criptográfica. Rotineiramente, só permito que executáveis sejam executados apenas nas janelas ou nos diretórios de arquivos de programas. Caso contrário, os usuários poderiam fazer download para AppData ou até mesmo para seu diretório de usuários e basicamente executar qualquer coisa. Qual é o sentido de forçar os usuários a serem usuários limitados se eles podem executar qualquer EXE que desejarem? Abro exceções para o GoToMeeting, mas ainda não para o Chrome.
Responder4
Sim, eu me importo. E a razão é simples...perfis móveis.
Embora seu aplicativo possa não ser tão grande, adicione todos os outros que decidem que AppData é o lugar para fazer suas instalações e perfis ficarem enormes...o tempo de login dos usuários aumenta...e então somos os culpados pela lentidão dos sistemas/ rede (sim, isso vale para quem deveria conhecer melhor também).
Minhas políticas do AppLocker, que serão lançadas em breve, eliminarão esses exemplos de programação incorreta do Windows, para que nem tudo esteja perdido.