C# Entwicklungsumgebungen

Zitat

Mono ist noch nicht so komfortabel wie SharpDevelop?

Mono ist keine Entwicklungsumgebung, sondern eine Laufzeitumgebung (Virtual Machine). Das was du benutzt hast, war wahrscheinlich MonoDevelop.

Ich kann dir als Entwicklungsumgebung nur SharpDevelop ans Herz legen. Unterstützt .NET 2.0, is schön schnell und hinkt dem Visual c# Express in keinster Weise hinterher. Ausserdem lassen sich mit SharpDevelop auch Programme in Boo oder mit GTK#-Oberfläche bauen. Das kannst du mit VC# vergessen...

Und wenn du Microsoft nicht über den Weg traust, dann nimm Java und nicht .NET

Der Unterschied zu Visual C# und Turbo C#?
Visual C# is von Microsoft und Turbo C# von Borland. Und naja, wir kennen ja die Qualität der Borland Entwicklungsumgebungen *hust*

Zitat von phxql

Und naja, wir kennen ja die Qualität der Borland Entwicklungsumgebungen *hust*

Ach so? Hmm, erklär mal jemandem, der bisher mit Delphi zufrieden war, was an Borland-IDEs so schlecht ist.

Da ich seit mehr als 15 Jahren mit Borland-IDEs Software entwickele und bisher auch immer zufrieden war, würde mich das auch mal interessieren.

Ich habe 3 Jahre in der Arbeit mit Delphi 5 gearbeitet. Access Violation beim Speichern (Read of Adress 0x000000 in irgendwas.bpl failed) oder beim Kompilieren. Delphi 6 nie getestet. Delphi 7 zwar besser, aber trat immer noch auf. Delphi 8 hab ich selbst auch nie getestet, aber die Reaktionen darauf im Delphi-Forum mitbekommen. Delphi 2005 hatte ich die Personal, startete ewig und hatte auch lauter AccessViolations (beim Speichern, beim Beenden...)...

Damit haben sich die Borlandschen Entwicklungsumgebungen für mich erledigt. Wenn ich Angst haben muss, meine Arbeit nich mehr speichern zu können, hat der Hersteller versagt.

Zitat von phxql

Der Unterschied zu Visual C# und Turbo C#?
Visual C# is von Microsoft und Turbo C# von Borland. Und naja, wir kennen ja die Qualität der Borland Entwicklungsumgebungen *hust*

Microsoft hat den entscheidenen Vorteil, dass es das Betriebssystem auf welches die Entwicklungsumgebung abgestimmt werden muss, bestens kennt. An der Qualität von Borland kann ich nicht viel aussetzen. Habe bisher mit Turbo Pascal 5.5, Delphi 3 Professionell, Delphi 7 Personal und Delphi 2005 Personal gearbeitet. Bei letzterer stört mich die Behäbigkeit und die enthaltene Microsoft Hilfe.

Zitat von phxql

Damit haben sich die Borlandschen Entwicklungsumgebungen für mich erledigt. Wenn ich Angst haben muss, meine Arbeit nich mehr speichern zu können, hat der Hersteller versagt.

Diese Probleme hatte ich bisher nicht. Und ich bezweifle, dass diese Probleme allein Borland zuzuschreiben sind.

C# wollte ich auch ausprobieren. Jedoch nervt es, dass jede Entwicklungsumgebung ihre eigenen Projektdateien besitzt und eine Konvertierung anscheinend nicht möglich ist. So kann man nicht einfach eine Software installieren und beliebige Beispielprojekte ausprobieren.

Ab und zu hatte ich auch mal solche genannten Problemchen. Aber eigentlich nur, wenn ich selbst versucht habe, Komponenten zu entwickeln, oder haufenweise Komponenten von Freizeitautoren zu verwenden, und auch noch in DLLs einzusetzen. Insgesamt wirklich extrem selten.

Von C# hab ich bisher noch nicht viel gehört. Höchstens die Meinung, dass es vielleicht für kleinere Webanwendungen taugt, aber nicht für größere Anwendungsprogramme, womöglich noch mit Datenbankzugriffen... Keine Ahnung, in wiefern das zutrifft, da müsste ich erst mal den Sprachschatz kennen lernen.

Fr_An: SharpDevelop kann die Visual Studio-Projektdateien öffnen und umgedreht. Dass Borland ein anderes Format hat, is ja wohl klar. Aber ich bezweifle, dass es viele Leute gibt, die .NET mit Borland-Entwicklungsumgebungen nutzen, weil diese nur .NET 1.1 unterstützen und nicht schon das 2.0.

