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

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.

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.

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

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.

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.

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.