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?

[Phoenix]

Zitat:

Zitat von himitsu (Beitrag 1112678)

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

Es gibt drei Runtimes: 1.1, 2.0 und 4.0.
4.0 hat die 2.0 immer im Bauch (auch in der 30 MB großen Client-Profile Variante).

Das heisst um wirklich alles im .NET Bereich ausführen zu können braucht man lediglich 1.1 und 4.0. Wobei die 1er nicht mehr wirklich Relevant ist.

[Phoenix]

Zitat:

Zitat von Viktorii (Beitrag 1112688)

Zitat:

Zitat von jfheins (Beitrag 1112674)

multicast delegates spricht für sich denke ich.

Was ist denn eine multicast delegate?

Eine Delegate ist im Prinzip nichts anderes als ein Funktionspointer.

Mit dem was so technisch 'Multicast Delegate' heisst kann man einfach gesagt an ein einziges Event mehrere Handler gleichzeitig dran hängen und alle werden ausgeführt.

In Delphi kann ein Event immer nur genau eine Methode ausführen. Ausser man trickst ein bissel rum (ich hab hier mal vor Jahren eine Multicast-Delegate Klasse für Delphi gepostet).

[daywalker9]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1112662)

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.

Ja, VS 2010 ist mit .NET und WPF programmiert worden.

[Stevie]

Zitat:

Zitat von Phoenix (Beitrag 1112691)

Zitat:

Zitat von Viktorii (Beitrag 1112688)

Zitat:

Zitat von jfheins (Beitrag 1112674)

multicast delegates spricht für sich denke ich.

Was ist denn eine multicast delegate?

Eine Delegate ist im Prinzip nichts anderes als ein Funktionspointer.

Mit dem was so technisch 'Multicast Delegate' heisst kann man einfach gesagt an ein einziges Event mehrere Handler gleichzeitig dran hängen und alle werden ausgeführt.

In Delphi kann ein Event immer nur genau eine Methode ausführen. Ausser man trickst ein bissel rum (ich hab hier mal vor Jahren eine Multicast-Delegate Klasse für Delphi gepostet).

Für neuere Delphi Versionen (ab 2010) hab ich auch mal eine geschrieben ;)

Zum Thema: Obwohl ich mich primär als Delphi Entwickler sehe, hab ich in der Vergangenheit von .Net sehr viele Impulse bekommen gerade was meine Library angeht und ich schau mir immer gerne Sachen direkt aus dem Framework oder aus .Net Projekten ab. Durch die geringere Bürde an Altlasten und der GC kann .Net an vielen Stellen einfach seine volle Kapazität ausspielen, was in Delphi nicht oder nur sehr umständlich geht. Dafür hat Delphi wieder an anderen Stellen seine Stärken.

[divBy0]

Mir gefällt das mit den Frameworks nicht so...

WinForms...WPF...Silverlight... Was denn jetzt?

[Bernhard Geyer]

Zitat:

Zitat von divBy0 (Beitrag 1112706)

Mir gefällt das mit den Frameworks nicht so...

WinForms...WPF...Silverlight... Was denn jetzt?

VCL, CLX, VCL.NET, wxWidgets - Was denn jetzt?
Von den ganzen Webtechniken die Borland/Emba... die Jahre über immer mal für 1-2 Versionen eingeführt und dann wieder verworfen hat ganz zu schweigen ...

[Medium]

Ich mags :)
Nicht zuletzt, weil ich so auch ohne die Kosten für ein D2010 in den Genuss von Generics komme, die Lib sonst auch vieles zu bieten hat, wo ich für Delphi immer erst Fremdcode suchen muss (der oft genug nicht "mal eben einfach" eingebunden und funktionstüchtig ist), und es mit #Develop eine freie IDE gibt, an der ich bislang kaum etwas vermisse (das mag in einer Corporate-Umgebung etwas ander aussehen, aber für privat und Kleinprojekte ist die top).
Ich empfinde die Arbeit mit .NET immer sehr "flüssig".

[divBy0]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1112707)

VCL, CLX, VCL.NET, wxWidgets - Was denn jetzt?
Von den ganzen Webtechniken die Borland/Emba... die Jahre über immer mal für 1-2 Versionen eingeführt und dann wieder verworfen hat ganz zu schweigen ...

