Wie schätzt Ihr die Weiterentwicklung von .NET ein?

[MGC]

Hallo liebe DP-ler,

mich würde mal Eure persönliche Meinung zur Weiterentwicklung von .NET interessieren.
Noch vor relativ kurzer Zeit sollte .NET die bestmögliche Umgebung der Zukunft sein, da durch den managed Code z.B. Virenangriffe eingedämmt werden sollten und angeblich auch eine JAVA-ähnliche Plattformübergreifenden Entwicklungsstandard zur Verfügung stehen sollte und nicht zu vergessen - die verbesserte Erstellung von verteilten Anwendungen insbesondere im Netzwerkbereich.

Viel konnte man lesen, das selbst Spieleprogrammierer auf .NET umstellen wollten, da der Leistungsverlust durch die neuen Rechnergenerationen wieder wettgemacht werden sollten.

In welchen Bereichen lohnt sich der Einsatz von .NET Eurer Meinung nach tatsächlich?
(z.B.: Anwendungen für den beruflichen oder auch privaten Bereich, Netzwerkanwendungen, usw.)

Ich freue mich auf Eure Beiträge.

Marc

[Memnarch]

Zitat:

Viel konnte man lesen, das selbst Spieleprogrammierer auf .NET umstellen wollten, da der Leistungsverlust durch die neuen Rechnergenerationen wieder wettgemacht werden sollten.

Hier zweifle ich dann am Verstand der Spielefirmen. Viele Spiele sind ja im NativenCode Performance mässig teilweise einfach nur Müll. Und dann auch noch den zusätzlichen Performanceverlust durch noch stärkere Rechner ausgleichen. Ohje >.<. Es wird ja teilweise schon nicht mehr für DualCore sondern primär für Quadcore optimiert. DC user fallen dan weg und QC User rattern dan plötzlich auch an der Schwelle zur unspielbarkeit?

Obige Aussagen beruhen auf meiner Sicht der Dinge im Bezug auf Aktuelle Spiele-Qualitäten(Nur Performance/Lauffähigkeit berücksichtigt...inhalt rede ich noch garnicht von^^).

EDIT: wenn oben Als SpieleProgrammierer eher IndieEntwickler gemeint sind, relativiert sich meine Aussage. Bei "richtigen" Firmen bleibt meine Aussage bestehen.

MFG
Memnarch

[MGC]

Soweit ich den Artikel (ist aber schon eine ganze Weile her, das ich ihn gelesen habe) richtig verstanden habe, sollten es wohl kommerzielle Spieleentwickler gewesen sein, die über einen solchen Schritt sinniert haben. Ich selbst sehe es aber ähnlich wie Du.

Mich hat halt Eure Meinung interessiert, denn selbst bekannte Buchautoren wie Elmar Warken haben seit Delphi 2005 hauptsächlich Delphi für .NET beachtet und im Hinblick auf Native Windows-Applikationen eher auf ältere Bücher (z.B. für Delphi 6) verwiesen.

[Phoenix]

Zitat:

Zitat von MGC (Beitrag 1082651)

Noch vor relativ kurzer Zeit sollte .NET die bestmögliche Umgebung der Zukunft sein, da durch den managed Code z.B. Virenangriffe eingedämmt werden sollten und angeblich auch eine JAVA-ähnliche Plattformübergreifenden Entwicklungsstandard zur Verfügung stehen sollte und nicht zu vergessen - die verbesserte Erstellung von verteilten Anwendungen insbesondere im Netzwerkbereich.

Wieso sprichst Du da eigentlich in der Vergangenheit bzw. im Konjunktiv? Ist doch alles gesetzt und schon lange Wirklichkeit.

Zudem: Es gibt keinen 'Leistungsverlust' durch .NET. Die Runtime verwaltet den Speicher in aller Regel effizienter als man es selber machen könnte und ist daher sogar performanter als man es ohne zusätzliche Optimierungen von Hand hinbekommen würden.

Genauso wie Java hat .NET seine Stärken vor allem im Server-Bereich: Enterprise-Anwendungen, Webanwendungen, Services, Kommunikation, Plattformunabhängigkeit. Im Gegensatz zu Java gibt es für .NET mit Silverlight, WPF und Windows Forms allerdings auch taugliche GUI-Frameworks.

[xaromz]

Hallo,

ich mache in letzter Zeit ziemlich viel mit .NET und was die Weiterentwicklung angeht bin ich sehr zuversichtlich. Die Entwickler konzentrieren sich in letzter Zeit vor Allem auf Parallelisierung. Mit der Verbreitung von Multicores ist das auch vernünftig. Bisher gibt es wenig Frameworks, die den Programmierer in diesem Bereich gut unterstützen. Insofern könnte es also durchaus sein, dass zukünftige Programme in .NET effizienter arbeiten als Native, einfach weil die Parallelisierung leichter geht.

Abgesehen davon ist IMHO .NET die mit Abstand beste Plattform für Webanwendungen. Mit ASPX und Silverlight wird eigentlich alles in diesem Bereich abgedeckt.

Zu Spielen: Ich habe letztes Jahr an der Entwicklung eines Spiels für XBox und PC mitgearbeitet. Das war in C# geschrieben unter Verwendung von XNA. Bis auf plattformspezifische Teile (Spielermanagement, Input, Leaderboards) ist der Code für beide Plattformen identisch. Die Performance ist auch in Ordnung, wir haben da genauso wie unter nativem Code ziemlich viel optimieren können. Der einzige Knackpunkt ist der GC, der auf der XBox leider ziemlich einfach implementiert ist (Compact Framework). Wir durften also während des Spiels keine Garbage Collection verursachen, weil dabei die gesamte Maschine angehalten wird. Da sollte MS schleunigst nachbessern.

