Freigeben über

CompareAssemblyIdentityWithConfig-Funktion

  • Artikel

Vergleicht zwei Assemblyidentitäten, um zu ermitteln, ob sie äquivalent sind, nach dem Anwenden von Portabilitätsrichtlinienelementen aus einer angegebenen Konfigurationsdatei.

STDAPI CompareAssemblyIdentityWithConfig (
    [in]  LPCWSTR                  pwzAssemblyIdentity1,
    [in]  BOOL                     fUnified1,
    [in]  LPCWSTR                  pwzAssemblyIdentity2,
    [in]  BOOL                     fUnified2,
    [in]  struct AssemblyConfig    *pAssemblyConfig,
    [out] BOOL                     *pfEquivalent,
    [out] AssemblyComparisonResult *pResult
 );

Parameter

  • pwzAssemblyIdentity1
    [in] Die Textidentität der ersten Assembly im Vergleich.

  • fUnified1
    [in] Ein boolesches Flag, das eine vom Benutzer angegebene Vereinheitlichung für pwzAssemblyIdentity1 angibt.

  • pwzAssemblyIdentity2
    [in] Die Textidentität der zweiten Assembly im Vergleich.

  • fUnified2
    [in] Ein boolesches Flag, das eine vom Benutzer angegebene Vereinheitlichung für pwzAssemblyIdentity2 angibt.

  • pAssemblyConfig
    [in] Eine Konfigurationsdatei mit Informationen, die Portabilitätsrichtlinien beeinflussen, wie das <supportPortability>-Element.

  • pfEquivalent
    [out] Ein boolesches Flag, das angibt, ob die beiden Assemblys äquivalent sind.

  • pResult
    [out] Ein AssemblyComparisonResult-Wert, der detaillierte Informationen über den Vergleich enthält.

Rückgabewert

pfEquivalent gibt einen booleschen Wert zurück, der angibt, ob zwei Assemblys äquivalent sind. pResult gibt einen der AssemblyComparisonResult-Werte zurück, um einen ausführlicheren Grund für den Wert von pfEquivalent zu geben.

Hinweise

CompareAssemblyIdentityWithConfig prüft, ob pwzAssemblyIdentity1 und pwzAssemblyIdentity2 äquivalent sind. pfEquivalent ist auf true festgelegt, wenn eine oder mehrere der folgenden Bedingungen nach der Anwendung der Elemente in pAssemblyConfig erfüllt sind, die Portabilitätsrichtlinien beeinflussen:

  • Die beiden Assemblyidentitäten sind äquivalent. Bei Assemblys mit starken Namen setzt eine Äquivalenz voraus, dass Assemblyname, Version, öffentliches Schlüsseltoken und Kultur identisch sind. Für Assemblys mit einfachen Namen setzt eine Äquivalenz voraus, dass Assemblyname und Kultur übereinstimmen.

  • Beide Assemblyidentitäten verweisen auf Assemblys, die unter .NET Framework ausgeführt werden. Diese Bedingung gibt auch dann true zurück, wenn die Assemblyversionsnummern nicht übereinstimmen.

  • Die beiden Assemblys sind keine verwalteten Assemblys, aber fUnified1 oder fUnified2 wurde auf true festgelegt.

Das fUnified-Flag gibt an, dass alle Versionsnummern bis zur Versionsnummer der Assembly mit starken Namen als äquivalent mit der Assembly mit starkem Namen angesehen werden. Wenn beispielsweise der Wert von pwzAssemblyIndentity1 "MyAssembly, version=3.0.0.0, culture=neutral, publicKeyToken=...." ist, und fUnified1 den Wert true hat, bedeutet dies, dass alle Versionen von MyAssembly von Version 0.0.0.0 bis 3.0.0.0 als äquivalent betrachtet werden sollen. Wenn pwzAssemblyIndentity2 in einem solchen Fall mit Ausnahme einer kleineren Versionsnummer auf die gleiche Assembly verweist wie pwzAssemblyIndentity1, wird pfEquivalent auf true festgelegt. Wenn pwzAssemblyIdentity2 auf eine höhere Versionsnummer verweist, wird pfEquivalent nur auf true festgelegt, wenn fUnified2 den Wert true aufweist.

Der pResult-Parameter enthält spezielle Informationen zu den Gründen, warum die beiden Assemblys als äquivalent betrachtet werden. Weitere Informationen finden Sie unter AssemblyComparisonResult-Enumeration.

Anforderungen

Plattformen: siehe Systemanforderungen für .NET Framework.

Header: Fusion.h

Bibliothek: als Ressource in MsCorEE.dll enthalten

.NET Framework-Versionen: 4

Siehe auch

Referenz

AssemblyComparisonResult-Enumeration

Shfusion.dll (Assembly Cache Viewer-Tool)

CompareAssemblyIdentity-Funktion

Weitere Ressourcen

Fusion – Globale statistische Funktionen

Änderungsprotokoll

Datum

Versionsgeschichte

Grund

Mai 2011

Fehler in der ursprünglichen Dokumentation wurden korrigiert.

Kundenfeedback.

März 2011

Fehlende API-Dokumentation wurde hinzugefügt.

Korrektur inhaltlicher Fehler.