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

[Phoenix]

Zitat von holliesoft:

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 von Phoenix:

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 von Phoenix:

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

</Erbsenzaehlmodus>

[jaenicke]

Zitat von marcoX:

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 von holliesoft:

<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 von jaenicke:

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 von Insider2004:

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

Die Quelle dazu hätte ich gerne mal gesehen.

[Bernhard Geyer]

Zitat von Insider2004:

.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 von Bernhard Geyer:

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 von Phoenix:

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 von Phoenix:

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 von Phoenix:

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.