Das Fehlverhalten der IDE kann natürlich auch mit der Projektgröße zusammenhängen. 600.000 Zeilen (unter Delphi 5) Quellcode sind nicht wenig , aber trotzdem sollte eine IDE in dieser Preisklasse das schon zusammenbringen. Delphi 2005 PE hatte die Probleme auch schon bei Projekten mit 7 Zeilen.

Ich habe versucht, ein OpenSource C# Projekt mit BDS2005Personal zu öffnen. Borlands C# 2005 Personal brach die Konvertierung mit einer nichtssagenden Fehlermeldung ab.

SVCDPal2DVD habe ich mit Delphi 3 Professional begonnen, dann mit Delphi 7 Personal und jetzt Delphi 2005 Personal weiterentwickelt. Es gab selten Probleme.

Die NET 2.0-Unterstützung soll meines Wissens im nächsten Jahr kommen. Das die Microsoftprodukte es jetzt schon unterstützen, ist kein Wunder.

Ich hatte NET 1.1 auch nur installiert, weil es das BDS2005Personal verlangt. Programme, welche NET 2.0 benötigen, installiere ich erst nicht erst.

Bei mir hat sich die Frage, welches C# ich ausprobiere anscheinend vorerst erledigt.

Was soll mir dein erster Satz sagen? Dass Borland keine Importer schreiben kann?

Wenn Borland nächstes Jahr .NET 2.0 unterstützt, dann is das .NET 3.0 schon da. Und dass Microsoft .NET 2.0 kann, wundert mich auch nicht.
Aber: SharpDevelop ist nicht von Microsoft und kann .NET 2.0 trotzdem.
Naja, als Entwickler hast du 2 Möglichkeiten: Entweder du springst auf den .NET Zug auf oder du wirst überrollt. Ist wie mit der OOP... Zumindest seh ich das so. Aber das wird ja die Zukunft zeigen

Zitat von phxql

Was soll mir dein erster Satz sagen? Dass Borland keine Importer schreiben kann?

In dem Fall hatte es jedenfalls nicht geklappt.

Zitat von phxql

Naja, als Entwickler hast du 2 Möglichkeiten: Entweder du springst auf den .NET Zug auf oder du wirst überrollt. Ist wie mit der OOP... Zumindest seh ich das so. Aber das wird ja die Zukunft zeigen

Ich sehe das nicht so, dass man überrollt wird. Wenn man als Entwickler kein NET verwendet, läuft das Programm in den meisten Fällen trotzdem unter Windows. Verwendest Du NET, ist der Anwender gezwungen, NET zu installieren. Und im Falle von Delphi gibt es - zumindest bei Delphipraxis - kaum Unterstützung bei NET-Fragen.

Unter Windows XP SP 2 ist .NET 1.1 meines Wissens schon dabei. Vista wird von Haus aus .NET 2.0 mitbringen. Damit ist das Argument hinfällig.
Wenn Mono mal "fertig" ist, dann kannst du sogar .NET-Anwendungen unter Linux laufen lassen. Das zeigst du mir mal mit Delphi

Und die .NET-Binaries sind keine 700kb (wie bei Delphi) groß (was ja nur daran liegt, das Delphi die "Runtimes" in die Exe mit-einkompiliert).

Und klar, dass es bei delphi-praxis.de keine Unterstützung für .NET gibt, da die Unterstützung für .NET seitens Borland einfach nur noch schlecht ist. Dafür gibts andere große Communities für .NET. Okay, für Delphi.NET kenn ich keine, aber wer .NET macht, nimmt normalerweise C# oder VB.NET.

Sicher, dass NET beim SP2 dabei ist? In meiner Systemsteuerung steht nichts davon. :hm:

Vista interessiert mich nicht. Bis Anfang des Jahres habe ich nur mit Win98SE gearbeitet. Wegen des neuen DVD-Brenners, der kein IDE kann, musste ich gezwungenermaßen auf XP umsteigen.

Delphi ist für Windows. Für Linux gibt es Kylix. Das habe ich allerdings noch nicht ausprobiert. Und Delphi für NET nur ganz kurz und kann dazu nichts weiter sagen.

Als Hobbieprogrammierer kannst du natürlich einen Bogen um .NET machen. Aber wenn du das beruflich machst, wirst du dich irgendwann mit .NET beschäftigen müssen.