CLX, VCL.NET gibts aber auch in den aktuellen Delphi-Versionen nicht mehr zur Auswahl.

[Bernhard Geyer]

Zitat:

Zitat von divBy0 (Beitrag 1112710)

CLX, VCL.NET gibts aber auch in den aktuellen Delphi-Versionen nicht mehr zur Auswahl.

Weiß ich. Und viele würden gerne den Zustand haben das "alte" Technik noch ein paar Jahre mitläuft und sie nicht alles nach 1-2 Jahren wegschmeißen müssen wenn Sie die IDE aktualisieren.

[Ralf Kaiser]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1112712)

Zitat:

Zitat von divBy0 (Beitrag 1112710)

CLX, VCL.NET gibts aber auch in den aktuellen Delphi-Versionen nicht mehr zur Auswahl.

Weiß ich. Und viele würden gerne den Zustand haben das "alte" Technik noch ein paar Jahre mitläuft und sie nicht alles nach 1-2 Jahren wegschmeißen müssen wenn Sie die IDE aktualisieren.

Ich erinnere da nur mal an die Datenbank "Blackfish". Diese sollte ja die neue Datenbanktechnologie darstellen (das beste seit der Erfindung des geschnittenen Brotes). Wer damals damit ein größeres Projekt gestartet hat war hinterher ganz schön in den Hintern gekniffen...:wink:

In Bezug auf "neue Techniken" hat Borland/CodeGear/Emba in den letzten Jahren ziemlich wenig Planungssicherheit geboten. Wer fängt schon mit einer komplett neuen Technologie an wenn damit zu rechnen ist, dass diese in ein oder zwei Versionen einfach wieder verschwindet?

Die Gefahr, dass das .NET Framework plötzlich erstzlos gestrichen wird ist da wesentlich geringer.

[Ralf Kaiser]

Zitat:

Zitat von Medium (Beitrag 1112709)

und es mit #Develop eine freie IDE gibt, an der ich bislang kaum etwas vermisse

Da drängt sich mir die Frage auf: Kann man in SharpDevelop auch andere (.NET-)Sprachen einbinden? Ich denke da an Prism! :wink:

[Bernhard Geyer]

Zitat:

Zitat von Ralf Kaiser (Beitrag 1112717)

Ich erinnere da nur mal an die Datenbank "Blackfish". Diese sollte ja die neue Datenbanktechnologie darstellen (das beste seit der Erfindung des geschnittenen Brotes). Wer damals damit ein größeres Projekt gestartet hat war hinterher ganz schön in den Hintern gekniffen...:wink:

Glücklicherweise ist es bei uns wegen Lizenzkosteneinschränkungen (wir brauchen Royality-Free-Verteilung mit DB-Größe > 10 GB) ziemlich früh raus gefallen.

[Stevie]

Zitat:

Zitat von Ralf Kaiser (Beitrag 1112718)

Zitat:

Zitat von Medium (Beitrag 1112709)

und es mit #Develop eine freie IDE gibt, an der ich bislang kaum etwas vermisse

Da drängt sich mir die Frage auf: Kann man in SharpDevelop auch andere (.NET-)Sprachen einbinden? Ich denke da an Prism! :wink:

Ich meine mich zu erinnern, dass du mit Prism eh das VS (oder wars nur die Shell) bekommst, in die es sich integriert und du somit eh nix anderes brauchst, aber das kann Sebastian bestimmt besser beantworten. ;)

[Medium]

Prinzipiell ist #Develop dahingehend erweiterbar, man muss nur entweder eine Einbindung finden oder selber bauen (Highlighter-Definitionen, Compilerschalter und so Dinge). Von Hause aus waren, als ich zuletzt geupdated habe, C#, Boo und J# Unterstüzung drin. VB.NET kann auch sein, da bin ich grad nicht sicher. Aber wer will das schon ;)

[Phoenix]

Zitat:

Zitat von Stevie (Beitrag 1112725)

Zitat:

Zitat von Ralf Kaiser (Beitrag 1112718)

Zitat:

Zitat von Medium (Beitrag 1112709)

und es mit #Develop eine freie IDE gibt, an der ich bislang kaum etwas vermisse

Da drängt sich mir die Frage auf: Kann man in SharpDevelop auch andere (.NET-)Sprachen einbinden? Ich denke da an Prism! :wink:

Ich meine mich zu erinnern, dass du mit Prism eh das VS (oder wars nur die Shell) bekommst, in die es sich integriert und du somit eh nix anderes brauchst, aber das kann Sebastian bestimmt besser beantworten. ;)

Äh.. ein ganz klares JAIN :)
Ja, Prism bringt die Visual-Studio Shell mit. Prism kann sich allerdings auch in ggf. frühere vorhandene VisualStudio Editionen (ausser Express) einklinken.

Prism gibts aber auch in MonoDevelop. MonoDevelop ist ein Fork von #Develop, das zuerst von Windows Forms auf Gtk# umgestellt wurde und auch ansonsten Massiv aufgebohrt wurde.
Gtk# deshalb, damit es auch auf dem Mac und auf Linux läuft. Und das tut es sehr gut. ;-)

[marcoX]

Zitat:

Zitat von jaenicke (Beitrag 1112649)

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...

Stimmt, das mit dem Management Studio hatte ich selbst mal gesehen, war mir aber leider entfallen.

Zitat:

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.

Das ist korrekt, aber man kann ja auch in Delphi den Compiler anweisen nicht alles mit einzukompilieren und dann DLLs beilegen. Dann hat man auch nur eine wenige KB große EXE.

Ist mir jedenfalls (die Geschmäcker sind da sicher verschieden) als ein Framework.

[Ralf Kaiser]

Zitat:

Zitat von marcoX (Beitrag 1112764)

Das ist korrekt, aber man kann ja auch in Delphi den Compiler anweisen nicht alles mit einzukompilieren und dann DLLs beilegen. Dann hat man auch nur eine wenige KB große EXE.

Ist mir jedenfalls (die Geschmäcker sind da sicher verschieden) als ein Framework.

Wobei: Wenn man die VCL und anderen nötigen Teile eines Programmes als BPLs beilegt, was hat man dann?

Eben: Man hat ein Framework beigelegt (oder muss es zum Download anbieten) :wink:

[marcoX]

Zitat:

Zitat von Ralf Kaiser (Beitrag 1112765)

Zitat:

Zitat von marcoX (Beitrag 1112764)

Das ist korrekt, aber man kann ja auch in Delphi den Compiler anweisen nicht alles mit einzukompilieren und dann DLLs beilegen. Dann hat man auch nur eine wenige KB große EXE.

Ist mir jedenfalls (die Geschmäcker sind da sicher verschieden) als ein Framework.

Wobei: Wenn man die VCL und anderen nötigen Teile eines Programmes als BPLs beilegt, was hat man dann?

Eben: Man hat ein Framework beigelegt (oder muss es zum Download anbieten) :wink:

Man muss ja nicht die ganze VCL beilegen, das was manan DLLs beilegen muss, ist nicht sonderlich viel, ich glaube wenige MB, war jedenfalls damals beim C++ Builder so. Und auch bei C# muss man neue "Komponenten" in Form von DLLs beilegen.

Ich finde die Delphi-Lösung jedenfalls weit flexibler. Ich kann es einkompilieren, ich kann es aber auch lassen.

[Phoenix]

Zitat:

Zitat von marcoX (Beitrag 1112767)

Ich finde die Delphi-Lösung jedenfalls weit flexibler. Ich kann es einkompilieren, ich kann es aber auch lassen.

Was ist daran flexibler? Das geht mit .NET bzw. mit Mono auch. Man kann mittels Full-Ahead-of-Time compilation auch die Teile der Runtime in eine native .exe einkompilieren die benötigt werden. Das ist dann das gleiche was Delphi mit seiner RTL macht. Dann wird die .exe halt ein klein wenig größer, man braucht aber dafür kein Framework zu installieren. Hat halt den Nachteil, dass man das dann pro Plattform neu kompilieren muss, also separat für OS-X, Linux und Windows. Ach.. moment.. das kann Delphi ja nicht. Also ist man mit Mono dann doch flexibler ;-)

[holliesoft]

Zitat:

Zitat von Phoenix (Beitrag 1112690)

Zitat:

Zitat von himitsu (Beitrag 1112678)

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

Es gibt drei Runtimes: 1.1, 2.0 und 4.0.
4.0 hat die 2.0 immer im Bauch (auch in der 30 MB großen Client-Profile Variante).

