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

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

[MGC]

Zitat von stahli:

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

[Robotiker]

Zitat von generic:

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

[MGC]

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

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.

[Bernhard Geyer]

Zitat von MGC:

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.

[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

[Phoenix]

Zitat von MGC:

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.