Laden...

Zwei DLLs unterschiedlicher Version mit Alias - erste Referenz wird nie gefunden

Erstellt von Palladin007 vor einem Jahr Letzter Beitrag vor einem Jahr 589 Views
Palladin007 Themenstarter:in
2.094 Beiträge seit 2012
vor einem Jahr
Zwei DLLs unterschiedlicher Version mit Alias - erste Referenz wird nie gefunden

Hi,

ich habe ein Projekt im alten csproj-Format (kein SDK Format) und 4 DLLs in je 2 Versionen.
Ich habe die DLLs daher entsprechend der Version umbenannt und ihnen je einen Alias passend der Version gegeben.
Die DLLs sind auch alle privat, sie werden von "außen" geladen, darum muss ich mich also nicht kümmern.

Das Ergebnis in der csproj (Reference-Items sortiert, damit V17_5 oben steht):

<Reference Include="Microsoft.VisualStudio.ExtensionEngine.V17_5">
  <HintPath>..\..\lib\2022\Microsoft.VisualStudio.ExtensionEngine.V17_5.dll</HintPath>
  <Private>False</Private>
  <Aliases>V17_5</Aliases>
</Reference>
<Reference Include="Microsoft.VisualStudio.ExtensionEngineContract.V17_5">
  <HintPath>..\..\lib\2022\Microsoft.VisualStudio.ExtensionEngineContract.V17_5.dll</HintPath>
  <Private>False</Private>
  <Aliases>V17_5</Aliases>
</Reference>
<Reference Include="Microsoft.VisualStudio.ExtensionManager.V17_5">
  <HintPath>..\..\lib\2022\Microsoft.VisualStudio.ExtensionManager.V17_5.dll</HintPath>
  <Private>False</Private>
  <Aliases>V17_5</Aliases>
</Reference>
<Reference Include="Microsoft.VisualStudio.ExtensionsExplorer.V17_5">
  <HintPath>..\..\lib\2022\Microsoft.VisualStudio.ExtensionsExplorer.V17_5.dll</HintPath>
  <Private>False</Private>
  <Aliases>V17_5</Aliases>
</Reference>
    
<Reference Include="Microsoft.VisualStudio.ExtensionEngine.V17_7">
  <HintPath>..\..\lib\2022\Microsoft.VisualStudio.ExtensionEngine.V17_7.dll</HintPath>
  <Private>False</Private>
  <Aliases>V17_7</Aliases>
</Reference>
<Reference Include="Microsoft.VisualStudio.ExtensionEngineContract.V17_7">
  <HintPath>..\..\lib\2022\Microsoft.VisualStudio.ExtensionEngineContract.V17_7.dll</HintPath>
  <Private>False</Private>
  <Aliases>V17_7</Aliases>
</Reference>
<Reference Include="Microsoft.VisualStudio.ExtensionManager.V17_7">
  <HintPath>..\..\lib\2022\Microsoft.VisualStudio.ExtensionManager.V17_7.dll</HintPath>
  <Private>False</Private>
  <Aliases>V17_7</Aliases>
</Reference>
<Reference Include="Microsoft.VisualStudio.ExtensionsExplorer.V17_7">
  <HintPath>..\..\lib\2022\Microsoft.VisualStudio.ExtensionsExplorer.V17_7.dll</HintPath>
  <Private>False</Private>
  <Aliases>V17_7</Aliases>
</Reference>

Der Alias V17_7 wird auch erkannt, V17_5 allerdings nicht.

Zuerst (nachdem ich sie hinzugefügt habe) hat er die Referenzen erkannt und im Properties-Fenster auch einen Pfad angezeigt. Nach einem Neuladen des Projektes wurden die Referenzen mit einer Warnung markiert und es wird kein Pfad mehr angezeigt. Gefunden wurde der V17_5 Alias aber nie, egal ob Visual Studio die Referenz angeblich findet, oder nicht.
Wenn ich die Reihenfolge der Reference-Einträge vertauscht (17.7 zuerst), ist das Verhalten genau umgekehrt, er finden V17_5, aber nicht V17_7

Die Warnung, die er anzeigt, ist langweilig:

The referenced component [XYZ.dll] could not be found.

Weiß jemand, woran das liegt und wie ich das beheben kann?

Besten Dank 😃


Es geht um dieses Projekt: https://github.com/madskristensen/ExtensionPackTools

Ich versuche Visual Studio 2022 und die jeweils aktuelle Preview zu unterstützen. Da die referenzierten DLLs sich zwischen den Versionen 17.5 und 17.7 aber unterscheiden, suche ich nach einem Weg, das zu unterscheiden. Der Plan war daher, für beide Versionen den entscheidenden Code, wo der Unterschied relevant sind, zwei mal in je eine Klasse zu schreiben und für die jeweilige Version entsprechend anzupassen. Zur Laufzeit sollte er dann die Version prüfen und nur die richtige Klasse passend zur Version verwenden, zur Not auch mit Reflection, damit der JIT nicht auf die Idee kommt, die falsche Klasse zu kompilieren.

Ob der Plan funktioniert, weiß ich nicht, so weit komme ich ja gar nicht, weil Visual Studio die zweite Version aus irgendeinem Grund nicht findet 😕

Die Alternative wäre, ein viertes Projekt und somit eine vierte Version der Extension anzubieten, allerdings würde ich das gerne vermeiden, dass man auch noch auf die konkrete Version (nicht nur 2022) gucken muss.

NuGet Packages im Code auslesen
lock Alternative für async/await

Beim CleanCode zählen nicht die Regeln, sondern dass wir uns mit diesen Regeln befassen, selbst wenn wir sie nicht befolgen - hoffentlich nach reiflichen Überlegungen.

16.861 Beiträge seit 2008
vor einem Jahr

Ganz grobe Hilfe: Aliase werden nicht bei allen Projekten unterstützt. Zum Beispiel gibts irgendein Grund, wieso das bei Projekten, die XAML-Dateien haben, nicht funktioniert.
Aber welche Projekte das genau war, weiß ich nicht mehr.

Palladin007 Themenstarter:in
2.094 Beiträge seit 2012
vor einem Jahr

Ich hab's jetzt mit zwei zusätzlichen Projekten gelöst, eine je Version.

Irgendwie schade, dass das Alias-Feature nur so halb funktioniert, aber meine Lösung tut's auch.

Zum Beispiel gibts irgendein Grund, wieso das bei Projekten, die XAML-Dateien haben, nicht funktioniert.

Ich habe zwar XAML-Dateien, aber das war bei mir nicht der Grund, zumindest nicht nur.

Ich hatte es auch nochmal mit einer extra DLL versucht, in der ich alle Versionen zusammenfasse (auch Visual Studio 15 und 16) und interessanter Weise hat's mit den Versionen 15, 16 und und einer der beiden 17-Versionen funktioniert, aber nur eine 17er Version, nie beide.

Vielleicht hängt es damit zusammen, dass die DLLs von Version 17.5 und 17.7 die gleiche Versionsnummer haben, obwohl sie sich unterscheiden.

NuGet Packages im Code auslesen
lock Alternative für async/await

Beim CleanCode zählen nicht die Regeln, sondern dass wir uns mit diesen Regeln befassen, selbst wenn wir sie nicht befolgen - hoffentlich nach reiflichen Überlegungen.