Ach ja, durch WP7 kann man mit dem gleichen Framework Programme und insbesondere Spiele für Windows, XBox und Mobiltelefon schreiben, dass ist schon 'ne schöne Sache.

Gruß
xaromz

[Bernhard Geyer]

Zitat:

Zitat von xaromz (Beitrag 1082658)

... und Mobiltelefon schreiben,

Läuft Silverlight schon auf iOS, Android, Bada und WebOS? Oder nur für die "Randgruppe" Windows Phone7?

[MGC]

Zitat:

Zitat von Phoenix (Beitrag 1082656)

Wieso sprichst Du da eigentlich in der Vergangenheit bzw. im Konjunktiv? Ist doch alles gesetzt und schon lange Wirklichkeit.

Auif eine Weise stimmt dies, aber in letzter Zeit häufen sich auch gegenteilige Meinungen zur Zukunft der .NET-Plattform und daher habe ich die Vergangenheit und den Konjunktiv gewählt.

Zitat:

Zitat von Phoenix (Beitrag 1082656)

Zudem: Es gibt keinen 'Leistungsverlust' durch .NET. Die Runtime verwaltet den Speicher in aller Regel effizienter als man es selber machen könnte und ist daher sogar performanter als man es ohne zusätzliche Optimierungen von Hand hinbekommen würden.

Aber wie sieht es mit dem Leistungsverlust durch die "Restkompilierung" des managed Code aus? Welche Performance-Einbußen erhält man hieraus? Das würde mich interessieren, habe mit .NET noch nicht allzuviel gearbeitet. Daher auch mein Interesse. Die GC allerdings ist eine hervorragende Entwicklung, die einen Entwickler bei der Vermeidung von Speicherlecks sehr gut unterstützt.

Zitat:

Zitat von Phoenix (Beitrag 1082656)

Genauso wie Java hat .NET seine Stärken vor allem im Server-Bereich: Enterprise-Anwendungen, Webanwendungen, Services, Kommunikation, Plattformunabhängigkeit. Im Gegensatz zu Java gibt es für .NET mit Silverlight, WPF und Windows Forms allerdings auch taugliche GUI-Frameworks.

Die FCL haben wir ja Anders Hejlsberg zu verdanken, der die VCL mit Weiterentwicklung zu Microsoft gebracht hat. :wink:

Wie aber sieht es mit Cross-Platform aus, wie es zu Beginn der .NET-Ära angekündigt wurde? Ein Java-Runtime-Environment gibt es ja für nahezu jede Plattform.

[cookie22]

Zitat:

Aber wie sieht es mit dem Leistungsverlust durch die "Restkompilierung" des managed Code aus? Welche Performance-Einbußen erhält man heiraus? Das würde mich interessieren, habe mit .NET noch nicht allzuviel gearbeitet. Daher auch mein Interesse.

Den gibt es kaum, hat Phoenix ja auch schon geschrieben. Zum Teil ist .Net schneller als Nativ Code zum Teil etwas langsamer. Die Zeiten wo .Net langsam war, sind schon lange vorbei.

[MGC]

Zitat:

Zitat von cookie22 (Beitrag 1082663)

Zitat:

Aber wie sieht es mit dem Leistungsverlust durch die "Restkompilierung" des managed Code aus? Welche Performance-Einbußen erhält man heiraus? Das würde mich interessieren, habe mit .NET noch nicht allzuviel gearbeitet. Daher auch mein Interesse.

Den gibt es kaum, hat Phoenix ja auch schon geschrieben. Zum Teil ist .Net schneller als Nativ Code zum Teil etwas langsamer. Die Zeiten wo .Net langsam war, sind schon lange vorbei.

Heißt also, dass ich ruhigen Gewissens auf Delphi Prism umsteigen könnte ohne Performanceverluste zu erleiden. Das klingt doch schonmal recht angenehm, ins besondere da einem dann sowohl VCL als auch FCL zur Verfügung stehen würde.

Meine alten Anwendungen die ich in Delphi produziert habe, würde ich jedoch vorerst noch nicht portieren. (Nach dem Motto: Never change a running System)

[Hisoka]

Zitat:

Zitat von MGC (Beitrag 1082662)

Wie aber sieht es mit Cross-Platform aus, wie es zu Beginn der .NET-Ära angekündigt wurde? Ein Java-Runtime-Environment gibt es ja für nahezu jede Plattform.

Naja es läuft auf allen "Windows" Systemen mehr oder weniger gut.

Aber von Hause aus ist nur die Basis(also der Teil der ISO Standardisiert ist) Plattform unabhängig. Der Rest ist es nur bedingt( als Windows.Forms läuft großteils, WPF läuft gar nicht). Moonlight ist nur brauchbar wenn du auf DRM verzichtest, denn das darf auf einem Linux Desktop nicht verwendet werden(sagen die Lizenzbedingungen von MS für Play 4 Sure)


Also ein Java ist es nicht. Man kann nicht eben mal eine Anwendung mit GUI schreiben und sie läuft auf allen Systemen ohne Probleme. Die meisten .NET Anwendungen die ich bisher gesehen hab sind Plattform gebunden. Also sie laufen entweder auf Win oder unter Linux oder auf dem Mac. Einige wenige laufen mit erheblichen Aufwand und Win und OSX oder unter Lin und OSX. Anwendungen die gut unter allen Plattformen laufen sind selten.
Windows.Forms wird nicht auf jeder Plattform mitgeliefert, daher müssen die passenden Pakete extra ausgeliefert werden.

[Bernhard Geyer]

Zitat:

Zitat von MGC (Beitrag 1082664)

