Converter VB 6 in C#

[Jesus]

siehe Titel.
Gibts sowas ?

Ich kenne nur VB6 zu VB.NET konverter (der im VS integriert ist) und der funktioniert eher schlecht als recht. Gitbs einen sehr guten VB 6 zu C# konverter ?

[-xenonite-]

nette Idee, koennte man ja mal programmieren wenn man viel Code wandeln muss. Der Code ansich wäre wohl auch kein Problem, ich sehe da eher ein Problem mit speziellem, wie der API, win32-Kommandos und der GUI.

[Jesus]

ich habs aufgegeben, da kommt man auf keinen grünen Zweig. Gibt einfach zu viele Änderungen zw. vb6 und vb.net, von c# ganz zu schweigen.

M$ sollte sich da wirklich mal was einfallen lassen, wenn sie schon den support für VB6 droppen.

[Kinman]

gui wär nicht so schlimm, solang man alles in der IDE plaziert hat --> frm bzw. frx dateien auslesen.

mfg Kinman

[Grestorn]

Da VB6 nicht wirklich objektorientiert ist, im Gegensatz zu VB.NET oder C#, ist es ohnehin angebracht, VB6 SW erst mal so zu lassen wie sie ist und bei Gelegenheit komplett durch eine völlig neu entwickelte C# Version zu ersetzen.

Nur eines ist schlimmer als VB6 Code: Konvertierter VB6 Code.

[Crushinator]

(...) Nur eines ist schlimmer als VB6 Code: Konvertierter VB6 Code. Dem muß ich weitestgehend zustimmen und noch hinzufügen, daß nach meinem Empfinden ein von VB4 bis nach VB6 mitgeschleppter und dann konvertierter Code noch schlimmer ist. ;)

[Gumpel]

...und bei Gelegenheit komplett durch eine völlig neu entwickelte C# Version zu ersetzen.Das wird wohl sehr sehr sehr lange dauern. Nicht umsonst ist heute noch 70% aller Software in COBOL geschrieben. Ich habe auch keine Ambitionen unsere tausende DIN A4-Seiten Code von VB6 in C# oder VB.net umzusetzen.

[Trap]

Zum Thema funktionierende Anwendungen neu entwickeln:
http://c2.com/cgi/wiki?RewriteCodeFromScratch

[Grestorn]

Das wird wohl sehr sehr sehr lange dauern. Nicht umsonst ist heute noch 70% aller Software in COBOL geschrieben. Ich habe auch keine Ambitionen unsere tausende DIN A4-Seiten Code von VB6 in C# oder VB.net umzusetzen.Und das ist ein großes Übel. Manchmal muss man die Ärmel hochkrämpeln und Software neu entwickeln. Andernfalls schleppt man Müll immer länger mit sich rum, schreibt Work-Arounds und Adapter für Alt-Code. Irgendwann wird alles so unübersichtlich, dass es nahezu unwartbar wird und die Aufwände ins Astronomische steigen.

Ich arbeite u.a. für einen sehr sehr großen Konzern, der größtenteils mit IBM Großrechnern arbeitet (womit ich Gott sei dank wenig zu tun habe). Ihr könnt Euch gar nicht vorstellen, wie schrecklich verkrustet die Software dort ist, und welche Klimmzüge jeden Tag gemacht werden, um damit klarzukommen.

[HellHorse]

Und das ist ein großes Übel. Manchmal muss man die Ärmel hochkrämpeln und Software neu entwickeln.
Ja gut, COBOL ist eine eigene Geschichte. Es gibt ja Leute die sagen, die durchschnittliche COBOL Software sei 30 Jahre alt, weil man erst nach 15 Jahren anfängt damit Gewinn zu erwirtschaften und vermutlich liegen sie damit gar nicht mal so weit von der Wahrheit entfernt. Und es gibt Leute, die heute Software, die in 30 Jahren noch laufen muss, in COBOL schreiben würden. So was stimmt einen doch nachdenklich.