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

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