[Heißt also, dass ich ruhigen Gewissens auf Delphi Prism umsteigen könnte ohne Performanceverluste zu erleiden. Das klingt doch schonmal recht angenehm, ins besondere da einem dann sowohl VCL als auch FCL zur Verfügung stehen würde.

Nein. Unter Delphi.Prism steht dir nur FCL zur Verfügung. Die VCL.NET war nur in Delphi for .NET verfügbar und ist mit Delphi 2007 entgültig gestorben.

[MGC]

Zitat:

Zitat von Hisoka (Beitrag 1082665)

Also ein Java ist es nicht. Man kann nicht eben mal eine Anwendung mit GUI schreiben und sie läuft auf allen Systemen ohne Probleme. Die meisten .NET Anwendungen die ich bisher gesehen hab sind Plattform gebunden. Also sie laufen entweder auf Win oder unter Linux oder auf dem Mac. Einige wenige laufen mit erheblichen Aufwand und Win und OSX oder unter Lin und OSX. Anwendungen die gut unter allen Plattformen laufen sind selten.
Windows.Forms wird nicht auf jeder Plattform mitgeliefert, daher müssen die passenden Pakete extra ausgeliefert werden.

Also im Prinzip das gleich wie immer. :)
Eine Eierlegende-Wollmilchsau wird es leider wohl nie geben.:)

Aber da ich hauptsächlich für Windows-Plattfromen entwickle dürfte dies für mich eine eher untergeordnete Rolle spielen (ansonsten gibt es ja noch JAVA, mal ganz abgesehen davon, das sich Delphi ohnehin auch nicht für jedes eignet - egal ob W32 ode .NET).

Aber da meine Wurzeln bei Pascal liegen komme ich auch nicht einfach so von Delphi los.:wink:

[MGC]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1082667)

Zitat:

Zitat von MGC (Beitrag 1082664)

[Heißt also, dass ich ruhigen Gewissens auf Delphi Prism umsteigen könnte ohne Performanceverluste zu erleiden. Das klingt doch schonmal recht angenehm, ins besondere da einem dann sowohl VCL als auch FCL zur Verfügung stehen würde.

Nein. Unter Delphi.Prism steht dir nur FCL zur Verfügung. Die VCL.NET war nur in Delphi for .NET verfügbar und ist mit Delphi 2007 entgültig gestorben.

Hm, das ist schade, diese Entwicklung ist mir leider ein wenig abhanden gekommen. Somit hätte sich eine Portierung von Altprojekten nach Prism für mich dann ohnehin erledigt.
Aber wenigstens erklärt das für mich jetzt den deutlichen Preisunterschied zwischen Prism und Delphi W32, da ja allem Anschein nach die Forms-Entwicklung zu MS ausgelagert wurde.

[Memnarch]

Wenn ich das was ich verstanden habe kurz zusammenfassen darf: .NEt bringt keine "AHA" vorteile. Je nach komplexität ist mein Programm wie immer an eine Plattform gebunden, "Portierungen" müssen selbst erledigt werden. Einige stellen sind schneller, einige stellen sind langsamer als beim NAtiveCode. Fragt sich welche? CPU lastige berechnungen für z.B Physic&Co (ati nutzer bleiben halt softwaregefangen)?

Hab ich was vergessen?


MFG
Memnarch

[stahli]

Ich denke, man muss die Entscheidung stärker auf seine Ansprüche beziehen.

Für Internetanwendungen halte ich ASPX (Delphi Prism) für interessant (habe mal ein kleines Projekt erstellt). Man braucht einen Server, der ASPX unterstützt, dann ist die Anwendung über den Browser ja "Plattformunabhängig".

Anders sehe ich das mit Desktopanwendungen (wenn diese nur unter Windows laufen müssen). Da scheint mir natives Delphi doch noch effektiver (zumindest konnte ich mich mit Prism da noch nicht recht anfreunden). Vorteile sehe ich in dem Bereich bei der Desktopentwicklung nicht.
Dabei ist mir die Ausführungsgeschwindigkeit eigentlich weniger wichtig (ein paar zehntel Sekunden sind schon mal übrig).
Wichtiger ist mir die Art der Entwicklungsarbeit.
.NET erschließt sich mir noch nicht ganz. Irgendwie wirkt das auf mich etwas "eigenartig" und eher geeignet für Datenbankanwendungen. (Ist nur so ein Eindruck.)

Für Desktopanwendungen greife ich lieber auf das bewährte Delphi zurück und sehe im .NET keine Vorteile.

Die verschiedenen .NET-Versionen wirken auch nicht sehr überzeugend auf mich. Also ich bin skeptisch...

[mkinzler]

Zitat:

Läuft Silverlight schon auf iOS, Android, Bada und WebOS? Oder nur für die "Randgruppe" Windows Phone7?

Vom Monoprojekt existieren offizielle Versionen für iOS und Android, für webOS gibt es eine "inoffizielle" Implementierung und in einem Blog erwähnt Miguel de Icaza webOS.

[MGC]

Zitat:

Zitat von stahli (Beitrag 1082673)

Ich denke, man muss die Entscheidung stärker auf seine Ansprüche beziehen.

(...)

Wichtiger ist mir die Art der Entwicklungsarbeit.
.NET erschließt sich mir noch nicht ganz. Irgendwie wirkt das auf mich etwas "eigenartig" und eher geeignet für Datenbankanwendungen. (Ist nur so ein Eindruck.)

Für Desktopanwendungen greife ich lieber auf das bewährte Delphi zurück und sehe im .NET keine Vorteile.

Die verschiedenen .NET-Versionen wirken auch nicht sehr überzeugend auf mich. Also ich bin skeptisch...

@Stahli:

Vielen Dank für Deine Beurteilung der Situation. Somit schlägt der Zeiger für mich gerade wieder eher gegen Delphi Prism aus, da ich allerhöchstens ein wenig Netzwerk-Kommunikation zu bewältigen habe udn das sehr gut auch mit herkömmlichen Mitteln und DCOM erledigen kann.

[Robotiker]

Das .net-Framework ist heute wesentlich mehr als Forms und Datenbankzugriff.

Was mich im Moment sehr beschäftigt, sind die Möglichkeiten zur parallelen Programmierung. Dazu gibt es auf dieser Seite einige Infos:
http://parallelpatterns.codeplex.com/

In den nächsten Versionen kommt unter anderem einiges zur asynchronen und verteilten Programmierung:
http://msdn.microsoft.com/en-us/vstudio/gg316360
http://msdn.microsoft.com/en-us/devlabs/gg585582
http://msdn.microsoft.com/en-us/devlabs/gg585581
http://msdn.microsoft.com/en-us/devlabs/gg585584

Auch gibt es einige Zusatzpakete aus dem Bereich Scientific Computing, die zeigen, was mit .net alles geht:
http://www.solverfoundation.com/
http://research.microsoft.com/en-us/projects/bio/

[generic]

Ein generelles Problem im dotnet sehe ich noch, dass die Firmengeheimnisse (Programmlogik) nur schlecht versteckt sind.

Die IL kann man prima lesen. Gerade wenn es um Lizenz/Kopierschutz geht, muss man hier auf externe Tools setzen.

x86 Assembler lässt sich halt schlechter lesen als IL.
(ist aber auch für geübte kein Problem)


Parallele Entwicklung mit Delphi auch kein Problem -> OmniThread-Lib (Ich werde da demnächst einen Artikel schreiben)

[mkinzler]

Hierfür gibt es Obfuscatoren

[Bernhard Geyer]

Zitat:

Zitat von MGC (Beitrag 1082670)

Hm, das ist schade, diese Entwicklung ist mir leider ein wenig abhanden gekommen.

Das hast du dich wohl in den letzten Jahren sehr Rar im Codegear-Forum gemacht ...

Zitat:

Zitat von MGC (Beitrag 1082670)

... da ja allem Anschein nach die Forms-Entwicklung zu MS ausgelagert wurde.

Die Form-Entwicklung ist nicht ausgelagert. Prism verwendet halt als das was MS im Framework als IDE-Unterstützung bereit stellt und setzt auch auf den VS.NET-Kern auf. Sinnvoller als wie bei Delphi.NET zwanghaft mit Mannjahren versuchen das nochmal nachzuimplementieren aber die nötigen Spracherweiterugen zu verschlafen. Partial-Classes war der Tod des WinForms-Support in Delphi for .NET.

[MGC]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1082703)

