Por que usar assemblies de nome forte?

107

Quais são as vantagens de usar assemblies com nomes fortes?

Quais são as coisas que não podem ser feitas com uma montagem normal?

c# .net

— desenvolvedor
fonte

92

Deixe-me listar os benefícios de nomear fortemente sua montagem primeiro:

A nomenclatura forte de seu assembly permite que você inclua seu assembly no Global Assembly Cache (GAC). Assim, permite que você compartilhe entre vários aplicativos.
A nomenclatura forte garante um nome exclusivo para esse assembly. Assim, ninguém mais pode usar o mesmo nome de montagem.
O nome forte protege a linhagem da versão de um assembly. Um nome forte pode garantir que ninguém seja capaz de produzir uma versão subsequente de seu assembly. Os usuários do aplicativo têm a garantia de que uma versão do assembly que estão carregando vem do mesmo editor que criou a versão com a qual o aplicativo foi construído.

Mais informações sobre nomes fortes da Microsoft estão em Strong-Named Assemblies ( MSDN ).

— Kyle Rosendo
fonte

1

Tem certeza do item 4? Acho que talvez esse comportamento tenha mudado recentemente. Tentei fazer com que o carregamento de um assembly com nome forte falhasse modificando-o, mas ele carregou sem incidentes.

— Jens

19

Com relação ao nº 4, isso está incorreto. Não foi projetado para proteger contra adulteração. Consulte blogs.msdn.com/b/shawnfa/archive/2005/12/13/… para obter mais informações.

— Colin Bowern

1

@ RobV8R 90% de nossas dependências são de código aberto, as chaves privadas estão nos repositórios git públicos (de acordo com as recomendações da Microsoft) e disponíveis para quem quiser.

— trampster

1

@ RobV8R Você não pode usar a palavra comprometido aqui, o que implicaria que era para ser um segredo em primeiro lugar. As diretrizes da Microsoft são de que a chave privada deve ser mantida em seu repositório de origem pública. As chaves privadas não são comprometidas, elas são publicadas intencionalmente. Dado que as chaves privadas são conhecidas e destinadas a serem usadas por pessoas que modificam o código de código aberto dos projetos pais (caso contrário, a licença seria violada em muitos casos), então as pessoas que fazem isso usariam um número de versão diferente, mas a mesma chave, neste caso seja necessário um redirecionamento de ligação.

— trampster

1

@ RobV8R O que eu queria originalmente dizer é que muitas pessoas acreditam que a nomenclatura forte garante que sua dependência seja bloqueada para uma versão específica de um assembly, e esse simplesmente não é o caso, um redirecionamento de ligação simples pode alterar a versão que você usa, desde que foi assinado com a mesma chave privada. E como eu disse, as chaves privadas são publicadas intencionalmente para a maioria de nossas dependências.

— trampster

9

Quais são as coisas que não podem ser feitas com uma montagem normal?

Como todas as discussões que começaram com o surgimento de Nuget sugeriram livrar-se completamente de conjuntos com nomes fortes, minha empresa tentou isso e encontrou uma mudança significativa de comportamento quando se trata de configurações de aplicativos:

Se você usar o aplicativo automático ou as configurações do aplicativo com escopo do usuário fornecidas pelo VisualStudio (herdando System.Configuration.ApplicationSettingsBase), um EXE com nome forte criará exatamente 1 diretório dentro de% LOCALAPPDATA% chamado, por exemplo, "YourApplication.exe_StrongName_kjsdfzsuzdfiuzgpoisdiufzsdouif", não importa onde o EXE está localizado.

Mas sem o nome forte, o local (= caminho) do EXE será usado para criar um valor de hash que já difere entre DEBUG e RELEASE build, criando muitos diretórios dentro de% LOCALAPPDATA% nomeados como "YourApplication.exe_Url_dfg8778d6fs7g6d7f8g69sdf". Isso o torna inutilizável para implantações ClickOnce, onde o diretório de instalação muda a cada atualização.

— springy76
fonte

5

Gostaria de acrescentar que, sem um nome forte, você não pode usar redirecionamentos de vinculação em arquivos de configuração.

Isso não vai funcionar:

  <dependentAssembly>
    <assemblyIdentity name="MyAssembly.MyComponent" publicKeyToken="null" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
  </dependentAssembly>

Você precisa ter um token de chave pública

  <dependentAssembly>
    <assemblyIdentity name="MyAssembly.MyComponent" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
  </dependentAssembly>

— Tomasat
fonte

9

Os redirecionamentos de vinculação não são necessários se você não tiver um nome forte.

— trampster

0

Apenas um exemplo: gostaria de dar uma resposta dando mais ênfase na segurança . No caso de criarmos assemblies com um código-fonte que não queremos ser reutilizado por terceiros, mas queremos que seja testável, podemos assinar fortemente um assembly e tornar os internos visíveis apenas para os assemblies com o mesma assinatura.

— Ricky Youssef
fonte