Mögt ihr das .NET Framework? Ich bis heute nicht

[marcoX]

Also ich konnte mich trotz aller Lobhuddelei irgendwie nie damit anfreunden.

Das hat Gründe:

Nummer 1) Ich sehe den Sinn nicht so. Gut, für MFC-Programmierer ist C++ .NET sicher ein Segen, bloß vieles über was sich dort gefreut wird, konnte der C++ Builder schon vor 12 Jahren - nativ! Und wenn ich sehe, was mit der VCL (oder Units wie Synapse) alles möglich ist (bald sogar Cross Compiling), dann frage ich mich, wozu man das Framwork-Gedöns denn bitte braucht? Und verschiedene Sprachen...nun es gibt die VCL für Delphi, für den C++ Builder und für PHP, zeitweise gab es sie sogar für C#. Wenn das Borland/Embacadero mit den winzigen Mitteln alles kann, was könnte dann bloß Microsoft alles?

Nummer 2) Die "Umstände". Im Grunde brauch ich bei einem 100KB .NET Programm immer 40MB Gedöns. Gut, bei einem .NET 2.0 Programm kann man davon ausgehen, dass es relativ viele haben, setze ich aber auf .NET 4 muss man selbst bei Vista den ganzen Kram mitliefern oder zumindest einen Web-Installer anbieten. Und das, wo viele Anschlüsse auf dem Land immer noch ISDN haben - meine Kunden können vom ".NET mit ISDN nachladen" ein Lied singen. Aufgrund der fehlenden Aufwärtskompatibilität (wie auch) wird sich das Problem auch in Zukunft nicht lösen lassen.

Ich bin wirklich happy, dass es mit Delphi/Lazarus eine letzte Bastion gegen den totalen .NET Zwang gibt!

Was ich übrigens wirklich sehr amüsant finde:
Microsoft entwickelt seine Tool selbst nicht mit .NET. Weder portiert es Anwendungen (auch kleinere nicht), noch habe ich Software entdeckt, die MS selbst in .NET programmiert hätte.

[FredlFesl]

Was hat dot.NET mit VCL oder Synapse zu tun?

[jaenicke]

Zitat:

Zitat von marcoX (Beitrag 1112644)

Was ich übrigens wirklich sehr amüsant finde:
Microsoft entwickelt seine Tool selbst nicht mit .NET. Weder portiert es Anwendungen (auch kleinere nicht), noch habe ich Software entdeckt, die MS selbst in .NET programmiert hätte.

Das stimmt so nicht.
Im Businessbereich wird/wurde z.B. Microsoft Dynamics NAV auf C# portiert.
Das SQL Management Studio ist in C# geschrieben, ebenso zumindest Teile von Windows Live. Die Zune Software ebenfalls. Diverse Tools wie IDEs und Compiler sind mit einer .NET Sprache geschrieben worden (Visual Studio, Sharepoint, serverbasierte Dienste wie ASP, die MSDN-Webseite u.a. selbst, Team Foundation Server, XBox Live, ...).

Da gibt es schon sehr viel. Und dass nicht alles auf .NET portiert wird, ist eben auch eine Kosten-/Nutzenfrage...

Zitat:

Zitat von marcoX (Beitrag 1112644)

Im Grunde brauch ich bei einem 100KB .NET Programm immer 40MB Gedöns.

Dafür sind die einzelnen Anwendungen sehr klein. Wenn du zehn native Anwendungen hast, sind diese auch locker 40 MiB groß. In .NET geschrieben gerade einmal 1 MiB. Und in Lazarus geschriebene Anwendungen sind sogar eher noch größer.

Jetzt überlege dir einmal, dass deine Benutzer nur ISDN haben. Du machst jetzt 5 Updates. Dann musst du bei einer .NET Anwendung gerade mal ein paar KiB jeweils übertragen. Bei einer nativen Anwendung musst du aber jedesmal mehrere MiB übertragen...