Das hast du dich wohl in den letzten Jahren sehr Rar im Codegear-Forum gemacht ...

Ja, das gebe ich zu, war ein wenig eingefangen von meinen Projekten an der Arbeit und habe mich immer nur mal kurz um die .NET-Entwicklung gekümmert, da diese zum damaligen Zeitpunkt für mich kaum eine Relevanz für meine Projekte hatte.

Ich fasse hier also nochmal kurz für mich zusammen:
Es wird für mich auf jeden Fall interessant sich mit .NET mal richtig auseinanderzusetzen, insbesondere da ich im wissenschaftlichen Bereich tätig bin und auch wir über kurz oder lang mal unsere alten Rechner (Pentium 4) abschiessen werden und sich mir dann über das .NET-Framework mögliche Zusatzoptionen ergeben die ich unter W32 nur schwer umgesetzt bekomme.
Für meine kleinen Applikationen an Messgeräten die nichts anderes tun als Daten auszulesen und nach kleineren Verrechnungen über eien bereits vorhandene Schnittstelle in laufende DBMS einzupflegen brauche ich allerdings kein .NET, da alles inHouse läuft und keine Webunterstützung von Nöten ist.

Würdet Ihr mir nun raten mich eher mit Delphi Prism oder lieber mit C# auseinanderzusetzen? Immerhin ist C# ja eine Sprache die eigens für .NET entwickelt wurde, wenn ich das noch recht im Kopf habe.

Übrigens, vielen Dank an alle die bisher schon mitdiskutiert haben. Allmählich kommt Fahrt in die Sache und ich plane schonmal meine nächsten Fortbildungen ein.

[Robotiker]

Zitat:

Zitat von generic (Beitrag 1082700)

Parallele Entwicklung mit Delphi auch kein Problem -> OmniThread-Lib (Ich werde da demnächst einen Artikel schreiben)

Das ist sicher auch ein Kandidat für etwas, was in zukünftigen Delphis enthalten sein muss.

Intel und MS investieren im Bereich C++ sehr stark in Libraries für parallele Berechnungen. Das ist auch so ein Punkt, wo ich gespannt bin, wie Emba da mit dem neuen Compiler mithalten will ...

[Phoenix]

Zitat:

Zitat von MGC (Beitrag 1082707)

Würdet Ihr mir nun raten mich eher mit Delphi Prism oder lieber mit C# auseinanderzusetzen? Immerhin ist C# ja eine Sprache die eigens für .NET entwickelt wurde, wenn ich das noch recht im Kopf habe.

Prism ist halt Object Pascal, und zudem noch fortgeschrittener als C#.

Die wichtigsten Beispiele bisher: LINQ gab es gut ein dreiviertel Jahr bevor C# es hatte, die Parallel Extensions hatte Prism auch über 12 Monate vor C#. Beim DLR-Support waren wir zugegebenermassen nur 3 Monate voraus, haben aber auch parallel an Cooper gearbeitet ;-)

