Vantagens de usar arquivos .dll ao vincular arquivos .cs a projetos (para minhas próprias classes auxiliares / métodos de extensão genéricos)

37

Eu tenho um projeto auxiliar que uso em todos os aplicativos que eu crio. Ele contém alguns métodos de extensão e um monte de classes auxiliares genéricas, controles etc. Eu atualizo / estendo o projeto auxiliar de tempos em tempos. Geralmente são projetos pequenos e não relacionados, e eu sou a única pessoa trabalhando em todos eles.

Eu tentei duas abordagens para usá-lo

  • adicione arquivos .cs diretamente (Adicionar como link) a cada projeto em que eu os utilizo
  • compila como .dll e adiciona como referência

Eu vejo alguns benefícios e desvantagens dessas abordagens.
O primeiro:

  • é mais simples, porque as classes auxiliares são compiladas no arquivo exe, portanto, muitas vezes, posso fornecer facilmente apenas um único arquivo .exe que funcionará bem. Como eu adiciono como link, posso ter certeza de que sempre que eu criar um projeto que use o helper, os arquivos auxiliares serão a versão mais recente.
  • é ainda mais simples, porque eu posso separar os arquivos, para que meus métodos de extensão que funcionam bem no .NET 4.0 possam ser referenciados separadamente daqueles que exigem o .NET 4.5, o que significa que o aplicativo como um todo pode ser executado .NET 4.0
  • Permite depurar o código, com todos os benefícios dos pontos de interrupção, etc etc ...
  • não parece ser "melhor prática"

O segundo:

  • parece ser a abordagem correta, mas:
  • requer que eu forneça um arquivo .dll separado, que por algum motivo é muito mais difícil para os usuários (eles tendem a compartilhar meus programas sem o .dll, que falha na inicialização)
  • à medida que é compilado em um único arquivo .dll, ele exigirá a versão mais recente do .NET - muitos dos meus usuários não têm o .NET 4.5 e apenas alguns elementos da minha classe auxiliar exigem isso, o que significa que posso ser forçando algumas pessoas a atualizar seus sistemas sem motivo
  • Eu também preciso ter certeza de que sempre que eu atualizar algum dos meus programas, eu também entrego o arquivo .dll - mesmo que eu não saiba se ele foi alterado desde a última versão, ou não (poderia ter sido , mas poderia ser a mesma versão). Não consigo ver uma maneira simples de determinar isso, sem acompanhar a versão de montagem, que é um trabalho adicional. Por enquanto, quando eu atualizo meus programas, eu só entrego o exe atualizado, e eu gosto de mantê-lo pequeno e de baixo perfil.

Então, qual é o benefício real de usar o arquivo .dll aqui? Por favor, note que eu sou a única pessoa que edita o código de todos os aplicativos e arquivos auxiliares.

Além disso, para esclarecer - os aplicativos geralmente são muito pequenos, enquanto o código contido nas classes auxiliares é completamente genérico para todos eles (algumas simples comparações de strings, caminhos ou operações XML, etc.)

Na verdade, alguém me fez perceber agora que há uma terceira opção. Como eu tenho o código auxiliar em um projeto separte, posso adicionar esse projeto a soluções de cada um dos meus aplicativos separados - que funciona como 'Adicionar como link' para arquivos únicos, exceto que eu só adiciono um único projeto ... Mas, como notado por Doc Brown, isso essencialmente significa que .dll precisará ser adicionado ao projeto de qualquer maneira ...

Ainda outra coisa que é a favor de não usar os arquivos dll é a capacidade de depurar ativamente a classe auxiliar ...

    
por Bartosz 11.09.2015 / 13:04
fonte

6 respostas

12

Você já viu a maioria dos prós e contras. Usando arquivos cs como referências é de fato mais leve e, muitas vezes, mais fácil de gerenciar. No entanto, recomendo usar essa abordagem exclusivamente quando seus arquivos cs forem totalmente independentes e não tiverem nenhum requisito de criação especial.

Usando DLLs separadas

  • tornará as dependências de outros utilitários ou bibliotecas explícitas (contanto que você não tenha tais dependências, funcionará bem)

  • permitirá que você defina configurações de compilação específicas (por exemplo, se uma classe só funciona na configuração x86 ou precisa pelo menos do .NET 4.0, a configuração de compilação do assembly torna esse requisito explícito).

Portanto, especialmente se você tiver muitos componentes autocontidos de classe única, usar a referência a arquivos é bom, mas se você tiver componentes referenciando outros componentes ou requisitos de compilação específicos, recomendo usar DLLs.

Para atenuar os problemas com o gerenciamento de muitas DLLs separadas, você pode criar um pacote de instalação ou utilizar ILMerge , que pode incorporar um conjunto de assemblies em um único executável. Em nosso ambiente, lidamos com o problema de maneira diferente, usando um script de implantação para cada aplicativo. Este script garante que todas as DLLs necessárias sejam sempre entregues à produção quando uma nova versão do aplicativo for publicada.

    
por 11.09.2015 / 14:04
fonte
11

