---

Hallo Zusammen,

ich habe eine Frage und würde mich sehr freuen, wenn Ihr mir hier helfen könntet.

Ich habe einen neuen Rechner mit 64 bit bekommen.
Hier soll auch vb.net Programme für 32 bit Rechner und gleichzeitig für 64 bit entwickeln werden.

Jetzt habe ich das Problem, die eine Anwendung, die ich habe, läuft jetzt nicht mehr auf 32 bit.
Was muß ich hier beachten?

Danke für jede Hilfe.

------------------
Schöne Grüße
Feyza : )

[Diese Nachricht wurde von Feyza am 30. Mrz. 2011 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hi,

lass erst mal wissen, mit welchem IDE Du arbeitest, dann kann ev. geholfen werden.

Und sollte es Visual-Studio sein, dann kannst Du in den Projekteigenschaften den Precompiler dazu zwingen, dann das Projekt für 32bit erstellt wird (damit wird es aller Wahrscheinlichkeit nach auf 32bit- und 64bit-Geräten lauffähig sein).

Projekteigenschaften ==> (Fenster) Kompilieren ==> (Button) Erweiterte Compilereinstellungen ==> Ziel-CPU

HTH, - alfred -

------------------
www.hollaus.at

---

Hallo alfred,

danke Dir für Deine Hilfe.

Ich habe das Visual Studio 2003 und 2008.
Bei 2008 finde ich das Menu Komplilieren, aber bei 2003 nicht.

Bei unseren Rechner im Betrieb ist nur die Framework 1.1 installiert.
Ich kann leider nicht die anderen Versionen von Visual Studio ausser 2003 für die Entwicklung verwenden, oder ist es möglich, dass ich selbst entwickelte Programme aus Visual Sudio 2008 auf Rechner mit Framework 1.1 laufen lassen kann?

------------------
Schöne Grüße
Feyza : )

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hi,

sorry, hier beginnt strategisches Freimachen des Hirns für neue Sachen, deswegen ist Framework 1.1 schon raus (sonst würd ich 4.0 oben nicht einlagern können). 

Für mich beginnt 64bit erst mit Framework 2.0, nicht mit 1.1 und auch nicht mit VS2003.

Nur diese Aussage ist wohl mit Vorsicht zu geniessen (siehe Verdrängungswettbewerb), mach einmal eine kleine EXE (ohne spezielle Einstellung f. Prozessortyp), und evaluiere die Byte-Länge einer Variable vom Typ 'Integer'.
Lass dieses EXE auf einem 64bit-System laufen, gibt Dir das Programm hier 4 zurück, kannst Du scheinbar eh nur 32bit-Apps mit Framework 1.1 und VS2003 erzeugen, liefert es 8 zurück, dann vermute ich mal schon, dass es einen Schalter gibt, nur woanders. 

- alfred -

------------------
www.hollaus.at

---

Zitat:

---

Original erstellt von Feyza:
... oder ist es möglich, dass ich selbst entwickelte Programme aus Visual Sudio 2008 auf Rechner mit Framework 1.1 laufen lassen kann?

[/B]

---

Hallo Feyza,

es ist etwas Gebastel, hat aber schon mal funktioniert: Du kannst versuchen, Dein 2.0-er Programm mit dem Compiler der 1.1 zu kompilieren und binden. Die (ellenlange) Kommandozeile siehst Du beim Buildvorgang im Ausgabefenster. Hier den Aufruf von vbc.exe in eine .bat schreiben, von 2.0 auf 1.1 umbauen, manuell starten und ... dann viel Glück.

Hast Du allerdings Klassen verwendet, die es erst seit der 2.0 gibt, wird's wohl nix.

Daneben gibt's bei mir im Build-Menü den Configuration-Manager, wo Einstellungen für verschiedene Platformen gemacht werden können.

@alfred: Nach meinem bisherigen Verständnis von .net sollten Programme durch die Intermediate Language doch platformunabhängig sein. Zumindest, was die Windows-Welt und Programme, die nur .net- Klassen verwenden betrifft ? Der Beitrag läßt jetzt doch Zweifel daran aufkommen.

Gruß, Michael

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von mseufert:
@alfred: Nach meinem bisherigen Verständnis von .net sollten Programme durch die Intermediate Language doch platformunabhängig sein. Zumindest, was die Windows-Welt und Programme, die nur .net- Klassen verwenden betrifft ? Der Beitrag läßt jetzt doch Zweifel daran aufkommen.

---