Zudem hast du als Entwickler sehr viel weniger Aufwand, weil du sehr viel bereits im Framework zur Verfügung hast, was du z.B. in Delphi alles nachprogrammieren oder mit zusätzlichen Komponenten abdecken musst. Das alles muss dann aber auch in die Anwendung einkompiliert werden, so dass diese größer wird. Und du hast den Aufwand.

Ich selbst entwickle zwar auch lieber nativ in Delphi, aber die Vorteile von .NET sehe ich durchaus und ich arbeite auch immer wieder mal damit, sei es mit Delphi Prism oder C#.

[FredlFesl]

Zitat:

Zitat von marcoX (Beitrag 1112644)

Wenn das Borland/Embacadero mit den winzigen Mitteln alles kann, was könnte dann bloß Microsoft alles?

Hast Du überhaupt eine Ahnung, was dot.NET ist?

Zitat:

Zitat von marcoX (Beitrag 1112644)

Ich bin wirklich happy, dass es mit Delphi/Lazarus eine letzte Bastion gegen den totalen .NET Zwang gibt!

Dann sind C, Java, php und (so gut wie) alle Web-Applikationen also schon .NET-Zwang?

Mir scheint, Du hast einfach etwas gegen dot.NET, weisst aber gar nicht, warum? ==> Glaube = nichts wissen ==> Religion.

[Daniel]

ehm ... ist das der Versuch, eine Diskussion über Ideologien loszutreten? Nunja ... ein bisschen fundierter müsste die Kritik schon sein, wenn Du an einer ernsthaften Diskussion interessiert bist. Derzeit liegt diese Diskussion auf gleicher Ebene wie zum Beispiel "Ich mag keine Erbsensuppe". Da mag man als Außenstehender nur sagen "Ja und? Ist sein gutes Recht, isst er halt was Anderes."

Das Thema .NET ist hier und woanders x-mal durchgekaut worden. Das .NET-Framework hat technische Eigenschaften, die sich nicht wegdiskutieren lassen und sehr viele Entwickler arbeiten hochproduktiv damit. Natürlich steht es Dir frei, eine Technologie abzulehnen. Du solltest Dir nur darüber im Klaren sein, dass diese "Stammtisch-Mentalität" eine gewisse Professionalität vermissen lässt.

[Bernhard Geyer]

Zitat:

Zitat von marcoX (Beitrag 1112644)

Und verschiedene Sprachen...nun es gibt die VCL für Delphi, für den C++ Builder und für PHP, zeitweise gab es sie sogar für C#. Wenn das Borland/Embacadero mit den winzigen Mitteln alles kann, was könnte dann bloß Microsoft alles?