Stand heute kann Prism von Haus aus aus auch Aspektorientierte Programmierung mittels einer zusätzlichen Assembly (Cirrus), wozu man in C# noch etliche Zusatztools und vor allem Post-Build-Prozesse benötigt (die dann u.a. auch das unmittelbare Signieren von Assemblies schwer machen). Bis C# AOP kann wird noch einige Zeit vergehen.

Daneben bietet Prism mit Interface delegation dann auch noch Language-Support, die man als C#'ler sehr schnell und sehr schmerzlich vermisst.

Nichtsdestotrotz bin ich der Meinung, dass ein .NET-Entwickler C# zumindest lesen können muss. Der Einzige Vorteil den C# geniesst ist der bessere Support von Drittherstellern.

Im übrigen kann ich Stahli gar nicht nachvollziehen. Ich bin mit .NET inzwischen bei jeder Anwendung schneller fertig als mit nativem Delphi, vor allem weil die API sehr eingänglich ist, das Debuggen viel effizienter geht und das Framework in nahezu jedem Bereich von Standardanwendungen schon etwas mitbringt, dass sich mal kurz ableiten bzw. bei Interfaces implementieren lässt um damit schneller ans Ziel zu kommen.

[stahli]

Da sind sie wieder ... Begriffe und Technologien, die ich nicht verstehe. :oops:

Na ja, ich habe mir Prism schon angesehen, aber keinen wirklichen Zugang gefunden. Es ist halt alles irgendwie so komisch... :-D

Mit Delphi komme ich gut zurecht. Prism erfordert einige Umgewöhnung und erst einmal ein grundsätzliches Verständnis von .NET
Autodidaktisch ist das (für Hobbyprogrammierer mit wenig Tagesfreizeit) schon eine Herausforderung. Ich will ja auch mit meinem Projekt weiter kommen.

Wenn es Videotutorials für Prism gäbe, würde ich die gern abonnieren. Die meisten Beispiele, die man so findet sind aber natürlich für C#, eine zusätzliche "Erschwernis".

Bisher bleibe ich daher lieber bei meinem geliebten Delphi - der Weg des geringsten Widerstandes.
Und meine Nutzer sparen sich das ganze .NET-Geraffel.

Ob und wann ich das mal bereue, wird sich zeigen.

[MGC]

Nun wendet sich der Zeiger wieder eher zu .NET... :|
Ich glaube ich werde mir mal Prism im Privatbereich zulegen und das ganze mal genauer untersuchen (Lässt sich ja auch eher mal nebenher in der Prof-Version zahlen als D-W32).
Durch einige Erfahrungen im Randbereich mit Delphi für .NET 2005 (Damals war es noch nicht ganz so ausgereift wie heute) ist mir auch die Vorgehensweise nicht vollkommen unvertraut. Und ich hoffe mal das sich nichts grundlegendes an der FCL geändert hat, so dass ich auch jeder Zeit meinen Elmar Warken-Schmöker Delphi für .NET 2006 zu Rate ziehen kann.

Höchstwahrscheinlich wird es erstmal auf eine zweigleisige Delphi-Geschichte herauslaufen. Auf diese Weise bin ich dann auch in Zukunft eher gerüstet, wenn es mal eine Änderung in nur eine von beiden Richtungen gibt.

[Phoenix]

Zitat:

Zitat von stahli (Beitrag 1082747)

Prism erfordert einige Umgewöhnung und erst einmal ein grundsätzliches Verständnis von .NET
Autodidaktisch ist das (für Hobbyprogrammierer mit wenig Tagesfreizeit) schon eine Herausforderung. Ich will ja auch mit meinem Projekt weiter kommen.

Wenn es Videotutorials für Prism gäbe, würde ich die gern abonnieren. Die meisten Beispiele, die man so findet sind aber natürlich für C#, eine zusätzliche "Erschwernis".

Wie gesagt, ich bin der Meinung als .NET Entwickler sollte man auf jeden Fall C# lesen können. Und ja: Das .NET Framework ist sehr umfangreich. Das ist natürlich für den Einsteiger erstmal überwältigend, aber natürlich auch ein Riesen-Vorteil für den produktiven Einsatz.

Wobei man sich am Anfang erstmal auf ein paar Namespaces und die Sprachfeatures beschränken kann. Ohne LINQ z.B. will ich heute gar nicht mehr programmieren (das ist auch der Grund, warum ich natives Delphi inzwischen für unproduktiver halte). Es geht doch eigentlich immer darum irgendwelche Daten irgendwie durchzunudeln, und um Daten zu selektieren und ggf. in einem einzigen Schritt gleich durchzunudeln ist LINQ halt echt grandios.

[MGC]

Zitat:

Zitat von generic (Beitrag 1082700)

Ein generelles Problem im dotnet sehe ich noch, dass die Firmengeheimnisse (Programmlogik) nur schlecht versteckt sind.

Die IL kann man prima lesen. Gerade wenn es um Lizenz/Kopierschutz geht, muss man hier auf externe Tools setzen.

Hierbei fallen mir noch andere Fragen zum Thema Sicherheit ein. Die .NET-Plattform stellt zwar entsprechende Sicherheits-Assemblies zur Verfügung, aber ist es ähnlich einer DLL-Inejction auch möglich eine Art Assembly-Injection durchzuführen, bzw. Assemblies auszunutzen, um Datenbrücken zu erstellen?

Virenbefall und Code-Injection dürfte ja aufgrund des managed Code nicht funktionieren, was möglicherweise der Grund für den imensen Anstieg an Trojanern ist und kaum noch neue Viren auf die PC-Welt losgelassen werden(?).
Obwohl das auch wiederum eher an einem Interesse an Datenklau und dem gewinnen von Zombi-PCs durch Hijacker liegen könnte.