Wer sagt das? Ich sag mal so... Generell kann alles ab Windows XP .Net in allen Versionen, allerdings ist es ein riesen Unterschied, ob ein Programm 64bit-fähig oder nur in 32bit kompiliert wurde. Allein das Adressierungsverhalten und die einzelnen Variablen und Objekte unterscheiden sich teilweise extrem. Ebenfalls gibt es .Net 64bit und 32bit Komponenten, die zwar das gleiche machen, aber in Gänze nicht gleich sind. Daher wäre ein Programm, mal von der Kompatibilität abgesehen, sehr Fehlerbehaftet, wenn es mit 64bit-Komponenten kompiliert wurde und dann 32bit-Pendants nutzen müsste. Alles in allem kann ich nur sagen, dass das nicht gehen kann. Wenn du ein Programm in 32bit kompilierst, dann wird es auch unter 64bit erkannt und kann eben als 32bit-Applikation mit einer Adressierung von maximal 4GByte verwendet werden. Dies ist so, da .Net 64bit die 32bit-Komponenten mitliefert. Umgekehrt geht es aber nicht, da die Adressierung auf Grund des Betriebssystems ins leere laufen würde bzw. das Betriebssystem mit einer 64bit-Adressierung nichts anfangen kann.

------------------
MFG
Rick Schulz

Nettiquette (CAD.de)  -  Was ist die Systeminfo?  -  Wie man Fragen richtig stellt.  -  Unities

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hi,

>> Umgekehrt geht es aber nicht

Nur um sicher zu gehen. 

Auf dotNET aufbauende App's werden, wenn der Schalter für Ziel-CPU auf 'Any' gestellt ist, nicht für 32bit und nicht für 64bit kompiliert, sondern nur ein CIL-Code 'vorkompiliert' (wie auch immer das jetzt zu nennen wäre), der eigentliche Kompilierungsvorgang geschieht erst beim Start des EXE oder der DLL, hier wird von Framework der Zwischencode übersetzt und exekutiert.

Beim zweiten Kompiliervorgang weiß die EXE/das DLL ja schon, auf welchem Prozessor es läuft, kann sich damit gezielt auf den Prozessortyp festlegen und damit loslegen (damit sogar für den jeweiligen Prozessor die entsprechenden Optimierungen setzen).

Als solches braucht der Programmierer, so er nur Funktionen aus Framework benötigt, nicht darauf achten, auf welcher Ziel-CPU sein Programm laufen wird. Das Programm wird auf einem 32bit-OS mit 32bit-Verarbeitung/Adressierung arbeiten, bei 64bit-OS mit 64bit-Verarbeitung/Adressierung.

Als solches muß ich leider 'Umgekehrt geht es aber nicht' widerlegen, schon alleine die Einstellung der Ziel-CPU auf 'Any' ergibt, dass es eigentlich kein 'umgekehrt' gibt.

Soweit zur Theorie. 

In vielen Fällen reicht es nicht aus, nur mit Framework-eigenen Funktionen zu agieren, und ab dem Zeitpunkt, wo auf Treiber oder allg. auf unmanaged-Irgenwas hingegriffen werden muß, ist vorbei mit lustig. In diesen Fällen ist es sehr vorteilhaft, wenn sich der Programmierer zwei VBProj-Dateien (bzw. CSProj) anlegt - jeweils für Ziel-CPU=32bit und für Ziel-CPU=64bit und diese dann getrennt vorkompiliert.

Schon beim debuggen kommt man auf diesem Weg auf die Konflikte und nicht erst mit Abstürzen, wenn das Progi mal draussen ist.

-------------------------

Ich wollt da jetzt nicht auf Kritik los, ich verstehe Rick voll und ganz (siehe auch mein voriger Absatz), ich wollt nur aufklärend die doch sehr harten Worte 'umgekehrt geht nicht' ein wenig weichspülen. 

-------------------------

Praktische Ausführung:

Mach ich ein Progi mit nicht Framework-basierten Komponenten, dann teile ich ein:

a) eigenen Libraries, ausschliesslich Framework-basierend, Typ=DLL ==> diese werden mit Ziel Any-CPU kompiliert, fertig (CLR übersetzt/behandelt das dann selbst entsprechend des Prozessortyps)

b) HauptApp oder Lib's, die Schnittstellen zu 'anderen' Dingen (wie Treiber) benötigen, für die mach ich die Ziel-CPU Schaltung. Habe zar die gleichen VB- oder C#-Files (damit ich den Code nicht mehrfach aktualisieren muß), aber übergeordnet unterschiedliche VBProj/CSProj-Dateien (wo eben der Schalter Any/32/64 drin steht). Und dann erzeug ich damit in unterschiedlichen Zielverzeichnissen eben einmal 32-, einmal 64bit-Apps.

HTH, - alfred -

------------------
www.hollaus.at