Obtendo arquivos de conteúdo e Saída principal programaticamente

StackOverflow https://stackoverflow.com/questions/811691

  •  03-07-2019
  •  | 
  •  

Pergunta

Por alguma razão, temos um script que cria arquivos em lote para xcopy nossas assembléias compilados, arquivos de configuração, e vários outros arquivos para um compartilhamento de rede para os nossos testadores beta. Nós temos um instalador, mas alguns não têm as permissões necessárias para executar o instalador, ou eles estão correndo sobre Citrix.

Se você vomitou toda a sua mesa no menções de XCOPY e Citrix, usá-lo como uma desculpa para ir para casa mais cedo. Você é bem-vindo.

O código tem atualmente centenas de linhas como: 

CreateScripts(basePath, "Client", outputDir, FileType.EXE | FileType.DLL | FileType.XML | FileType.CONFIG);

Ela costumava ser pior, com 20 parâmetros int (um por tipo de arquivo) que representam ou não para copiar esse tipo de arquivo no diretório de saída.

Estas centenas de linhas de criar arquivos em lote upload / download com milhares de linhas XCOPY. Em nossos projetos de instalação, podemos referenciar coisas como "saída primária do Cliente" e "Arquivos de conteúdo do cliente". Eu adoraria ser capaz de fazer isso por meio de programação de um projeto não-configuração, mas eu estou em uma perda.

Obviamente MS faz isso, seja usando uma API ou ao analisar os arquivos csproj. Como eu iria fazer isso? Eu estou apenas procurando uma maneira de obter uma lista de arquivos para qualquer uma das categorias de configuração, i:.

  • Saída primária
  • recursos localizados
  • Arquivos de conteúdo
  • Documentação Arquivos

Editar : Eu tenho um projeto de instalação como Hath sugeriu, e é meio caminho para o que eu estou procurando. A única manutenção problema que de ser uma solução perfeita é que vários projetos dependem dos mesmos conjuntos de estar em sua própria pasta, ea configuração só irá copiar o arquivo de uma vez.

Exemplo:

Projetos de administração, cliente e servidor todos dependem de ExceptionHandler.dll, e Admin e Cliente ambos dependem Util.dll, enquanto Server não faz. Isto é o que eu estou procurando:

  • Administrador
    • Admin.exe
    • Admin.exe.config
    • ExceptionHandler.dll
    • Util.dll
  • Cliente
    • Client.exe
    • Client.exe.config
    • ExceptionHandler.dll
    • Util.dll
  • Servidor
    • Server.exe
    • Server.exe.config
    • ExceptionHandler.dll

Uma vez que os assemblies referenciados são todos o mesmo, o que eu recebo é o seguinte:

  • Administrador
    • Admin.exe
    • Admin.exe.config
    • ExceptionHandler.dll
    • Util.dll
  • Cliente
    • Client.exe
    • Client.exe.config
  • Servidor
    • Server.exe
    • Server.exe.config

Isto provoca uma FileNotFoundException quando um cliente ou servidor não consegue encontrar um dos dois DLLs que está esperando.

Existe uma propriedade de configuração que estou em falta para torná-lo sempre copiar a saída, mesmo que seja duplicado em outro lugar na produção de outro projeto?

EDIT novamente : Todas as DLLs referenciadas são definidas como "Copy Local", e sempre foram. Eu encontrei um artigo decente sobre usando NAnt e XSLT para pegar a lista de arquivos , de modo que pode ser uma possível solução, bem como, como neouser99 sugeridas.

Solução aceita : Eu estou praticamente de volta onde eu comecei. Todas as saídas .exe e .dll são colocados em um diretório "bin" no projeto de instalação, ligeiramente comprimido. As outras pastas de aplicativos por conter atalhos para o executável no diretório.