[rwachtel]

Zitat:

Zitat von MGC (Beitrag 1082749)

[...] so dass ich auch jeder Zeit meinen Elmar Warken-Schmöker Delphi für .NET 2006 zu Rate ziehen kann. [...]

Da Delphi PRISM so gar nichts mit Delphi for .NET gemein hat, solltest Du da nicht allzu viel erwarten.

[Bernhard Geyer]

Zitat:

Zitat von MGC (Beitrag 1082785)

Hierbei fallen mir noch andere Fragen zum Thema Sicherheit ein. Die .NET-Plattform stellt zwar entsprechende Sicherheits-Assemblies zur Verfügung, aber ist es ähnlich einer DLL-Inejction auch möglich eine Art Assembly-Injection durchzuführen, bzw. Assemblies auszunutzen, um Datenbrücken zu erstellen?

Virenbefall und Code-Injection dürfte ja aufgrund des managed Code nicht funktionieren, was möglicherweise der Grund für den imensen Anstieg an Trojanern ist und kaum noch neue Viren auf die PC-Welt losgelassen werden(?).

Auch managed Umgebungen sind nicht fehlerfrei implementiert. Nicht umsonst muss MS und Oracle/Sun immer wieder mal Sicherheitsupdates nachschießen. Denn auch die Basis-DLL's/Exe diese Umgebungen setzen irgendwann mal auf unmanged System-API's.
Aber solange noch IE8, Flash und Acrobat Reader noch einfacher Angriffsszenarien bieten wird man eher diese verwenden.

[Phoenix]

Zitat:

Zitat von MGC (Beitrag 1082785)

Hierbei fallen mir noch andere Fragen zum Thema Sicherheit ein. Die .NET-Plattform stellt zwar entsprechende Sicherheits-Assemblies zur Verfügung, aber ist es ähnlich einer DLL-Inejction auch möglich eine Art Assembly-Injection durchzuführen, bzw. Assemblies auszunutzen, um Datenbrücken zu erstellen?

Jain. Wenn man signierte Assemblies verwendet ist es im Prinzip technisch unmöglich einem Programm ein fremdes Assembly unterzujubeln. Ist es jedoch nicht signiert, kann man es natürlich jederzeit gegen ein beliebiges eigenes austauschen.

Das Zertifikat muss kein kostenpflichtiges Code-signing Zertifikat sein, sondern kann auch selber erstellt werden. Hauptsache, das Assembly hat eine kryptographische Signatur.

[stahli]

Zitat:

Zitat von Phoenix (Beitrag 1082774)

Ohne LINQ z.B. will ich heute gar nicht mehr programmieren (das ist auch der Grund, warum ich natives Delphi inzwischen für unproduktiver halte). Es geht doch eigentlich immer darum irgendwelche Daten irgendwie durchzunudeln, und um Daten zu selektieren und ggf. in einem einzigen Schritt gleich durchzunudeln ist LINQ halt echt grandios.

Ok, LINQ ist schon interessant (mich würde allerdings eher nur die Objekt-Variante interessieren (LINQ to Objects)).

Seinerzeit habe ich mich für Prism in Verbindung mit ECO interessiert, das ja ähnliche Möglichkeiten bieten sollte.
Leider lief das nach meinen Erfahrungen nicht stabil und ich hätte es gern in Delphi genutzt.

Mal angenommen, ein LINQ würde es auch in Delphi geben (grundsätzlich sollte das ja machbar sein), wie würdest Du dann argumentieren?
(Ich meine das nur als ganz grundsätzliche Überlegung - also den Aufwand für Emba und Schwierigkeiten der Umsetzung etc. einfach mal außen vor lassen.)

Also ein Vergleich Delphi+LINQ mit Prism, sozusagen...

[MGC]

Hallo zusammen,

vielen Dank für die rege und ernsthafte Beteiligung, die in der Tat vielschichtig das Thema .NET und insbesondere auch Delphi und .NET beleuchten un dglücklicherweise nicht in die Richtung von Delphis Ende oder dem Ende von nativer Windows-Apllikationsentwicklung gelaufen sind. :thumb:

Zitat:

Da Delphi PRISM so gar nichts mit Delphi for .NET gemein hat, solltest Du da nicht allzu viel erwarten.

Auch die FCL-Grundlagen haben sich seit Delphi Prism geändert? Uups, ich habe wirklich eine wichtige Veränderung verschlafen. :oops:

Gibt es empfehlenswetre Literatur zum Thema? Ich halte lieber ein papierenes Nachschlagewerk in der Hand als mich enzig und allein auf online-Quellen zu verlassen. Würde mich sehr gern eingehender mit dem Thema .NET und Delphi Prism beschäftigen. Ausserdem finde ich es immer besser, wenn ich mich nicht vollkommen unvorbereitet um Fortbildungen kümmere.

Zitat:

Auch managed Umgebungen sind nicht fehlerfrei implementiert. Nicht umsonst muss MS und Oracle/Sun immer wieder mal Sicherheitsupdates nachschießen. Denn auch die Basis-DLL's/Exe diese Umgebungen setzen irgendwann mal auf unmanged System-API's.
Aber solange noch IE8, Flash und Acrobat Reader noch einfacher Angriffsszenarien bieten wird man eher diese verwenden.

Ja, vollkommen fehlerfrei ist nichts und es nur eine Sache des Ansporns für Hacker, sich diesem Thema mal eingehender zu widmen. Aber zum Glück liebt der Mensch den Weg des geringsten Widerstands und der Möglichkeit so vielen Usern wie möglich in den Rechner schauen zu können.
Jeder weiss ja noch das selbst Firefox nach einem größeren Verbreitungsgrad auch mögliche Angriffsszenarien geboten hat, diese aber zu Beginn noch uninteressant waren, da die meisten wohl eher auf IE gesetzt haben.