As DLLs são úteis quando um aplicativo é grande e há partes que exigem atualizações, mas não o aplicativo inteiro. Então, se você está escrevendo o MS Word, é útil ter o código de verificação ortográfica em uma DLL que pode ser atualizada sem ter que atualizar a totalidade do MS Word. Se o que você está escrevendo é um pequeno aplicativo utilitário (ou uma série de aplicativos independentes que usam todos o mesmo código), não faz muita diferença se o código está embutido no aplicativo (s) ou não.

    
por 11.09.2015 / 14:24
fonte
2

Você resumiu bastante na sua pergunta, eu só tenho alguns pontos para adicionar.

Mono Options é um ótimo exemplo de um pacote NuGet que usa muito bem a primeira abordagem.

Como alternativa, se você decidir usar dlls, poderá usar ferramentas como Costura para incorporar essa referência em seu executável como um recurso incorporado. Para usá-lo basta adicionar o pacote Costura.Fody :

Install-Package Costura.Fody
    
por 11.09.2015 / 18:46
fonte
2

Se uma dll é mais benéfica ou não depende de vários fatores:

  1. O tamanho do código (quando compilado).
  2. Quantos exes usam.
  3. Com que frequência você pretende atualizar o código.
  4. se os exes devem ou não ser mantidos juntos ou existir completamente separadamente.

O propósito de uma biblioteca compartilhada é pegar o código que é comum a vários executáveis e centralizá-lo para que todos os executáveis compartilhem uma cópia. Isso tem o objetivo de economizar espaço e tornar o código mais fácil de atualizar.

Se a quantidade de código em sua classe auxiliar for muito pequena, talvez não valha a pena movê-lo para uma dll, pois a sobrecarga do código que está em uma dll pode neutralizar o benefício de economia de espaço da centralização.

Além disso, se você estiver fazendo apenas alguns executáveis, o tamanho do código em cada executável pode ser pequeno o suficiente para não ser um problema. No entanto, quanto mais executáveis você tiver usando o mesmo código, mais benéfico seria ter o código movido para uma dll.

Como um exemplo simplificado, digamos que sua classe auxiliar compila 128 bytes em um arquivo exe, mas quando movida para uma dll, a dll é de 512 bytes. Se você tiver apenas 3 executáveis, você estará economizando espaço incluindo o código nos executáveis. No entanto, se você tivesse 5 executáveis, você estaria no ponto em que seria melhor ter uma dll, porque o espaço combinado ocupado por 5 cópias do código (5 * 128 = 640 bytes) é maior do que o espaço ocupado. por ter o código em uma dll (512 bytes).

Agora, por exemplo, você encontra um bug no seu código auxiliar. Se você compilou todos os seus executáveis com o código ativado, você terá que recompilar cada executável e redistribuir as versões recompiladas. Se você compilasse o código para uma dll, você teria apenas que recompilar e redistribuir a dll, e o bug seria automaticamente corrigido para todos os executáveis que o usam.

Finalmente, para um programa encontrar uma dll, ela precisa saber onde procurar pela dll. Se você está mantendo todos os seus executáveis juntos, você pode simplesmente colocar a dll no mesmo diretório e todos eles vão encontrá-lo imediatamente. Se você está intencionalmente mantendo-os separados, torna-se mais difícil coordená-los para usar a mesma dll.

    
por 12.09.2015 / 08:02
fonte
1

Sua terceira opção é a mais apropriada (inclua-a como um projeto "biblioteca de classes" separado para a solução). Isso combina os benefícios de todas as abordagens:

  • Seu "projeto auxiliar" está sempre atualizado em todos os diferentes projetos.
  • Você pode consultar o código do projeto quando quiser ver as alterações rapidamente.
  • Você pode compilá-lo para a versão .NET correta a cada vez.
  • Você pode incorporar uma DLL em um exe de qualquer maneira, portanto não se preocupe com isso, você pode ter isso como parte de sua compilação.

Fazemos isso o tempo todo e não posso fazer nada além de recomendar essa abordagem.

Outra quarta alternativa que você não mencionou é colocá-la em um repositório privado do NuGet, que permitiria a sua versão correta e referenciá-la sem o projeto extra em cada solução.

    
por 11.09.2015 / 21:06
fonte
1

Como desenvolvedor, sempre gosto de incluir a referência da solução do utilitário ao meu aplicativo, pois ele me permite depurar o código (e detectar possíveis bugs no utilitário também!), além de todas as alterações feitas no utilitário serem incluídas automaticamente no aplicativo. .

Então, na verdade, a decisão depende de quão maduro é o utilitário ! Se você não tem certeza sobre os erros do utilitário, então você deve sempre incluir o arquivo .cs desse utilitário para descobrir os erros. Mas se você tiver certeza de que o utilitário está maduro o suficiente e ele não retornará o resultado com nenhum erro e não há espaço para aprimoramento no utilitário, você pode ir em frente e incluir o arquivo DLL.

    
por 17.09.2015 / 10:30
fonte

Tags