Shim di compatibilità utilizzato da .NET Standard 2.0

Le panoramiche ( esempio ) di .NET 2.0 Standard dicono che ora utilizza un qualche tipo di shim di compatibilità che corregge il problema di compatibilità delle librerie di terze parti. Quindi è ansible utilizzare la libreria di terze parti con .NET Standard fino a quando non utilizza alcuna API che .NET Standard non ha.

Ciò che non è chiaro è

  • come funziona questo shim? qualche inconveniente?

e

  • come verificare che la libreria di terze parti sia supportata? Inserendolo direttamente nel progetto e poi cercando di compilare?

    Questo funziona creando tutte le librerie necessarie necessarie a cui fanno riferimento le librerie .NET classiche.

    Ad esempio in .NET Core l’implementazione di Object o Attribute è definita in System.Runtime . Quando si compila il codice, il codice generato fa sempre riferimento all’assieme e al tipo => [System.Runtime]System.Object . I progetti .NET classici tuttavia fanno riferimento a System.Object di mscorlib . Quando si tenta di utilizzare un assembly .NET classico su .NET Core 1.0 / 1.1, questo in genere porta a tipi non trovati. In .NET Core 2.0, ci sarà un tipo “falso” in un mscorlib che il runtime sa come inoltrare a dove è effettivamente l’implementazione.

    Puoi leggere di più su come funziona questa unificazione degli assiemi sul repo GitHub dotnet / standard ma lo scenario più importante è questo (immagine presa da questo repository):

    facciata mscorlib

    Questo mostra come dovrebbe funzionare lo scenario: quando una dll di terze parti fa riferimento a [mscorlib]Microsoft.Win32.RegistryKey , ci sarà un mscorlib.dll che contiene un tipo inoltrato a [Microsoft.Win32.Registry] Microsoft.Win32.RegistryKey quindi funzionerà quando è presente un Microsoft.Win32.RegistryKey.dll .

    Questo mostra anche il lato negativo principale: il registro è un concetto solo per Windows e non è disponibile su Mac o Linux, quindi questo particolare codice potrebbe non funzionare su piattaforms non Windows. Ma se si utilizzano solo parti della libreria che non utilizzano questa funzionalità, potrebbe funzionare per scenari multipiattaforma.

    Un altro problema è che anche se l’API è “disponibile” per la compilazione e il riferimento, può ancora lanciare PlatformNotSupportedException .

    Ad esempio, una libreria che implementa un formato di file per la serializzazione / deserializzazione potrebbe funzionare senza modifiche, anche se è stata creata per .NET Framework 3.5.

    Per trovare l’API utilizzata da una libreria specifica, .NET Portability Analyzer può essere utilizzato per eseguire la scansione di una DLL e mostrare se la libreria è compatibile e, in caso contrario, quali API stanno bloccando.