Benutzer mit den meisten Antworten
Ein Hauptprojekt für 32-Bit und/oder 64-Bit Betriebssystem erstellen (externe DLL's mit 32- als auch 64-Bit verwenden)

Frage
-
Hallo, ich habe eine Anwendung mit mehreren eingebundenen Projekten.
Diese Anwendung läuft noch auf WinXP-Rechnern (32-Bit) als auch auf Win10-Rechnern mit 64-Bit. Nun habe ich von einem externen (SAP) DLL's bekommen, um gewisse Dateien dort abrufen zu können. Jetzt würde ich das Projekt gerne so umstellen, das ich einmal das Projekt als "x86" erstellen lasse und auch als "x64".
Habe schon rumprobiert, aber das läuft nicht so. Habe mir das eine Projekt geschnappt mit den 32/64-bit DLL's und habe versucht die CSPROJ-Datei anzupassen. Leider ohnen korrekten Erfolg. Ich binde die DLL's als Beispiel als 32-Bit in die Verweise ein, ändere die "CSPROJ" -Datei ab, auch für die 64-Bit DLL's, aber wenn ich das Projekt mit der x64 starte, dann bekomme ich die Meldung er findet die DLL nicht.
Wenn ich in den Verweisen die 32-Bit-DLL's entferne, binde die 64-Bit-DLL's ein, dann läuft das Projekt mit "x64".
Irdendwie bekomme ich es nicht hin, das diese Projekt erkennt, wann es die 64-Bit DLL verwenden soll. Hier mal ein Beispiel und der Link wo ich das herhabe:
https://stackoverflow.com/questions/3832552/conditionally-use-32-64-bit-reference-when-building-in-visual-studio
Hier mal das Beispiel wie ich das gemacht habe:
<Reference Include="sapnco_utils_x64">
<HintPath>..\..\..\DLLS\SapZeichnungen\x64\sapnco_utils_x64.dll</HintPath>
</Reference>
<Reference Include="sapnco_x64">
<HintPath>..\..\..\DLLS\SapZeichnungen\x64\sapnco_x64.dll</HintPath>
</Reference>
<Reference Include="sapnco_utils_x86">
<HintPath>..\..\..\DLLS\SapZeichnungen\x86\sapnco_utils_x86.dll</HintPath>
</Reference>
<Reference Include="sapnco_x86">
<HintPath>..\..\..\DLLS\SapZeichnungen\x86\sapnco_x86.dll</HintPath>
</Reference>Bin mir nicht sicher ob man das eventuel in <PropertyGroup> </PropertyGroup> machen muss?
Wäre sehr dankbar um jede Hilfe
oema von MSDN
Antworten
-
Es geht zwar ein bisschen an deiner Frage vorbei, aber dein grundlegendes Problem hab ich mal so gelöst, dass ich zur Laufzeit auf das richtige DLL-Verzeichnis verwiesen hab.
Konkret sah das so aus:
Die Anwendung selbst wurde weiter auf AnyCPU kompiliert und wurde mit "x86"- und "x64"-Verzeichnis ausgeliefert, in der die jeweiligen Plattform-abhängigen 3rd-Party-Bibliotheken liegen.
In der Klasse, in der diese Bibliotheken benötigt werden, hab ich im Static-Konstruktor per SetDllDirectory den Suchpfad passend zur Plattform eingestellt.
public class MeineKlasse { [DllImport("kernel32.dll")] static extern bool SetDllDirectory(string lpPathName); static MeineKlasse() { string dllSubfolder = IntPtr.Size == 4 ? "x86" : IntPtr.Size == 8 ? "x64" : throw new Exception("Unbekannte CPU-Plattform"); string dllfolder = Path.Combine(Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location), dllSubfolder); if (!Directory.Exists(dllfolder)) { throw new Exception($"Verzeichnis {dllfolder} nicht gefunden."); } if(!SetDllDirectory(dllfolder)) { throw new Exception($"SetDllDirectory für {dllfolder} fehlgeschlagen."); } } }
Für meinen Fall hat das so wunderbar funktioniert.
- Als Antwort vorgeschlagen Dimitar DenkovMicrosoft contingent staff, Moderator Mittwoch, 8. Dezember 2021 14:02
- Als Antwort markiert Dimitar DenkovMicrosoft contingent staff, Moderator Donnerstag, 16. Dezember 2021 10:21
Alle Antworten
-
Hallo oema,
Eine DLL mit x86- und x64-Version enthält einen Platforms-Parameter in ihrem MSBuild PropertyGroup-Element. Der folgende Artikel bietet ein geeignetes Beispiel:
Vorgehensweise: Konfigurieren von Projekten für Zielplattformen > Beispiel: Verweisen auf x86- und x64-Assemblys und -DLLs
Wenn eine DLL nicht gefunden werden konnte, kann dies daran liegen, dass HintPath nicht berücksichtigt wird. Eine Lösung könnte darin bestehen, x86- und x64-Ordner, die Deine DLL enthalten, außerhalb des Projektverzeichnisses in das Projektmappenverzeichnis zu verschieben, wie hier beschrieben:
.Net Core project trying to conditionally reference 32/64 bit assembly but dotnet build always resolves 64bit
Gruß,
Ivan Dragov
Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „IT-Pros helfen IT-Pros“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.
- Bearbeitet Ivan DragovMicrosoft contingent staff, Moderator Mittwoch, 1. Dezember 2021 21:35
-
Hallo,
==>
Eine Lösung könnte darin bestehen, x86- und x64-Ordner, die Deine DLL enthalten, außerhalb des Projektverzeichnisses in das Projektmappenverzeichnis zu verschieben, wie hier beschrieben:
.Net Core project trying to conditionally reference 32/64 bit assembly but dotnet build always resolves 64bit< ==
Das habe ich leider nicht verstanden, wo ich die Dateien hinverschieben soll. Außerhalb des Projektverzeichnisses? Beispiel?
oema von MSDN
-
Es geht zwar ein bisschen an deiner Frage vorbei, aber dein grundlegendes Problem hab ich mal so gelöst, dass ich zur Laufzeit auf das richtige DLL-Verzeichnis verwiesen hab.
Konkret sah das so aus:
Die Anwendung selbst wurde weiter auf AnyCPU kompiliert und wurde mit "x86"- und "x64"-Verzeichnis ausgeliefert, in der die jeweiligen Plattform-abhängigen 3rd-Party-Bibliotheken liegen.
In der Klasse, in der diese Bibliotheken benötigt werden, hab ich im Static-Konstruktor per SetDllDirectory den Suchpfad passend zur Plattform eingestellt.
public class MeineKlasse { [DllImport("kernel32.dll")] static extern bool SetDllDirectory(string lpPathName); static MeineKlasse() { string dllSubfolder = IntPtr.Size == 4 ? "x86" : IntPtr.Size == 8 ? "x64" : throw new Exception("Unbekannte CPU-Plattform"); string dllfolder = Path.Combine(Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location), dllSubfolder); if (!Directory.Exists(dllfolder)) { throw new Exception($"Verzeichnis {dllfolder} nicht gefunden."); } if(!SetDllDirectory(dllfolder)) { throw new Exception($"SetDllDirectory für {dllfolder} fehlgeschlagen."); } } }
Für meinen Fall hat das so wunderbar funktioniert.
- Als Antwort vorgeschlagen Dimitar DenkovMicrosoft contingent staff, Moderator Mittwoch, 8. Dezember 2021 14:02
- Als Antwort markiert Dimitar DenkovMicrosoft contingent staff, Moderator Donnerstag, 16. Dezember 2021 10:21
-
Hallo, nach langer Zeit:
Hier hat sich die Lösung abgespielt (MSBuild "Referenz" in der CSPRJ-Datei).
Hier müssen die diversen DLL's eingefügt werden, damit die Applikation weiss was bei 32- oder 64-bit verwendet werden muss.
https://mycsharp.de/forum/threads/124049/in-applikation-alternativ-32-bit-oder-64-bit-dll-verwenden?page=1
oema von MSDN