Das heisst um wirklich alles im .NET Bereich ausführen zu können braucht man lediglich 1.1 und 4.0. Wobei die 1er nicht mehr wirklich Relevant ist.

Quelle? Gerade in einer VM getestet: Windows XP ohne irgend ein .net Framework, .net Framework 4 Full Installer installiert, Anwendung für .net 2.0 gestartet, Fehlermeldung:

---------------------------
MergeMovies.exe - .NET Framework Initialization Error
---------------------------
Unable to find a version of the runtime to run this application.
---------------------------
OK
---------------------------

So weit ich weiß:
1. Runtime 1.1
2. Runtime 2.x => .net Framework 2, 3.0, 3.5
3. Runtime 4.0

[Phoenix]

Zitat:

Zitat von holliesoft (Beitrag 1112777)

Quelle? Gerade in einer VM getestet: Windows XP ohne irgend ein .net Framework

Nehm mal ein anständiges OS das keine 10 Jahre als ist, wie z.B. Vista oder 7 ;-)
Bei XP muss man die 2.0er Runtime tatsächlich noch manuell Nachinstallieren.

[holliesoft]

Zitat:

Zitat von Phoenix (Beitrag 1112778)

Nehm mal ein anständiges OS das keine 10 Jahre als ist, wie z.B. Vista oder 7 ;-)
Bei XP muss man die 2.0er Runtime tatsächlich noch manuell Nachinstallieren.

<Erbsenzaehlmodus>
Das ist mir klar, denn Vista wurde mit .net 3.0 und Windows 7 wird mit .Net 3.5 Sp1 ausgeliefert.
Mir ging es ja nur um die Aussage:

Zitat:

Zitat von Phoenix

4.0 hat die 2.0 immer im Bauch (auch in der 30 MB großen Client-Profile Variante).

</Erbsenzaehlmodus>

;-)

[jaenicke]

Zitat:

Zitat von marcoX (Beitrag 1112764)

Das ist korrekt, aber man kann ja auch in Delphi den Compiler anweisen nicht alles mit einzukompilieren und dann DLLs beilegen. Dann hat man auch nur eine wenige KB große EXE.

Ist mir jedenfalls (die Geschmäcker sind da sicher verschieden) als ein Framework.

Hier wird deine Argumentation... äh... seltsam...
Grund:
Wenn du das mit Delphi machst, hast du für jede einzelne Delphiversion unterschiedliche Bibliotheken, die der Anwender ggf. installieren muss. Nämlich dann, wenn er das eine Tool benutzt, das in Delphi 7 geschrieben ist, eins von Delphi 2009, eins von XE, ...

Und dann wird die Datenmenge riesig. Oft deutlich mehr als beim .NET Framework, bei dem in der Regel wie genannt die 4.0er Installation genügt.

[Phoenix]

Zitat:

Zitat von holliesoft (Beitrag 1112779)

<Erbsenzaehlmodus>

Ja, hast ja recht :)
Was ich meinte war dass auch .NET 4.0 Prozesse .NET 2.0 Assemblies laden und ausführen können, was mit 2.0 und 1.1 ja nicht funktioniert.

[marcoX]

Zitat:

Zitat von jaenicke (Beitrag 1112785)

Wenn du das mit Delphi machst, hast du für jede einzelne Delphiversion unterschiedliche Bibliotheken, die der Anwender ggf. installieren muss. Nämlich dann, wenn er das eine Tool benutzt, das in Delphi 7 geschrieben ist, eins von Delphi 2009, eins von XE, ...

Naja, ich glaube die 4MB lassen sich auch verschmerzen! ;)

Ich will hier keinen Streit entfachen, aber ich liebe einfach native Software. Ist vielleicht z.T. auch ein Gefühlsding. Bei Linux sehe ich das übrigens ähnlich. Auf dem Server sind shared libs das beste, was es geben kann. Auf dem Desktop würde ich mir (optinal) viel mehr statisch gelinkte Packete wünschen, mit denen man mal eben eine portable Software schnüren kann.

[Insider2004]

.net ist doch schon halbtot. Microsoft hat doch schon gesagt, es langsam einzustellen. HTML5 und Java sind die Nachfolgetechnologien.

[Phoenix]

Zitat:

Zitat von Insider2004 (Beitrag 1112814)

.net ist doch schon halbtot. Microsoft hat doch schon gesagt, es langsam einzustellen. HTML5 und Java sind die Nachfolgetechnologien.

