VisualBasic Programm unter 64/32 bit

Hallo
ich habe ein Programm geschrieben in VB.net, das auf meinem Pc funktioniert. Ich hab es dann aber auf einem anderen Computer ausprobiert. Auf diesem verhält das Programm sich ganz anders. Manche Sachen funktionieren, andere nicht. (z.b kann die Picturebox kein Bild laden, Dateien werden nicht erkannt usw.)
Auf beiden Rechnern ist die selbe Version des .net Frameworks drauf. Der einzige Unterschied ist, dass auf mein Computer ein 64bit Windows 7 und auf dem anderen ein 32bit Windows XP.

Ist das das Problem? Wenn ja, wie umgeh ich das?
Danke für die Hilfe
Gruss Gil

"Picturebox kein Bild laden, Dateien werden nicht erkannt" <-- etwas präzisere Fehlerbeschreibungen wären sinnvoll...

An 32/64 bit dürfte es nicht dran liegen. Ein 64 bit Prog lässt sich nicht einfach so auf einem 32 bit System nutzen.
Ich kenn mich mit VB.net nicht aus, könnte als nur Vermutungen anstellen.
Vielleicht liegt es an unterschiedlichen Bibliotheken.

Das Programm läuft aber ohne Fehler?

z.b. kann die Picturebox kein Bild laden, Dateien werden nicht erkannt

Zum Vergrößern anklicken....

liegt das Bild auf deinem Rechner?
Was macht das Prog?

Nur mal so aus dem Buch heraus würde ich sagen, dass nicht 64/32 bit das Problem ist, sondern XP und Win7.

Womit arbeitest du denn ? Visual Studio ? Office ? Setz dir doch mal Haltepunkte wo er meckert und schlag in den MSDN nach ob das ne XP oder Win7 ... Sache is.

Gruß

HD

Das sind nur 2 von vielen Beispielen. Es ist nich so, das eine Fehlermeldung kommt. Manche Teile des Programms funktionieren einfach nicht. Ich möcht wissen, ob das einen Zusammenhang mit den verschiedenen Betriebssystemen haben könnte.

Ich arbeit mit der Visual Studio 2008 Express Edition.

Das Bild zb. liegt im selben ordner wie die .exe und wird mit "picturebox1.image = "curdir ()/xxx/xxx" geladen.

Ich würde mal den Ansatz von HansDampf38 verfolgen.
Könnte an XP und Win 7 liegen.
Zur Not einfach mal schnell auf nem anderen Win 7 System probieren, wenn du die Möglichkeit hast.

@Gilrich: Eventuell wären mehr Probleme hilfreich oder auch einfach mal realer Code...
Was für ein Dateiformat haben die Bilder?

@HansDampf38: Kennst du dich mit .net aus?
Ich halte es mit WinXP vs Win7 als nicht sooo wahrscheinlich, schließlich stellt das .net-Framework eine eigene Schicht dar.

Es wird ganz sicher an den verschiedenen Systemen liegen.

Hast du mal konkret Code der unter Win7 läuft und unter Win XP nicht ?

Ich wiederhole die Frage nochmals: Kennst du dich mit .net aus?

Ich bin übers Wochenende weggefahren und komm nicht an meinen Code ran. Ich werde in posten, sobald ich zu Hause bin.

Also mal spontan würde ich sagen das hier am falschen Baum gebellt wird!

1. Das .Net Framework macht in der Standard-Compiler-Einstellung kein Problem aus 64 oder gar 32 Bit. In beiden Fällen läuft der Code, da als Standard eigentlich die Option "Any CPU" eingeschaltet ist. Es sei denn du stellst diesen Schalter bewußt auf 64 Bit dann wirst du auf dem 32 Bit ein Problem haben. Andersrum wenn du auf 32 Bit stellst, sollte das auch auf der 64 Bit Kiste laufen, da hier dieses WOW. oder wie es heißen mag. für die Kompatibilität sorgt

2. Das .Net Framework stellt sicher, das die verfügbaren Klassen auch auf allen unterstützten OS Versionen laufen, es sei denn du bindest direkt die Windows API ein, was man aber eigentlich vermeiden sollte.

3. "curdir ()/xxx/xxx" Ist die mieseste Möglichkeit um das aktuelle Verzeichnis der auszuführenden Assembly zu ermitteln, da das Verzeichnis zwar bei Programmstart u.U, auf das Installationsverzeichnis der Assembly verweist. Aber zum Beispiel wenn du die Assembly über einen Link mit einem anderen Arbeitsverzeichnis startest, sitzt du in der Scheiße, da CurDir nun das andere Arbeitsverzeichnis ausgibt. Wenn du einen Datei öffnen/Datei speichern Dialog in der Assembly verwendest, steht das Verzeichnis auf dem letzten ausgewählten Verzeichnis. Es sei denn du stellst die entsprechende Eigenschaften des Dialogs anders ein. Schließlich und letztendlich ist CurDir völlig unbestimmt, was es für ein Verzeichnis ausgibt. Ach ja das ist kein Bug, sondern ein Feature!

Alternative für das Ermitteln des Installationsverzeichnis deiner Assembly nimmst du besser System.AppDomain.CurrentDomain.BaseDirectory. Im übrigen wäre es vielleicht auch gut den Pfad nicht auf die von dir angegebene Art zu bilden, sondern stattdessen über System.IO.Path.Combine. Wäre ja vielleicht schön wenn die App dann auch unter Linux/Unix mit Mono lauffähig wäre.

Aber sei es wie es sei, krempel die Ärmel hoch und schau mal ob du noch weitere solche Eier im Code hast. Desweiteren würde ich mal behaupten, dass du auf dem 32 Bit System andere Schritte zum Testen gehst, als in der 64 Bit Umgebung. Wenn du Fragen hast, dann stelle sie, aber konkreter und lass hier nicht jeden im Dunkeln stochern!