Benutzer mit den meisten Antworten
VS2010 Klassenbibliotheken für x86 oder x64

Frage
-
Guten Morgen,
ich habe gestern den ganzen Tag daran gesessen, heute Morgen auch, aber ich komme nicht weiter und weiss ehrlich gesagt auch nicht wie ich meine Frage richtig formulieren soll.
Also, vor drei Jahren habe ich angefangen meine Klassen in einer Klassenbibliothek zu sammeln, ist ja auch nicht schwer. Alle meine Projekte haben eine Referenz zu der Klassenbibliothek, macht ja auch Sinn.
Mein Problem ging schon los, als ich von .NET 2.0 auf .NET 3.5 gewechselt bin, und jetzt .NET 4.0 und ganz schlimm wird es wenn ich zwischen einer x86 und x64 Anwenung mich entscheiden will/muss. Wobei sich mir oft die Frage stellt MUSS ICH WIRKLICH nach und nach auf x64 umstellen, aber das ist jetzt nicht unbedingt super wichtig.
Frage: Wie kann ich es erreichen, dass ich meine ganzen Klassen in einen ProjectSolution-Ordner unterbringe, wo alle meine Anwendungen später darauf verweisen und ich kann "bequem" zwischen .NET 2.0, 3.0, 3.5 und 4.0 wechseln oder gar zwischen x86 und x64 hin- und herschalten? In meiner Klassenbibliothek sind auch Verweise zu externen DLLs die mal in x86 und mal in x64 kompiliert sind, wo es natürlich immer wieder "ärger" gibt, weil dann die Meldung kommt das die Datei "im falschen Format" vorliegt.
Ich hoffe ich habe meine Frage ansatzweise vernünftig rübergebracht. Sieht irgendwie so aus als wenn ich selbst nicht wüsste was ich vorhabe :-)))
Aber ich muss irgendwie "Ordnung" reinbekommen. Derzeit wird z.B. auch bei Webanwendungen die Klasse zum abspielen und bearbeiten von MP3's hinzugefügt, auch bei einer ASP.NET Anwendung. Und würde ich jetzt alles aufknüppern und in einzelne Klassenbibliotheken packen, hätte ich 40 DLLs, mal übertrieben ausgedrückt, da ich ja viele Kategorien habe wie Sound, Bitmaps, DateTimeTools, HtmlParser etc. etc.
Wie bekomme ich aber die Ordnung hin? GIbt es da ein HowTo speziell zu diesem Thema? Oder muss ich vielleicht doch alles "zu Fuß" machen?
Gruß
Andy
PS: Ach ja, Visual Studio 2010 Prof. SP1 falls das wichtig ist.
Antworten
-
Hallo Karsten, hallo Andreas,
dass ein 64-Bit Prozess keine 32-Bit Komponente/DLL laden kann, ist kein MSFT/Windows spezifisches Problem, sondern ein allgemeines. Ein 32-Bit Prozess/DLL erfordert eine in Hardware oder Software emulierte x86 Umgebung und würde hier auch allein bei der Adressierung der Speicherbereiche enorme Probleme bekommen. Es ist hingegen meist kein Problem einen 32-Bit Prozess, samt 32-Bit Komponenten/DLLs in einem reinem 64-Bit System auszuführen. Via IPC können beide Prozesse dann auch untereinander kommunizieren.
Beantwortet dies Eure Frage?
Thorsten Dörfler
Microsoft MVP Visual Basic
vb-faq.de- Als Antwort markiert Robert BreitenhoferModerator Dienstag, 16. August 2011 09:52
-
Hallo Scotty,
da zeigt Dein Finger auf den falschen. Das Problem ist dort der Prozessor.
Der müsste parallel x86 (32-Bit) und x64 (64-Bit) Code ausführen können, siehe Intel 64Können täte es von den Intel-Prozessoren der Itanium, siehe z. B.:
http://www.heise.de/newsticker/meldung/IA32-Execution-Layer-fuer-Windows-erhaeltlich-91655.html
Nur der wiederum stirbt schon seit Jahren und Microsoft hat die Unterstützung
dafür (mangels Nachfrage) weitgehend aufgegeben.
(Derzeit beharken sich HP und Oracle, weil Oracle ihn auch nicht mehr unterstützen will).Deswegen gibt es dort nur eine Emulation auf Prozessebene:
http://blogs.msdn.com/b/oldnewthing/archive/2008/12/22/9244582.aspx
http://blogs.msdn.com/b/oldnewthing/archive/2005/10/05/477317.aspxDie (langsame) Alternative wäre den x86 Code durch eine Software-Emulation zu unterstützen.
Dagegen hat sich Microsoft aus gutem Grund entschieden -> es würde wieder gemeckert werden.Der Vollständigkeit halber das Verhalten von Visual Studio: X86,x64,IA64,Any CPU
Gruß Elmar- Als Antwort markiert Robert BreitenhoferModerator Dienstag, 16. August 2011 09:52
Alle Antworten
-
Hallo Andreas,
dieses hin- und herschalten zwischen x86 und x64 kannst Du Dir ganz einfach ersparen, indem Du die Klassenbibliotheken mit der Zielplattform "AnyCPU" erstellst. Hier entscheidet dann der Prozess, der das Assembly referenziert, ob es als 32-Bit oder 64-Bit ausgeführt wird. Es gibt heute nur noch ganz wenige Gründe explizit eine bestimmte Zielplattform anzugeben. Dies sind meist Interop Szenarien, wo bestimmte externe Bibliotheken verwendet werden müssen, die nicht als 64-Bit Version oder umgekehrt zur Verfügung stehen.
Für das Zielframework würdest Du separate Projekte benötigen, die aber die gleichen Sourcefiles einbinden. Wobei sich hier dann die Frage stellen würde, wozu Du die Framework Version ändern können sollst. Wenn Du ohnehin keine neuen Klassen einer höhreren Runtime Version verwendest, kannst Du das Assembly auch gegen .NET 2.0 erstellen und dieses auf jeden Fall in einer Anwendung, die .NET 3.0, 3.5 einbinden, da beide auf die gleiche CLR Version (2.0) setzen. Auch eine Verwendung in einer .NET 4.0 Anwendung sollte keine größeren Probleme aufwerfen. Hier wird dann auch nicht zusätzlich die Runtime für 2.0 geladen, sondern die Ausführung erfolgt komplett im .NET 4.0.
Thorsten Dörfler
Microsoft MVP Visual Basic
vb-faq.de -
Hallo Thorsten,
aha, also switcht die Klassenbibliothek automatisch zwischen x86 und x64 um, verstehe. Und ich habe schon angefangen viel viel zu viel zu machen was völlig unnötig ist.
Aber was ist mit den DLLs auf die in der Klassenbibliothek selbst verwiesen wird und ich keinen Sourcecode habe ? Nehmen wir z.B. BASS.DLL von un4seen.com. Die gibt es sowohl für x64 als auch x86. Der Name Bass.Dll bleibt immer gleich, ich kann die Datei leider nicht umbennen da sonst Bass.Net.Dll diese nicht findet.
Sagen wir mal ich habe in meiner Klassenbibliothek einen Verweis auf die x86er-Dll. Jetzt kommt meine Endanwendung und sagt "ich will in x64 kompilieren". Wie/Wo/Wem sage ich jetzt "Achtung, dann nehme die x64er-Dll von Bass.Dll" ? Kann man das irgendwie mit #If...#Then lösen? (Wie nennt man diese Befehle nochmal beim Namen die expliziet an den Compiler gehen? Compiler-Regeln?)
Gruß
Andy -
dieses hin- und herschalten zwischen x86 und x64 kannst Du Dir ganz einfach ersparen, indem Du die Klassenbibliotheken mit der Zielplattform "AnyCPU" erstellst. Hier entscheidet dann der Prozess, der das Assembly referenziert, ob es als 32-Bit oder 64-Bit ausgeführt wird.
Hallo Thorsten,
das würde ich so nicht unterschreiben, ich hatte letztens selber eine Solution die auf eine Access-DB zu gegriffen. Der Zugriff erfolgte mittels eines typisierten Dataset. Das funktionierte solange bis ein Projekt mit "AnyCPU"(alle anderen X86) hinzugefügt habe. Ziel-Framework 3.5, kompilieren - kein Problem, Start >> "27.000 Exceptions". Nach dem ich das hinzugefügte Projekt auch auf X86 umgestellt hatte lief die Anwendung wieder tadellos.
--
Gruß Scotty
-
Guten Morgen,
so, ich glaube ich habe jetzt eine Lösung gefunden und zwar über "Buildereignisse..."
Dort habe ich dann z.B. einen solchen Befehl hinzugefügt:
copy "$(ProjectDir)_DLL\$(PlatformName)\bass.dll" "$(ProjectDir)$(OutDir)"
Scheint zu funktionieren. Je nach Plattform "AnyCPU oder x86" wird dann auch die richtige DLL aus ..\bla\_DLL\x64\ oder ..\bla\_DLL\AnyCPU\ in das jeweilige Ausgabeverzeichnis kopiert und alle anderen Projekte die einen Verweis auf meine Klassenbibliothek haben nehmen sich dann auch die richtige DLL für AnyCPU bzw. x64.Anders war es (so glaube ich) leider nicht lösbar. Wenn ich es richtig gesehen habe, dann kann man in C++ z.B. folgendes im Quellcode einfügen:
#pragma comment(lib,"winmm.lib")
Das geht in VB.NET überhaupt nicht da der Compiler nur ein #If...#Then kennt wo ich höchstens weitere VB.NET-Befehle ranhängen kann, aber keine Anweisungen an den Compiler.
@Peter Fleischer
Ist also eine x64-Anwendung (also der Aufrufer) nicht Abwärtskompatibel zu einer x86-DLL nein? Habs jetzt noch nicht ausprobiert, hätte aber gedacht es würde gehen. Das von einer x86-Anwendung ein Aufruf zu einer x64-DLL Probleme macht, wäre mir klar. Aber umgekehrt?Gruß
Andy -
Hi Karsten,wenn ein Prozess nur 32-Bit unterstützt, wie beispielsweise die Jet, dann muss der Aufrufer auch als X86 laufen. Die ursprüngliche Frage war aber anders.--
Viele Gruesse
Peter
Hallo Peter,bescheidene Frage: Ein auf komplet auf 64-Bit ausgelegtes System kommt nicht einer 32-Bit Komponete klar? Wie traurig werden den Bilder denn noch in Richtung M$?
Ooh, lieber Gott, ich hoffe die denken langsam mal nach. (=:
Gruss Scotty
-
Hallo Karsten, hallo Andreas,
dass ein 64-Bit Prozess keine 32-Bit Komponente/DLL laden kann, ist kein MSFT/Windows spezifisches Problem, sondern ein allgemeines. Ein 32-Bit Prozess/DLL erfordert eine in Hardware oder Software emulierte x86 Umgebung und würde hier auch allein bei der Adressierung der Speicherbereiche enorme Probleme bekommen. Es ist hingegen meist kein Problem einen 32-Bit Prozess, samt 32-Bit Komponenten/DLLs in einem reinem 64-Bit System auszuführen. Via IPC können beide Prozesse dann auch untereinander kommunizieren.
Beantwortet dies Eure Frage?
Thorsten Dörfler
Microsoft MVP Visual Basic
vb-faq.de- Als Antwort markiert Robert BreitenhoferModerator Dienstag, 16. August 2011 09:52
-
Hallo Scotty,
da zeigt Dein Finger auf den falschen. Das Problem ist dort der Prozessor.
Der müsste parallel x86 (32-Bit) und x64 (64-Bit) Code ausführen können, siehe Intel 64Können täte es von den Intel-Prozessoren der Itanium, siehe z. B.:
http://www.heise.de/newsticker/meldung/IA32-Execution-Layer-fuer-Windows-erhaeltlich-91655.html
Nur der wiederum stirbt schon seit Jahren und Microsoft hat die Unterstützung
dafür (mangels Nachfrage) weitgehend aufgegeben.
(Derzeit beharken sich HP und Oracle, weil Oracle ihn auch nicht mehr unterstützen will).Deswegen gibt es dort nur eine Emulation auf Prozessebene:
http://blogs.msdn.com/b/oldnewthing/archive/2008/12/22/9244582.aspx
http://blogs.msdn.com/b/oldnewthing/archive/2005/10/05/477317.aspxDie (langsame) Alternative wäre den x86 Code durch eine Software-Emulation zu unterstützen.
Dagegen hat sich Microsoft aus gutem Grund entschieden -> es würde wieder gemeckert werden.Der Vollständigkeit halber das Verhalten von Visual Studio: X86,x64,IA64,Any CPU
Gruß Elmar- Als Antwort markiert Robert BreitenhoferModerator Dienstag, 16. August 2011 09:52