Wenn ich es noch recht im Kopf habe, hat MS doch vor Jahren mal ein Projekt zur fehlerfreien Softwareentwicklung gestartet, an dem unter anderem auch eine deutsche Uni beteiligt war. Ich habe das Thema leider nicht weiter verfolgt. Falls jemand von Euch da mehr im Bilde ist, wäre das ggf. auch mal für einen eigenen Thread interessant. (Obwohl, um tatsächlich dafür zu sorgen das fehlerfreie Produkte auf den Markt kommen können, fehöt einfach Zeit und Geld. Ganz abgesehen von den verschiedenen Systemen auf denen ein OS und auch Software laufen muss/sollte. Das kann bei den heutigen Projekten wahrscheinlich gar nicht realistisch sein)

Zitat:

Jain. Wenn man signierte Assemblies verwendet ist es im Prinzip technisch unmöglich einem Programm ein fremdes Assembly unterzujubeln. Ist es jedoch nicht signiert, kann man es natürlich jederzeit gegen ein beliebiges eigenes austauschen.

Das klingt wiedrum mal gar nicht so schlecht. Bei größeren Projekten wird ohnehin signiert und bei inHouse-Lösungen kann ich also selbst eine "Sparsignatur" erstellen.
Klingt zumindest nach weniger Aufwand als bei W32 zu übeprüfen ob eine eigene oder eine Fremd-DLL mitläuft. Und selbst dann kann man sich nie sicher sein, ob das ganze nicht wieder ausgehebelt wird.

[Robotiker]

Aktuelle Bücher sind leider bei Delphi, ob managed oder nativ, schon seit Jahren Mangelware. Das ist aber auch bei nativem C++ unter Windows nicht so viel besser.

Dagegen gibt es für C# sehr viele Bücher:

• Die Entwicklung von C# über die Jahre ist z.B. in "C# in Depth" von John Skeet beschrieben.
• Sehr lesenswert finde ich "Effective C#" und "More Effective C#" von Bill Wagner.
• "LINQ in Action" beschreibt dieses Thema sehr ausführlich.
• "Real World Functional Programming" vergleicht C# und F# und bietet einen sehr guten Blick über den Tellerrand in das Gebiet der funktionalen Programmierung.
• Nützliche Nachschlagewerke sind die C# Codebooks von Jürgen Bayer, leider in der neuen Ausgabe geradezu unanständig teuer geworden.
• Dann gibt es natürlich viele Bücher im Bereich Web, Datenbankanbindung, WPF, usw.

[Bernhard Geyer]

Zitat:

Zitat von MGC (Beitrag 1082850)

Klingt zumindest nach weniger Aufwand als bei W32 zu übeprüfen ob eine eigene oder eine Fremd-DLL mitläuft. Und selbst dann kann man sich nie sicher sein, ob das ganze nicht wieder ausgehebelt wird.

Für die per Plugin oder über Ausgelagerte Funktionalität eingebundenen DLL's kann man das prüfen. Jedoch jeder Firenscanner, Firewall, ect. sorgt dafür das jeder Prozess zig Nicht-Windows-DLL's untergeschoben bekommt. Und diese können dann u.U. einfach Speicherauszüge des Prozesses durchsuchen nach Passwörtern, ...

[Insider2004]

Zitat:

Noch vor relativ kurzer Zeit sollte .NET die bestmögliche Umgebung der Zukunft sein, da durch den managed Code z.B. Virenangriffe eingedämmt werden sollten und angeblich auch eine JAVA-ähnliche Plattformübergreifenden Entwicklungsstandard zur Verfügung stehen sollte und nicht zu vergessen - die verbesserte Erstellung von verteilten Anwendungen insbesondere im Netzwerkbereich.

Ich sehe beim besten Willen nicht, was .net mit Viren zu tun haben sollte. .net ist genauso anfällig für Viren wie Native Code. .net hat desweiteren nichts mit Netzwerken zu tun. Das war nur ein Marketing-Gag, weil .net zur Zeit des Internetbooms eingeführt wurde.

Zitat:

Viel konnte man lesen, das selbst Spieleprogrammierer auf .NET umstellen wollten, da der Leistungsverlust durch die neuen Rechnergenerationen wieder wettgemacht werden sollten.

Es ist richtig, dass neue CPUs den Leistugsverlust wett machen. Aber diese neuen CPU steigern die Leistungsfähigkeit von Native Programmen noch viel mehr. Also ist Native wieder vorn. Der Igel läuft jetzt schneller, aber der Hase eben auch. Und noch mehr.

Zitat:

In welchen Bereichen lohnt sich der Einsatz von .NET Eurer Meinung nach tatsächlich?
(z.B.: Anwendungen für den beruflichen oder auch privaten Bereich, Netzwerkanwendungen, usw.)

Es lohnt sich eigentlich nicht, weil es eine MS-Technologie ist und nur Win läuft (vergesst Mono mit seinen Exceptions). Dann schon eher Java als .net.

[Stevie]

Zitat:

Zitat von stahli (Beitrag 1082849)

Zitat:

Zitat von Phoenix (Beitrag 1082774)

Ohne LINQ z.B. will ich heute gar nicht mehr programmieren (das ist auch der Grund, warum ich natives Delphi inzwischen für unproduktiver halte). Es geht doch eigentlich immer darum irgendwelche Daten irgendwie durchzunudeln, und um Daten zu selektieren und ggf. in einem einzigen Schritt gleich durchzunudeln ist LINQ halt echt grandios.