Sehe ich nicht so. Sowas hat man von Java auch mal behauptet und alle Welt musste plötzlich in Java programmieren. Ergebnis: Die beiden Aussagen "Wir entwickeln in Java" und "Wir haben Performance-Probleme" fallen grundsätzlich in einem Satz. Für .NET sehe ich eine ähnliche Zukunft.

Der Zweck von großen Laufzeit-Bibliotheken ist vor allem: Eine möglichst breite Basis, die einmal installiert wird, und auf die dann sehr verschiedene Programme zugreifen können.

Warum wohl sind z.B. VisualBasic-Programme immer so schön klein gewesen? -- Weil sie praktisch nur aus dem Aufruf von Funktionen in der VBRUN##.DLL bestehen. ## je nach VB-Compiler-Version. Eventuell auch noch ein paar *.VBX-Dateien.

In Delphi kann man ähnliches erreichen, wenn man voraussetzt, dass die Anwender jeweils alle nötigen *.BPL-Dateien im System haben. Je nach Compiler-Version.

Schon diese Beispiele zeigen: Gemeinsam verwendete Bibliotheken können Platz sparen und einen gemeinsamen Standard für verfügbare Funktionalitäten und Komponenten schaffen. Im Fall von .NET geht das sogar über mehrere Programmiersprachen hinweg (man kann hier durchaus Klassen in einer Sprache schreiben, in einer zweiten Sprache ableiten, und die Ableitung in einer Applikation in einer dritten Sprache benutzen).

Der Vorteil geht nur dann verloren, wenn man jedes Mal bei größeren Versionssprüngen wieder eine riesige Laufzeitbibliothek (oder gar das SDK) herunterladen und installieren muss (wie viele VBRUN-DLLs verschiedener Versionen habt ihr auf eurem Rechner?). Sicher sind Weiterentwicklungen gut. Aber wenn sie nicht zu älteren Versionen kompatibel sind, dann relativiert sich die "gemeinsame Nutzbarkeit" erheblich.

Zitat von zisoft

Sehe ich nicht so. Sowas hat man von Java auch mal behauptet und alle Welt musste plötzlich in Java programmieren. Ergebnis: Die beiden Aussagen "Wir entwickeln in Java" und "Wir haben Performance-Probleme" fallen grundsätzlich in einem Satz. Für .NET sehe ich eine ähnliche Zukunft.

Java und Performance-Probleme... Nenn mir mal ein anständiges geschriebenes Java-Programm was langsam is. Benchmarks haben ergeben, dass Java in vielen Bereichen schneller als c, c++ und Delphi ist.
Eclipse ist nicht langsam, Azureus auch nicht. Wenn Java langsam ist, dann liegt das an der GUI. Swing und AWT zeichnen die Steuerelemente ja selbst. Vorteil: Es sieht überall gleich aus, Nachteil: Schweinelangsam. Zum Glück gibts da sowas wie SWT (Standard Widgets Toolkit). Gut, damit geht ein bisschen platformunabhängigkeit drauf, aber unter Windows, Linux und Mac gehts immer noch.

Henrik: ich denke nicht, dass PureBasic ein derartig umfangreiches Framework bieten kann wie .NET. Ausserdem revolutioniert .NET das Programmieren ein bisschen, wie Ligh schon sagte, das Erstellen einer Klasse in einer beliebigen .NET-Sprache, und ich kann sie in jeder .NET-Sprache hernehmen.
Und es is ja irgendwie klar, dass wenn man Windows-Spezifische Sachen in sein Quelltext macht, dass es dann nur unter Windows geht ;). Da is der Entwickler aber selbst dran schuld.
Meine Versuche mit .NET und Mono haben mich angenehm überrascht. Hat (fast) alles auf Anhieb geklappt.

LigH: Es ist sogar Absicht, dass .NET 2.0 nicht abwärtskompatibel zu .NET 1.1 ist. Ich werf nur ein Stichwort in den Raum: "Dll-Hell". Mit .NET ist immer garantiert, dass ein Programm mit der .NET-Version ausgeführt wird, gegen die es auch kompiliert wurde. Und 20 MB für eine Runtime runterzuladen, das kann man dem User dann schon noch zumuten. Vor allem, weil es auf wirklich jeder CD von Computerzeitschriften drauf ist.

Und zwischen .NET und Java is noch ein Unterschied. Das eine wird von Sun gepusht, das andere von Microsoft. Und wir wissen ja, was derzeit den PC-Markt dominiert...