Was hat's uns gebracht?

[Sebastian Köhler]

Hallo,<br>
ich hab mich ja nun schon einige Zeit in .NET umgeschaut, vorwiegend im Bereich CompactFramework, und da kommt mir eine Frage wieder und wieder in den Kopf!<br>Was hat uns .NET gebracht?<br>Ich will nicht meckern oder klagen, doch meiner Meinung nach ist das alles ein "NEUES ALTES"!<br>Ich dachte eigentlich das .NET eine neue Errungenschaft ist um es den Programmieren einfach zu machen ihre Arbeit zu verrichten!<br>
Doch was ich überall zu sehen bekomme... simple Funktionen und Eigenschaften sind nur über aufwendige Wege zu erreichen!<br>
Viele, oft genutzte Sachen sind nur über Unsafe Code oder Invokes zu erreichen!<br>
Verstehe ich bei dem Thema .NET was falsch? Wenn ja dann bitte ich um Feedback damit mir das klar wird!

mfg SebK

[U.Richter]

Hallo,

ich beginne mich in C# einzuarbeiten und bin auch etwas ernüchtert von der<br>
ganzen NET- Geschichte. Ich habe zum Beispiel einen vollwertigen Ersatz für <br>
die Funktion BITBLT aus dem GDI im GDI+ gesucht. Es gibt dort keine, also den<br>
Umweg über Invoke mit den bekannten Nachteilen wählen. Das nächste Manko sind die<br>
fehlenden Drive -u. Filelistboxen, wie man sie vo VB kennt. Es gibt zwar <br>
Kompatibilitätskomponenten aus VB6, aber von deren Verwendung wird abgeraten.<br>
Also bevor man mit der richtigen Programmiererei anfängt, die Dinger selber <br>
entwickeln. Es gibt von Microsoft für VB.Net 101 Beispielprogramme zu verschiedenen <br>
Anwendungsfällen. Arbeitet man die Programme durch, wird man Code finden, der<br>
mit der Hilfe, weder in VB.NET noch im SDK erklärbar ist, die Transparenz des Codes<br>
geht dabei stellenweise verloren. Mit den Klassen im NetFramework will man<br>
dem Chaos der Windows-API Funktionen zu Leibe rücken,<br>
in dem man sie objektorientiert kapselt und sie leichter verwendbar macht.<br>
Das ist aber nur zum Teil gelungen, weil man nicht alle Funktionen aus dem API<br>
im NET-Framework findet.<br>
Ich bin der Meinung, daß solche Entwicklerprodukte,<br>
wie Delphi, der Centura Team Developer<br>
oder der Powerbuilder neben den Net-Sprachen durchaus ihre Daseins-Berechtigung haben.<br>
<br>
MfG<br>
Ulli Richter<br>
Wirtschaftsinformatiker<br&gt

[Roger Ramuz]

Ich muss Euch beiden recht geben. ".NET" ist vorwiegend für "Internetler" beziehungsweise "Datenbänkler" konzipiert worden. Weiter verfolgt Microsoft mit diesem Wurf eine stärkere Anbindung an sich selbst.<BR><BR>
Ich bin mich ebenfalls am einarbeiten auf der C#-Schiene. Nach zirka 2 Monaten intensivem Studium und erstellen von Versuchsapplikationen, würde ich mir bis jetzt noch nicht anmassen, mich an ein bezahltes Projekt zu wagen.<BR><BR>
Dazu möchte ich erwähnen, dass meine Versuche sehr hardwarenah angesiedelt sind, weil ich vorwiegend technische Software im Aerospacebereich entwickle. Dabei sind vorwiegen HW-Schnittstellen für schnelle Proofings gefragt.<BR><BR>
Hier liegt das Hauptproblem, wie immer wird dieser Bereich von Microsoft sehr stiefmütterlich behandelt. Bis jetzt fand ich heraus, dass man nach wie vor auf API zurückgreifen muss (siehe mein mein Thema, C#: Das leidige Problem mit den HW-Schnittstellen...). Vielleicht gibt es einen anderen Weg, diesen habe ich leider bis anhin noch nicht gefunden. National Instruments bietet eigene Tools für Framework aber nur für ihre Produkte, welche auch bei uns zum Einsatz kommen. Aber ich möchte auch RS232-, USB-und andere genormte Schnittstellen bedienen können. Eine Eigenentwicklung liegt bei diesen Sachen nicht drinnen, weil kein möglicher Kunde für diese Zusatzkosten aufkommen würde.<BR><BR>
Ich setze meine Hoffnung in Borland, welche diese Lücke vielleicht erkannt hat und vielleicht demnächst etwas in dieser Richtung auf den Markt bringen wird. Ich warte ab und setzte vorläufig meine alten Entwicklungsumgebungen ein, bis ich definitiv zu .NET wechseln werde.<BR><BR>

Mit freundlichen Grüssen<BR>
Roger Ramu

[Bernhard Geyer]

Hallo Roger,

ich denke Hardwarenahe Programmierung ist nicht das Ziel von .NET. Also wurde das für die erste(n) Versionen nichts gemacht. Evtl. gibt es ja schon Komponentenhersteller dafür.

Ob Borland diese Lücke schließen wird ist sehr fraglich. Ein Hoffnungsschimmer den ich für die serielle Schnittstelle sehen würde, wäre wenn Delphi.NET heraus ist, das die sehr gute AsyncPro-Komponenten (http://sourceforge.net/projects/tpapro) auf Delphi.NET portiert werden.

Selbst habe wir als Delphi-Entwickler in unseren Umfeld (Installationsfreie Verteilung der Anwendung, Unicode unter 9x/ME) eher mehr Nachteile mit .NET als Vorteile (XCopy-Verteilung ist ja für Delphi-Entwickler ein alter Hut).<br>
Aber für die bisher mit MFC gepeinigten SW-Entwickler ist C#/.NET ein gewaltiger Schritt in Bezug auf Entwicklungsproduktivität und SW-Qualität.<br&gt

[Roger Ramuz]

Hallo Bernhard,<BR><BR>
Leider kann ich Deinen Ausführungen vollumfänglich zustimmen. Hardwarenahe Applikationen sind meistens keine Massenprodukte, wie sich dies MS eben wünschen würde. Unsere Kunden sind vorwiegend solche, welche spezielle Applikationen von uns entwickeln lassen und denen sitzt das Geld eben auch nicht mehr so locker in der Tasche. Also können wir nur hoffen und weiterhin PC-Hardwareschnittstellen vergewaltigen, bis sich vielleicht ein Hoffnungsschimmer in naher Zukunft auftut.<BR><BR>
Trotz allem besten Dank für Deinen Eintrag zu diesem Thema.<BR><BR>
MfG Roger Ramu