Nominazione sicura

La denominazione forte si riferisce alla firma di un assembly con una chiave, generando un assembly con nome sicuro. Quando un assembly è denominato con un nome forte, crea un'identità univoca basata sul nome e sul numero di versione dell'assembly e può contribuire a evitare conflitti tra assembly.

Lo svantaggio della denominazione forte è che .NET Framework su Windows consente il caricamento rigoroso degli assembly una volta che un assembly è fortemente nominato. Un riferimento ad assembly con nome forte deve corrispondere esattamente alla versione dell'assembly caricato, il che costringe gli sviluppatori a configurare i reindirizzamenti di binding quando utilizzano l'assembly.

<configuration>
   <runtime>
      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
         <dependentAssembly>
            <assemblyIdentity name="myAssembly" publicKeyToken="32ab4ba45e0a69a1" culture="neutral" />
            <bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.0.0"/>
         </dependentAssembly>
      </assemblyBinding>
   </runtime>
</configuration>

Quando gli sviluppatori .NET si lamentano del naming forte, ciò di cui in genere si lamentano è il caricamento stretto delle assembly. Fortunatamente, questo problema è isolato in .NET Framework. .NET 5+, .NET Core, UWP e la maggior parte delle altre implementazioni .NET non hanno un caricamento rigoroso degli assembly, che è il principale svantaggio del naming forte.

Un aspetto importante della denominazione complessa in .NET Framework è che è virale: un assembly con nome sicuro può fare riferimento solo ad altri assembly con nome sicuro. Se la libreria non è con nome sicuro, le app e le librerie di .NET Framework che richiedono nomi sicuri non possono usarla.

I vantaggi della denominazione avanzata in .NET Framework sono i seguenti:

1. È possibile fare riferimento all'assembly e utilizzarlo da altri assembly con nome sicuro.
2. L'assembly può essere archiviato nella Global Assembly Cache (GAC).
3. L'assembly può essere caricato affiancato ad altre versioni dell'assembly. Il caricamento di assembly side-by-side è comunemente richiesto dalle applicazioni con architetture plug-in.

La denominazione avanzata non offre vantaggi per .NET Core/5+. Il compilatore C# genera un avviso CS8002 per gli assembly con nome sicuro che fanno riferimento ad assembly con nome non sicuro. È consigliabile eliminare questo avviso per le librerie destinate solo a .NET Core/5+.

Quando applicare un nome sicuro alle librerie .NET

La denominazione avanzata non è necessaria per le librerie destinate solo a .NET Core/5+. È consigliabile assegnare un nome sicuro alle librerie .NET open source se le relative destinazioni includono .NET Framework o .NET Standard.

Annotazioni

Queste linee guida sono specifiche per le librerie .NET distribuite pubblicamente, ad esempio le librerie .NET pubblicate in NuGet.org. La denominazione avanzata non è necessaria per la maggior parte delle applicazioni .NET e non deve essere eseguita per impostazione predefinita.

✔️ PRENDERE IN CONSIDERAZIONE il naming forte degli assembly della libreria se si usa solo .NET Framework o .NET Standard.

La denominazione avanzata non ha alcun impatto sui runtime .NET moderni. Se la libreria è destinata solo a .NET moderno, non è necessario assegnare un nome sicuro agli assembly.

Se si utilizza il multi-targeting tra .NET Framework/.NET Standard e .NET moderno, dovresti utilizzare il strong name su tutti i framework di destinazione.

Considerare l'aggiunta della coppia di chiavi di denominazione forte (pubblica + privata) al sistema di controllo del codice sorgente.

Una coppia di chiavi disponibile pubblicamente consente agli sviluppatori di modificare e ricompilare il codice sorgente della libreria con la stessa chiave.

Non è consigliabile rendere pubblica la coppia di chiavi di denominazione avanzata se è stata usata in passato per concedere autorizzazioni speciali in scenari parzialmente attendibili. In caso contrario, è possibile compromettere gli ambienti esistenti.

Se non è possibile registrare la coppia di chiavi pubblica e privata, registrare la chiave pubblica e usare la firma pubblica per il processo di compilazione regolare. La firma pubblica consente comunque agli sviluppatori di ricompilare e usare la libreria nella maggior parte degli scenari.

Importante

Quando si desidera l'identità del server di pubblicazione del codice, è consigliabile usare Authenticode e Firma del pacchetto NuGet . La sicurezza dall'accesso al codice non deve essere usata come mitigazione della sicurezza.

✔️ PRENDERE IN CONSIDERAZIONE di incrementare la versione dell'assembly solo per le modifiche di versione principali per consentire agli utenti di ridurre i reindirizzamenti di binding e la frequenza con cui questi ultimi vengono aggiornati.

Altre informazioni sul controllo delle versioni e sulla versione dell'assembly.

❌ NON aggiungere, rimuovere o modificare la chiave di denominazione complessa.

La modifica della chiave di nome sicuro di un assembly modifica l'identità dell'assembly e rende inutilizzabile il codice compilato che lo usa. Per ulteriori informazioni, vedere Modifiche binarie che causano interruzioni.

❌ NON pubblicare versioni con nome sicuro e non con nome sicuro della libreria. Ad esempio, Contoso.Api e Contoso.Api.StrongNamed.

Pubblicare due pacchetti biforca l'ecosistema degli sviluppatori. Inoltre, se un'applicazione finisce per dipendere da entrambi i pacchetti, lo sviluppatore può riscontrare conflitti di nomi dei tipi. Per quanto riguarda .NET, sono tipologie diverse in moduli diversi.

PrecedenteAvanti