A diferença agora é que eu estou indo para adicionar uma ação personalizada para o instalador para uso reflexão, enumerar as dependências para cada saída executável e copie o .exe e .dll para os diretórios separados. Pouco de dor, como eu só assumiu que havia uma maneira de detectar programaticamente quais arquivos seriam incluídos via alguma biblioteca de configuração.

Foi útil?

Solução

por que não usar um outro projeto de instalação e apenas definir configuração dos arquivos do pacote 'para arquivos tão solto sem compressão (projeto- configuração> Propriedades)? em seguida, compartilhar a pasta .. ou algo assim.

edit:

Eu vejo, você tem 3 pastas para as suas saídas. mas o projeto de instalação só detecta o ExceptionHandler.dll e Util.dll uma vez, por isso vai apenas escolher a primeira pasta e colocá-lo lá dentro.

Você poderia fazer um projeto de instalação para cada projeto - pouco chato talvez ..

Você pode adicionar manualmente a DLL para os projetos que estão em falta da Assembléia quer pela inclusão no arquivo por arquivo 'add' ou 'adicionar assembly' ou 'saída do projeto add' se você tem esses projetos na mesma solução .. (eu duvido que é o caso, porém).

ou simplesmente despejar todos eles em um diretório de saída ...

Outras dicas

Embora seja concebido como uma ferramenta de construção, você pode encontrar NAnt para ser extremamente útil para o que você é falando sobre. As tarefas (Build, copiar, mover, excluir, etc.) que podem ser definidos permitem pesquisas de arquivo muito grão fino, até gerais, pastas cheias. Se você também incorporam NAnt em seu processo de criação, eu acho que você pode achar que ele ajuda em mais maneiras então um.

Outra abordagem que tem trabalhado para mim no passado é adicionar o recurso compartilhado (Assembly, DLL ou projeto) como uma referência para cada um dos projetos de administrador, servidor e cliente. Em seguida, abra o painel de propriedades para o item referenciado em cada projeto e conjunto "Copy Local" para true.

Agora, quando você construir os projetos, cada um terá sua própria instância da Assembleia copiado para sua pasta de saída.

Isso também deve fazer com que os componentes compartilhados adicionados desta maneira para ser replicado em cada uma das pastas de saída no pacote de instalação.

Uma abordagem completamente diferente poderia ser para configurá-los como links simbólicos no compartilhamento de rede. Um link simbólico é basicamente um atalho, onde os do sistema de arquivos esconde o fato de que é um atalho, então todas as outras aplicações realmente acredita que o arquivo foi copiado ( http://en.wikipedia.org/wiki/NTFS_symbolic_link ).

Uma vantagem dessa abordagem é que o arquivo é atualizado imediatamente como as mudanças de arquivos e não somente quando você construir seus projetos. Então, quando você, por exemplo, salvar uma das config-arquivos com um editor de texto a atualização é aplicada imediatamente.

A parte seguinte roteiro MSBuild pode construir seu arquivo SLN (você pode substituí-lo com .csproj) e irá reportar uma lista de todos os projetos que estavam construção (DLLs, EXEs). 

 <MSBuild Projects="MySolution.sln" Targets="Clean; Rebuild" Properties="Configuration=$(BuildMode);">
    <Output TaskParameter="TargetOutputs"
                ItemName="AssembliesBuilt" />
    </MSBuild>

Agora, isso realmente não resolver o problema, mas torna-se-lhe uma lista de tudo o que foi construído. Você também tem CopyLocal, então você poderia provavelmente apenas tomar AssembiesBuild e copiar todos os arquivos DLL e .config a partir daí.

Exemplo:

AssembliesBuild = c: \ myproj \ something1 \ build.dll

Você iria para c: \ myproj \ something1 \ e simplesmente procurar todos .dll * e * ficheiros.config e incluí-los. Você pode fazer isso muito facilmente com MSBuild ou PowerShell, se você tem instalado. Para a saída de um script XCOPY de MSBuild, eu acho que você vai precisar MSBuild contrib projct instalado.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top