:roll: Die Quelle dazu hätte ich gerne mal gesehen.

[Bernhard Geyer]

Zitat:

Zitat von Insider2004 (Beitrag 1112814)

.net ist doch schon halbtot. Microsoft hat doch schon gesagt, es langsam einzustellen. HTML5 und Java sind die Nachfolgetechnologien.

Weis du was der Unterschied zwischen Java und JavaScript ist und wie willst du mit HTML5 und JavaScript Serverkomponenten bauen?
Es ist jetzt so das MS jetzt auch HTML5+JS als primäre GUI-Technik neben Silverlight/WPF/WinForms unterstützen wird.

[Phoenix]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1112816)

Es ist jetzt so das MS jetzt auch HTML5+JS als primäre GUI-Technik neben Silverlight/WPF/WinForms unterstützen wird.

Auch das haben sie so nicht gesagt. Es wurde bisher lediglich gesagt, dass Tiles für die Metro-Shell ausschliesslich mit Html5 + JS gebaut werden können. Mehr dazu haben sie nicht gesagt. Und ich bin mir sicher, dass selbst Microsoft Ihr Office, VS, Media Player und ihre anderen Anwendungen nicht auf Html-GUI's umstellen wird.

Will heissen vorne der Launcher wird das (wieder) können. Und that's it. Mit Html auf dem Desktop haben sie sich zu Zeiten von Win98 schon in die Nesseln gesetzt (damals hiess das 'Active Desktop', kann sich noch wer daran erinnern?) und hat sich auch nicht durchgesetzt.

Die einzige sinnige Idee könnte sein, Web-Anwendungen direkt auf dem Desktop laufen zu lassen. Also Facebook (oder die DP) als 'native' Windows-App, aber sonst? Sowas wie Google Docs oder Office 365 auf dem Desktop? Die sind nett wenn man Unterwegs ist, aber auf dem Desktop will ich eine 'richtige' Anwendung haben.

[Bernhard Geyer]

Zitat:

Zitat von Phoenix (Beitrag 1112818)

Auch das haben sie so nicht gesagt. Es wurde bisher lediglich gesagt, dass Tiles für die Metro-Shell ausschliesslich mit Html5 + JS gebaut werden können. Mehr dazu haben sie nicht gesagt. Und ich bin mir sicher, dass selbst Microsoft Ihr Office, VS, Media Player und ihre anderen Anwendungen nicht auf Html-GUI's umstellen wird.

Nicht unbedingt. Wenn man sieht was es für Apps schon als reine Browser-Lösung gibt könnte irgendwann mal fast jede App als HTML5/JS-Lösung laufen.

Zitat:

Zitat von Phoenix (Beitrag 1112818)

Mit Html auf dem Desktop haben sie sich zu Zeiten von Win98 schon in die Nesseln gesetzt (damals hiess das 'Active Desktop', kann sich noch wer daran erinnern?) und hat sich auch nicht durchgesetzt.

Klar kenn ichs. War eines der ersten Dinge die ich abgeschaltet haben wenn ich einen neuen PC aufgesetzt habe. Aber wenn man Vista/Win7 diese Sidebar sieht, so ist das doch dahingehend was weiterentwickeltes. Und diese Sidebar wird häufiger sinnvoll eingestzt als der alte Active desktop

Zitat:

Zitat von Phoenix (Beitrag 1112818)

Die einzige sinnige Idee könnte sein, Web-Anwendungen direkt auf dem Desktop laufen zu lassen. Also Facebook (oder die DP) als 'native' Windows-App, aber sonst? Sowas wie Google Docs oder Office 365 auf dem Desktop? Die sind nett wenn man Unterwegs ist, aber auf dem Desktop will ich eine 'richtige' Anwendung haben.

Du (und ich) will bei solchen Apps eine richtige Anwendung. Aber wenns gut genug implementiert ist wird es vielen egal sein ob die App lokal oder im Browser läuft. Für Unternehmen ist es natürlich einfacher wenn alle relevanten Apps zentral einmal eingespielt werden und dann von dort über Browser performant laufen. Aber bis ein Inventor/ProE oder NX als solche Lösung läuft dauert es noch. Bei PLM/ERP-Lösung geht m.E. eindeutig der Weg in den Browser/Weblösung.