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

[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