Ok, LINQ ist schon interessant (mich würde allerdings eher nur die Objekt-Variante interessieren (LINQ to Objects)).

Seinerzeit habe ich mich für Prism in Verbindung mit ECO interessiert, das ja ähnliche Möglichkeiten bieten sollte.
Leider lief das nach meinen Erfahrungen nicht stabil und ich hätte es gern in Delphi genutzt.

Mal angenommen, ein LINQ würde es auch in Delphi geben (grundsätzlich sollte das ja machbar sein), wie würdest Du dann argumentieren?
(Ich meine das nur als ganz grundsätzliche Überlegung - also den Aufwand für Emba und Schwierigkeiten der Umsetzung etc. einfach mal außen vor lassen.)

Also ein Vergleich Delphi+LINQ mit Prism, sozusagen...

Schau dir in dem Zusammenhang mal Collections von Alex Coibanu an. Ich bin im Moment dabei darauf aufbauend etwas wie einen LinqToSql Provider dafür zu schreiben. Wird aufgrund der nicht vorhandenen Lambdas in Delphi und der fehlenden Umwandlung dieser in Expression Trees etwas anders laufen. Aber mit den neuesten Delphi Versionen (>= 2010) geht da inzwischen schon einiges. Grundsätzlich geht aber zumindest, was Linq To Objects angeht fast alles genauso in Delphi mit dieser Library, ausser diese Linq Syntax, die ja in C# oder Prism eingebaut ist. (Mag jemand nen Precompiler für Delphi schreiben, der das in reguläre Methoden Aufrufe umbaut? :)) Trotzdem schiel ich immer neidisch richtung C#, wenns mal wieder nen internal dcc Error hagelt oder irgendwas in Delphi nicht so läuft wie das .Net Vorbild es macht.

[MGC]

Zitat:

Zitat von Insider2004 (Beitrag 1082892)

Ich sehe beim besten Willen nicht, was .net mit Viren zu tun haben sollte. .net ist genauso anfällig für Viren wie Native Code. .net hat desweiteren nichts mit Netzwerken zu tun. Das war nur ein Marketing-Gag, weil .net zur Zeit des Internetbooms eingeführt wurde.

Angeblich sollte .NET einen erhöhten Schutz vor Viren (insbesondere Code-Injection) bieten. Vor Code-Injection müsste es aufgrund des managed Code auf jeden Fall sicher sein, da im Programm-Header (soweit ich mich recht erinnere) eine Möglichkeit zur Überfprüfung des zu kompilierenden Codes hinterlegt ist.
Natürlich sollte der managed Code hauptsächlich die Option bieten, plattformunabhängig zu werden, was im Prinzip jedoch durch MS selbst absichtlich/unabsichtlich verhindert wurde(?).

In Verbindung mit ASP.NET/ASPX sollten doch mittels .NET einfacher(?) auch größere Multitier-Projekte mit z.B. Deutschlandweit verteilten Server-/Client-Systemen erstellt werden können.

Zitat:

Sicherheit
Eines der wichtigsten Konzepte ist das Sicherheitskonzept von .NET. Das Sicherheitskonzept von .NET fängt an bei Mechanismen, die die Identität des Programmherstellers gewährleisten sollen (Authentizität), geht über Mechanismen zum Schutz der Programme vor Veränderung (zum Beispiel durch Programmviren) bis hin zu Schutzmechanismen, die den Ort der Herkunft bzw. Programmausführung (zum Beispiel Internet) einbeziehen. Es gibt technisch betrachtet sowohl ein codebasiertes (Code-based Security) als auch ein nutzerbasiertes (Role-based Security) Sicherheitsmodell. Spezialisten stoßen allerdings insbesondere bei der Web- und Datenbankprogrammierung unter .NET auf bis zu einem halben Dutzend alternativer und ergänzender Sicherheitsmodelle von Betriebssystem, CLR, Datenbank und Webserver.
http://de.wikipedia.org/wiki/.NET

Zitat:

Zitat von Insider2004 (Beitrag 1082892)

Es lohnt sich eigentlich nicht, weil es eine MS-Technologie ist und nur Win läuft (vergesst Mono mit seinen Exceptions). Dann schon eher Java als .net.

Die Frage nach der richtigen Entwicklungsumgebung/Sprache ist meist eine sehr subjective udn auch projektabhängige Entscheidung. Wenn ein Softwaresystem ohnehin nur auf WIN laufen soll, wieso dann mit JAVA arbeiten, wenn über die FCL ein Framework zur Verfügung steht, welches einem den GUI-Entwurf vereinfacht? (Mal ganz abgesehen davon, dass alle .NET-Kompos auch datensensitive Eigenschaften haben).

[Insider2004]

Ich glaube es ließen sich noch zig .net-Techniken finden, warum man .net nehmen sollte.

Fakt ist, dass man ein sehr schnelles und unheimlich flexibles Programmiersystem hat (Delphi) und ein sicheres, langsameres und unflexibleres Programmiersystem (Prism, C#, Whatever).

Ich brauche ersteres für meine Kunden-Anforderungen. Es kommt einfach immer wieder vor, dass man was casten muss oder mal direkt in die CPU-Register rein muss. Und da zieht .net einfach den kürzeren.

Der Resourcenverbrauch ist im Vergleich zu Native einfach sehr viel größer. Meine Kunden haben teiweise PCs von 2002. Was soll ich da mit net ankommen? Die zeigen mir den Vogel, wenn ich sage, sie sollen das net-Framework vorher installieren.

[mkinzler]

Zitat:

Da Delphi PRISM so gar nichts mit Delphi for .NET gemein hat, solltest Du da nicht allzu viel erwarten.

Im Gegenteil. Von Prism kannst du mehr verwarten