Der Vergleich hinkt. Im Gegensatz zu VCL für .NET ist die FCL verwendbar. VCL.NET war eine Todgeburt. Von "VCL" für PHP ist sehr fraglich wie weit es eingesetzt wird. Auch hat VCL.Delphi wenig mit VCL.PHP gemein. Schon mal eine Portierung probiert? Auch ja: Und läuft VCL schon auf Smartphones (werden ja bald öfter verkauft als Windows-PC's). Und erst gestern musste ich (ok, ist D6) noch einen ziemlichen Bug in Delphi bei verwendung von Widestrings umschiffen (ist in XE gefixt).

Zitat:

Zitat von marcoX (Beitrag 1112644)

Microsoft entwickelt seine Tool selbst nicht mit .NET. Weder portiert es Anwendungen (auch kleinere nicht), noch habe ich Software entdeckt, die MS selbst in .NET programmiert hätte.

Ist nicht VS.NET mittlerweile mit NET entwickelt? Diverse ander Tools auch.

[jfheins]

Ich sehe .net zum Großteil als "Delphi VCL 2.0" - und das hat mehrere Gründe. Zum einen natürlich Anders Hejlsberg aber auch sonst gibt es viele Parallelen.

Manche Dinge finde ich in .net besser gelöst - angefangen mit den multicast delegates, über die Sicherbarkeitsdefinitionen bis hin zu den Unicodes Strings.

Unicodes Strings: Waren von Anfang an* dabei. In Delphi kann es da zu Problemen kommen, wenn die Komponente nicht mit Unicode getestet wurde. (Okay, lässt sich kaum vermeiden wenn man das Framework umstellt...)
Sichtbarkeiten: In Delphi gibt es private, protected, public, published, strict private und strict protected. Die Sichtbarkeit hängt auch damit zusammen ob die Klassen in einer Datei stehen oder nicht.
Mir gefällt das Prinzip mit den namespaces besser - Man kann z.B. eine Datei pro Klasse hernehmen und braucht sich noch nichtmal um Kreuzverweise Gedanken zu machen!

multicast delegates spricht für sich denke ich. Auch wenn ich es noch nicht gebraucht habe, sowas habe ich auch lieber direkt in der Sprache integriert. Man kann sich in Delphi zwar eine Lösung zusammenschustern, aber das Kostet ziemlich viel Zeit und man ist darauf angewiesen, diese Lösung auch immer zu benutzen. Fremdcode lässt sich aber nicht immer so leicht anpassen.

Zum Abschluss noch ein kleiner Codeschnipsel, den ich sehr cool finde:

Code:

                for (int i = 0; i < files_lv.Items.Count; i++) // Listview durchiterieren
                {
                    if (files_lv.Items[i].Checked) // Nur die angehakten
                    {
                        ThreadPool.QueueUserWorkItem(new WaitCallback(Calculate), i); // Multithreaded
                        //Calculate(i); // Sequenziell
                    }
                }

Durch Benutzen der einen oder der anderen Zeiel ist die Komplette Berechnung entweder sequenziell oder komplett Multithreaded. Keine zusätzliche Änderung nötig.
Zugegeben, ich musste erst etwas suchen bis ich den ThreadPool gefunden hatte. Und alles nach Calculate() muss damit zurecht kommen, in einem Thread aufgerufen zu werden. Da wurden also schon Anpassungen fällig. Aber ich finde das Stückchen Code trotzdem genial :-D

* = ab .net 2.0, vorher hab ich's nicht benutzt

Ach ja, asp.net ist natürlich auch noch eine super Sache. Ich hab's mir einmal angesehen und meine Begeisterung für PHP ist schlagartig gesunken :mrgreen:
Und ja, wenn man sich geschickt anstellt kann man den gleichen Code einmal als Desktop Anwendung und einmal als Webservice verwenden.

[himitsu]

Zitat:

Zitat von jaenicke (Beitrag 1112649)

Zitat:

Zitat von marcoX (Beitrag 1112644)

Im Grunde brauch ich bei einem 100KB .NET Programm immer 40MB Gedöns.

Dafür sind die einzelnen Anwendungen sehr klein. Wenn du zehn native Anwendungen hast, sind diese auch locker 40 MiB groß. In .NET geschrieben gerade einmal 1 MiB.

Laufen .Net 1.0 Anwendungen auch in .Net 2, 3 oder 4?

Wenn nicht, dann
2 in .Net 1.x
2 in .Net 2.x
2 in .Net 3.x
2 in .Net 4.x
und jeweils noch das Framework dazu.

Dann ist Lazarus doch noch kleiner :stupid:

[Bernhard Geyer]

Zitat:

Zitat von himitsu (Beitrag 1112678)

Laufen .Net 1.0 Anwendungen auch in .Net 2, 3 oder 4?

Es gibt noch verwendbare Anwendungen in .NET 1.0?:gruebel:

Damit bleiben nur noch .NET 2 und .NET 4 übrig da ja .NET keine eigene Framework-Version ist.

[Viktorii]

Zitat:

Zitat von jfheins (Beitrag 1112674)

multicast delegates spricht für sich denke ich.

Was ist denn eine multicast delegate?

Was ein delegate ist, glaube ich verstanden zu haben. Im Prinzip das was bei Qt ein Slot ist !?!

Aber was heißt in dem Zusammenhang multicast?