Ist der .NET-Entwickler der neue VB6-Entwickler?

14. September 2011 07:55

Etwas mehr als 12 Stunden sind seit der BUILD vergangen… Die Konferenz die endlich Klarheit bringen sollte, die uns Entwicklern die Marschrichtung für die Zukunft aufzeigen sollte. Das Gefühl war schon irgendwie beängstigend am Vormittag, die Nervosität bei vielen Leuten spürbar. Durch die Verschwiegenheit von Microsoft im Vorfeld wurden die wildesten Gerüchte gestreut: Wird HTML5&JS die neue primäre Sprache für Windowsentwicklung? Wird es .NET weiterhin in seiner jetzigen Form geben? Haben wir viele Jahre eine Technologie gelernt, die nun veraltet ist?

Die Keynote begann, Windows 8 wurde gezeigt und dann war es raus: Es wird eine neue Laufzeitumgebung geben, genannt Windows RT, welche für die Entwicklung von Windows 8 Apps genutzt wird. Diese Runtime kann mit diversen Sprachen genutzt werden, neben HTML/JS und C++ glücklicherweise auch C#… Das HTML gesetzt war, vermuteten viele bereits, aber eine wirkliche Bekenntnis zu C# und zu .NET gab Microsoft bis dato nicht. Aber ist jetzt alles gut für das .NET Framework? Nein – ich denke nicht!

Wirklich viele Informationen über die nächste .NET Version gab es ja nicht. Bei der Sessionlist der BUILD ist mir folgende Session aufgefallen, auf die ich meine Argumentation stütze:

image

Das .NET-Framework wird also neue Erweiterungen bekommen, um Anwendungen für Windows 8 zu schreiben, bzw. die Windows RT aus .NET heraus nutzen zu können. Das man neue Erweiterungen für ein Betriebssystem bereitstellt, kennen wir bereits von Windows 7. Allerdings wurde das damals als “Windows 7 API Code Pack” bereitgestellt und nicht als Bestandteil einer neuen Version von .NET zu Verfügung gestellt.

Das Konzept von Microsoft war es (einmal!?), ein Framework für alle Windowsplattformen zur Verfügung zu stellen. Damit war sichergestellt, das Anwendungen, die auf einer Frameworkversion auf Betriebssystem X laufen, auch auf einem Betriebssystem Y läuft, vorausgesetzt es existiert eine Runtime dazu. Sollte Microsoft also wirklich die API für Windows 8 in .NET integrieren, wäre diese Plattformunabhängigkeit Geschichte. Macht man sich da das eigene Konzept kaputt?

Schaut man sich die Sessions zur BUILD an, wird eines deutlich: Der Kernpunkt dieser Konferenz ist neben Windows 8 vor allem HTML5 und JavaScript.

  • 9 Sessions zu .NET
  • 7 Sessions zu ASP.NET
  • 7 Sessions zu C#
  • 40 (!!!) Sessions zu HTML5

Merkwürdig das HTML5 als Technologie die langjährig gefeierte Technologie .NET mit einer gigantischen Entwicklergemeinde zu überholen scheint. Schaut man sich die Sessions im Bereich .NET, ASP.NET und C# an, mangelt es an wirklichen Innovationen und es erweckt den Eindruck, das diese Frameworkversion einzig und allein für die Kompatibilität mit Windows 8 entwickelt wurde und um die Brücke für ASP.NET Entwickler hin zu HTML5 Metro UI zu schlagen.

Wir sind bald im zehnten Jahr des .NET-Zeitalters angekommen. In dieser Zeit hat sich viel Verändert, das Framework wurde massiv erweitert und um coole und innovative Features ergänzt, wie z.B. LINQ. Wir haben mit WPF eine UI-Technologie die in der Lage ist, hardwarebeschleunigte Oberflächen zu entwickeln die schick und modern aussehen. Nun hat Microsoft mit Windows 8 ihr Flaggschiff zurück auf 0 gestellt (mehr oder weniger), und so viele Bereiche neu entwickelt wie bei keinem Betriebssystem vorher. Aber womit wurden die Oberfläche von Windows entwickelt? Mit HTML5 und JavaScript! Wurde das Betriebssystem auf Basis von managed Code geschrieben? Nein, aber warum? Das Forschungsbetriebssytem Singularity von Microsoft Research hat doch gezeigt, das ein performantes managed OS möglich ist und zahlreiche Vorteile hat. Welche großen Microsoftprodukte gibt es den, die mit .NET umgesetzt wurden, wenn wir Sharepoint einmal außen vor lassen? Keins!

Diese Tatsache zeigt mir, das Microsoft selbst nicht mehr an eine Zukunft von .NET glaubt und diese Version 4.5 des Frameworks untermauert das Ganze noch einmal. Egal mit wem man im Vorfeld gesprochen hat und über ein mögliches AUS von .NET diskutierte, jeder entgegnete mit der selben Antwort “Microsoft wird doch keine Technologie sterben lassen, in die sie so viele Jahre so viel Geld investiert haben”. Aber haben die VB6 Entwickler das nicht früher vielleicht auch behauptet bevor .NET veröffentlicht wurde? Ich befürchte die .NET Entwickler werden die neuen VB6 Entwickler…

Kommentare (38) -

Robert Seso
Robert Seso Deutschland
14.09.2011 11:18:33 #

Also .NET wird es nach wie vor geben, aber eben auf dem Server und in der Azure Welt, also als Backbone für den "neuen" WinRT Klienten. Klientseitig wird es auf kurz oder lang in der jetzigen Ausprägung zusammen mit den klassischen Desktop sicherlich sterben oder zumindest schrittweise reduziert.

Wegen der Frage welche Produkte neben SharePoint Microsoft mit .NET entwickelt hat -- ganz viele -- Dynamics CRM, BizTalk, der gesamte Azure Stack, große Teile von Visual Studio, Teile von Exchange, SQL Server, Office, TFS, IIS usw.

Antwort

Tim
Tim Deutschland
14.09.2011 11:43:56 #

Irgendwie bekomme ich Angst bei der Vorstellung, dass .NET ausstirbt.
Zum Artikel: sehr gut geschrieben und (leider) auch gut begründet. Die Ängste scheinen berechtigt.

Antwort

David
David Deutschland
14.09.2011 11:58:25 #

@Robert: Natürlich könnte es im Backend bleiben, aber wer sagt denn, das Microsoft nicht bald eine MS-Variante von Node.js veröffentlicht mit der dann wieder alles auf 0 gestellt wird? Was deine Produktaufzählung angeht, magst du zum Teil recht haben, aber für viele der Produkte (Dynamics) gab es auch keine wirklich ernsthaften Alternativen im MS Portfolio. Du musst bei meinen Überlegungen mal von jemandem ausgehen, der sich auf Silverlight, WPF, WinForms etc. spezialisiert hat.

Antwort

Robert Seso
Robert Seso Deutschland
14.09.2011 14:37:38 #

Silverlight, WPF und WinForms sind lediglich UI Technologien die auf dem .NET Framework basieren, und da gebe ich dir natürlich Recht, diese sind austauschbar und werden mittelfristig langsam durch Konzepte wie Metro UI ersetzt -- wahrscheinlich jedoch erst mit der Nachfolgeversion, Windows 8 wird nur den Anfang machen. So gesehen bleiben deine Skills sicherlich noch eine Zeit lang relevant, aber wenn dein Fokus auf dem UI liegt, dann ist jetzt der Zeitpunkt mit was neuem anzufangen.

Dass MS auch serverseitig den gesamten .NET Stack ersetzten wird, glaube ich nicht, zumindest nicht so schnell. Dafür ist .NET viel zu tief in den Serverprodukten und Azure verankert und das sind die Bereiche wo viel Geld verdient wird und man sich keine Experimente leisten darf.

Antwort

David
David
14.09.2011 14:49:33 #

Und womit sollte man als UI-Scopler jetzt anfangen? XAML? JavaScript? HTML 5? QBasic?

Antwort

Robert Seso
Robert Seso Deutschland
14.09.2011 20:43:50 #

So wie es aussieht ist HTML5 + JS zur Zeit die sicherste Option. XAML? Keine Ahnung, vermutlich auch Ok wenn man Windows-only Metro-only Anwendungen entwickeln will oder muss. Für diese drei wird es zumindest Mirgationspfade geben, sollten sie selbst in Zukunft gegen was anderes ausgetauscht werden. Und das ist das wichtigste, die UI Konzepte ändern sich immer wieder mal und eine 100% sichere Option wird es in dem Bereich wohl nie geben...

Antwort

Codeknecht
Codeknecht Deutschland
18.09.2011 00:38:25 #

Windows-Anwendungen mit HTML5 und JS ???
Kleine Apps, ok -  aber ich frage mich, wie das gehen soll, wenn z.B. Zugriffe auf das lokale Dateisystem und Kommunikationen mit dem Betriebssystem nötig sind.
Wie stelt sich Microsoft vor, das mit JS lösen zu können. Verstehe ich nicht....



Antwort

Robert Seso
Robert Seso Deutschland
19.09.2011 13:47:56 #

Also hier muss man zwischen den "klassischen" Windows Anwendungen und den Metro Windows Anwendungen unterscheiden. Die ersten basieren nach wie vor auf .NET oder Win32 API, und für Metro gibt es eine neue Laufzeitumgebung/Entwicklerframework (WinRT) mit entsprechenden Hooks zu allen OS-nähen Services die auch aus JS angesprochen werden können. Jedenfalls besteht Windows 8 eigentlich aus zwei (fast) getrennten OS-en, die nur noch einen gemeinsamen Kernel haben, alles andere ist getrennt. So ist zumindest mein Verständnis nach der Build Konferenz.

Antwort

Codeknecht
Codeknecht Deutschland
19.09.2011 13:56:54 #

@Robert: Danke für die Info!! Wenn JS mit diesen Hooks aufgebohrt wird, so dass man auch an OS-Servises rankommt, dann verstehe ich es.
Dass das so geplant ist, war mir komplett neu.

Bleibt aber zu befürchten, dass dieses JS dann eine spezielle Microsoft-Varinte ist, die mit reinem JS in weiten Teilen nichts mehr zu tun hat.

Wir werden sehen !

Antwort

Johannes
Johannes Deutschland
14.09.2011 13:22:37 #

Amen!
Zum Glück mache ich nur Web - da bleibt mir mein .NET hoffentlich noch eine Weile erhalten.

Die Message von MSFT ist aber eindeutig: HTML5 + JS

Man bedenke: JavaScript im Browser ist an sich auch die Hölle. Mit einer Abstraktionsschicht dazwischen (jQuery & Co.) wird es aber erträglich. Bestimmt wird ein Framework kommen und die WinRT-Entwicklung abstrahieren. Das geht immerhin in die Richtung von Cross-Platform.

Uuuunnd wem die compilation symbols in der Demo aufgefallen sind, der wird freiwillig Silverlight Abstand nehmen. Das war ja wiederlich!


Antwort

David
David Deutschland
14.09.2011 13:26:08 #

Ja Johannes, #ifdef lässt grüßen. Ich freue mich ja, das es für euch Webentwickler kaum veränderungen gibt, aber was bitte hat Microsoft das jetzt gebracht? Mit Plattformunabhängigkeit kann das bei dem Ganzen properitären Code nichts zu tun haben, also hätte man auch auf HTML5 und JScript auf dem Desktop verziichten können und das alles mit XAML durchziehen... Aber nein HTML5 muss ja auf den Desktop kommen, glückwunsch!

Antwort

Christopher Schleiden
Christopher Schleiden Deutschland
14.09.2011 13:34:51 #

Freut auch mal lieber, dass wir armen nativen Entwickler seit Ewigkeiten mal wieder etwas Liebe von der Corp bekommen. Bin wirklich mal auf die C++ WinRT Bindings gespannt und erstaunt vor allem, dass es die ueberhaupt gibt. Smile


Im allgemeinen denke ich aber nicht, dass .NET ausstirbt, bloss das es nicht die eierlegende Wollmilchsau bleibt(/wird) sondern wir wieder verschiedene Technologien fuer verschiedene Zwecke einsetzen werden. Herb Sutter sagte z.B. vor kurzem in seiner Keynote zum Thema Warum heute noch C++? in etwa folgendes:

“Was .NET All a Mistake?” Of course it wasn’t, Mr. Sutter states. “But it can’t do everything C++ can, just like C++ can’t do all .NET can”. Managed languages were the hammer that made everything look like a nail during the last decade. Today, the focus is on high demanding applications that need performance. The “king” is Performance per Watt, per Cycle, per Transistor: Performance per Dollar.

Aehnlich sehe ich das mit .NET. Sorry, ich sehe mich einfach nicht komplexe Applikationen mit Javascript entwickeln, zumindest nicht mit dem jetzigen Stand der Sprache.

Antwort

David
David Deutschland
14.09.2011 13:39:04 #

@Chris: Ja, ich sehe das ähnlich. Man hat gemerkt das man .NET falsch platziert hat. Für ordentliche Geschwindigkeit hat es nicht gereicht und mit WPF hat man halt nicht auf HTML5 sondern auf XAML gesetzt. Damit hat man alles ins Abseits befördert...
Aber ich freue mich für euch nativen Leute Smile

Antwort

Christopher
Christopher Vereinigte Staaten von Amerika
14.09.2011 14:03:56 #

Na, ich denke nicht dass es Weg fällt sondern nicht mehr für _alles_ verwendet wird. Enterprise App XY mit Db Anbindung, Myriaden von Grids etc. will ich weder in C++ noch JS schreiben, da ist Productivity dann wieder King..

PS: Dein yblog Layout ist nicht Handy tauglich ;) /wp7

Antwort

David
David Deutschland
14.09.2011 14:48:17 #

Ja das stimmt, mir geht es auch weniger darum das .NET langsam auf eine geunde größe schrumpft, sondern darum wie Microsoft mit den Informationen umgeht. Es wird eine Entwicklerkonferenz abgehalten, aber es wird keine Roadmap für die nächsten Jahre angegeben! Ich will endlich wissen wo es hingeht! Was ist die Servertechnologie in 2 Jahren? Was ist die UI Technologie in 2 Jahren? Und genau das meine ich in diesem Beitrag, Bei VB6 wurde mit COM und Interop auch das Blaue vom Himmer erzählt aber was daraus geworden ist, sieht heute ja jeder!

Antwort

Johannes
Johannes Deutschland
14.09.2011 15:54:48 #

Ich vermute, es gibt keine Roadmap weil die es selbst auch nicht wissen.

Wie weit sind die Windows8-Entwickler? Wann wird das JavaScript-Stack-Team fertig? Wann das Silverlight-Team. Das Blend5-Team. Das Visual Studio 2011 Team. Und hoffentlich hat das Store-Team endlich mal Resourcen. (siehe Zune und WP7-App Zertifizierungsprozess)...

Antwort

Niels
Niels Deutschland
15.09.2011 08:20:52 #

OMG, Microsoft was hast du getan??

Entwickler die keine halbwegs stabile .NET App hinbekommen haben nun Javascript an die Hand zu geben...
(UI)-Entwicklern deren UI wir bis heute nicht verstanden haben nun den MetroStyle gegeben...
wo soll das nur hinführen? Wieviel häufiger rauchen die Apps nun noch ab und gehen wir wieder einen Schritt richtung Office 2003, bei dem sich etliche Funktionen in den Tiefen von Kontextmenüs verstecken?

Eine Sprache wie C# ist sexy, weil built-in schon viele Features abgedeckt werden. "Wenns nicht baut, bauts nicht - dann ist wohl was fehlerhaft" Ja bei JS...wenns nicht tut, rauchts halt zur Laufzeit ab...halb so wild.

Wenn die Performance nicht stimmt, hab ich wohl in meiner Architektur einen Fehler oder die Möglichkeiten der Sprache nicht ausgenutzt (muss ich halt noch was lernen, nacharbeiten). Ja bei JS....lass ich halt nen Minifier und nen Merger drüberlaufen....besser wird das Coding aber dadurch immer noch nicht.

Für diese kleinen Apps wie gezeigt wurde, Bildchen anzeigen, Feeds listen, Facebook Status einsehen...kann ich mit JS + Metro UI auf dem Desktop noch leben, aber sobald ich eine "richtige" Anwendung code, werde ich einen Teufel tun und JS + Metro UI dafür einsetzen.

@Johannes: Sieh das mit den Compilation Symbols mal so, er zeigte, dass die für SL gedachte App funktioniert-wie-gedownloaded. Mit minimalen Änderungen auch Touch+Metro-enabled und dann auch noch fürs Phone funktioniert. Wers im realen Leben dann noch so macht ist selbst dran schuld.

Alles in allem, ist meiner Meinung HTML 5 für Windows 8 nun ein Hype um die Non-MS-Devs für sich zu gewinnen und ich weiss nicht ob "just another .NET/MS conference" so gut angekommen wäre - aus meiner Sicht ist da sehr viel Marketing mit im Spiel.

Bis dahin, wir werden sehen

Antwort

Sebastian
Sebastian Deutschland
15.09.2011 10:15:15 #

Moin,
also das ist dochmal Panikmache vom feinsten ;)
Warum es wenig Sessions zu .NET gab wirde in der Rede erwähnt, es ist der selbe Grund warum es auch keine oder kaum Sessions zu SilverLight gab, nicht weil diese Technologien aussterben, nein weil es etwas ist was wir alle schon kennen, wir kennen C# und wir wissen wie es funktioniert, warum sollte man nun also 100 Sessions dafür planen?
Es reicht doch wenn man 10 Sessions zu den neuerungen gibt zu den neuerungen und dann ist die Sache gegessen.
JavaScript dagegen ist neu auf der Windows Plattform, neu und unbekannt, deswegen MUSSTE es dafür auch mehr Sessions geben, denn hier sind alle neu und müssen sich einlesen und eingewöhnen - demnach macht es absolut sinn, hier mehr Sessions durchzuführen. (Und genauso wurde es auch begründet)
Gruß, Sebastian
PS: Schön cool bleiben ;)

Antwort

Boas Enkler
Boas Enkler Deutschland
15.09.2011 10:58:31 #

So wie ich es sehe läuft es doch auf folgendes:

eigene UI Sprache (HTML5 + JS , XAML ?) und business componentens wie gewohnt in der CLR.

Bisher gabs nirgends irgendetwas gegenteiliges zu hören und generell würde diese Trennung doch auch sinn machen...

Antwort

David
David
15.09.2011 11:01:42 #

Ja Boas, das würde Sinn machen wenn die HTML Oberflächen Plattformunabhängig wären. Warum hat man HTML5 + WIndows RT genommen und nicht XXAML + .NET? Sehe da keinen Sinn drin.

Antwort

Robert Seso
Robert Seso Deutschland
15.09.2011 21:13:14 #

Ganz einfach - WinRT und Metro UI werden auch auf den Tablets die mit ARM Prozesorren ausgestattet sind laufen, der klassische Desktop und alles was dazu gehört inkl. .NET nicht, das wird nur auf der x86 Architektur laufen. MS hat ausdrücklich keine Pläne .NET und die legacy Anwendungen auf ARM zu migrieren, da wird es eben nur die neuen Metro-Style Anwendungen geben. Darum kein .NET für Metro, vermute ich zumindest. Siehe auch den Artikel unter http://daringfireball.net/2011/09/metro - fand ich sehr interessant.

Antwort

Boas Enkler
Boas Enkler Deutschland
15.09.2011 11:16:45 #

Da hast du recht David. Allerdings hat das in meinen Augen weniger mit der Zukunft von .NET als viel mehr Marketing zu tun.

Wie gesagt ich denke es läuft darauf hinaus dass man mit HTML / XAML oder einem merge daraus langfristig UI schreibt.

Dafür war imo plain C# / .NET code eh nie geeignet.

aber was die Domaine Logik angeht da denke ich wird die CLR bleiben und sich weiter spezialisieren.

Antwort

hannes!
hannes! Deutschland
15.09.2011 12:40:25 #

Was ist an VB eigentlich so schlimm? Immerhin kenne ich Leute, die das noch heute einsetzen.

Ich habe VB nie wirklich programmiert, aber was natürlich als Erstes ins Auge sticht, ist die Syntax. Das ist vielleicht Geschmackssache, aber ich habe das Gefühl, dass man Vieles mit C# einfach eleganter erledigen kann.

Aber ansonsten? Jedem Problem sein Werkzeug. Und WCF, Entity Framework, LINQ  und sowieso .NET mit Visual Studio als IDE sind schon sehr mächtige Werkzeuge. Solange ich davon ausgehen kann, dass die mir noch in Zukunft zur Seite stehen, ist doch alles gut. Wenn MS in der Darstellungswelt gerade in unbekannte Gewässer vorstößt lehn ich mich doch lieber zurück bis ich erkenne, welches das Pferd ist, auf das man dauerhaft setzen sollte. Bis dahin tuts dann auch noch WPF Smile

Antwort

David
David
15.09.2011 12:52:18 #

@Sebastian: Bisher gab es auf jeder PDC irgendwas neue zu .NET oder C#, was ist es dieses Mal? Neue Sprache mit JScript hin oder her, es wurde keine wirkliche Neuerung in .NEt gezeigt und die Tatsache, dass MS nun in .NET 3.5 anfängt plattformspezifische Teile zu implementieren ist also auch nicht beunruhigend?
@Hannes: Es hat doch auch keiner gegen VB gemeckert, das Thema ist schon alngge durch... ;) Klar ist es eine Sprache wie jede andere auch, aber vom reinen Gefühl her finde ich sie nicht so strukturiert wie C#. Ja schon, aber aus welcher Entscheidungsgrundlage heraus willst du im Moment die UI-Technologie für ein langlaufendes projekt bestimmen?  Wenn ich ein Projekt anfange was in 1 1/2 Jahren fertig wird, kann ich derzeit nicht ruhigen Gewissens sagen das ich auf Technologie XYZ setzen könnte.

Antwort

Marcel
Marcel Deutschland
15.09.2011 13:29:53 #

Wieso kann man nur glauben dass Javascript in irgend einer weise C# den Rang abläuft?

Ich meine, dass man mit HTML + Javascript einfache kleinere Apps entwickeln kann, die dann auf Tablet oder Windows Phone laufen ist doch eine tolle Sache. Damit will Microsoft doch nur die App Entwicklung für Windows 8 und Windows Phone 7 vorantreiben.

So wie Windows 8 zur Zeit aussieht ist Windows 8 nichts anderes als ein Betriebssystem für ein Tablet PC. Und die hunderte von Millionen normalen PCs mit Maus und Tastatur haben ein geupdatetes Windows 7 mit "normaler Oberfläche". Und genau das ist der Grund wieso C# wohl kaum ein Auslaufmodell ist. Ein normaler PC User wird Windows 8 wohl kaum im Metro Style verwenden, sondern wird weiterhin "normale" Anwendungen benutzen. Diese Anwendungen werden wohl kaum mit HTML + Javascript geschrieben werden. Werden normale Fenster Anwendungen überhaupt so machbar sein? Ich meine wer kann sich schon vorstellen mit Javascript ein komplexes Programm zu schreiben. Da fehlt es der >Skriptsprache< doch auch einfach an Komplexität, da sie für kleinere Anwendungen im Browser Entwickelt wurde.

Also im Endeffekt ist HTML + Javascript nichts anderes als eine nette Sache um einfache kleinere Apps zu entwickeln aber für mehr wohl kaum.

Antwort

David
David
15.09.2011 13:34:06 #

Das sehe ich nicht so, JQuery hat gezeigt wie stark man JavaScript mit einer Abstraktionsschicht machen kann und wenn MIcrosoft das in die Hand nehmen würde, könnte man ähnliches erreichen. Wenn .NET die Kerntechnologie war, warum hat man dann die Windows RT nicht in .NET integriert?

Antwort

Florian
Florian Deutschland
16.09.2011 13:10:02 #

Ich denke mal aus Performance-Gründen. Und weil es keinen JIT-Compiler für ARM gibt. Letztendlich ist es ja auch egal, ob das "Backend" nun verwalteter oder nativer Code ist: Das "Frontend", die Metadaten, sehen von C# aus wie gewöhnliche .NET-Assemblies, ohne den ganzen P/Invoke-Kram, den man normal für die Verwendung von COM oder native Code braucht.

Antwort

Markus
Markus Österreich
15.09.2011 14:18:57 #

Die Frage die sich mir nun stellt;
Zahlt es sich überhaupt noch aus C# zu lernen? Ich bin eigentlich gerade am Anfang. Also Datentypen, Schleifen etc.
Nur will ich da nun nicht unbedingt meine ganze Energie investieren, wenn sich Microsoft letztendlich dazu entschließt, .NET und C# nach hinten zu stellen, bzw. es ganz aufgibt.

Antwort

David
David
15.09.2011 14:25:15 #

Also die Sprache C# an sich ist gefestigt, ich denke das sich das lernen auf jeden Fall lohnt. In meinen Augen scheint Microsoft aber die Richtung von .NET umlenken zu wollen bzw die Strategie gewchselt zu haben. Im Backend wirst du noch auf Jahre hin mit C# programmieren können und für das Frontend auch (noch)  in Verbindung mit XAML. Wenn du grad erst bei Themen wie Schleife und Datentypen bist: Auf jeden Fall. Solche Konstrukte hast du bei fast jeder Sprache und für sowas gilt: Kennst du eine, kennst du alle Smile

Antwort

Carsten
Carsten Deutschland
15.09.2011 16:30:16 #

Also ich arbeite mit Dynamics NAV, was nach vielen Releases endlich auf dem .NET-Framework läuft und es stehen bereits schon einige Releases auf der Roadmap.

Hinzu kommt, dass Microsoft jetzt kürzlich erst den Support für die neuen Releases auf 10 Jahre erhöht, was Planungssicherheit für Unternehmen bedeutet und einen Schlusstrich unter .NET eigentlich unmöglich macht, zumindest in den nächsten 10 bis 15 Jahren.

Und wenn in der heutigen Zeit für Microsoft etwas wirtschaftlich ist, dann ist es der B2B-Bereich. Also C# und .NET-Framework wird nicht so schnell aussterben.

Antwort

David
David
15.09.2011 16:32:38 #

Hallo Carsten,
das wusste ich noch nicht, danke für die Info. Hat Microsoft denn den Support an dem produkt festgemacht oder an der Entwicklungsplattform?

Antwort

Carsten
Carsten Deutschland
15.09.2011 21:20:02 #

Am Produkt. Aber bei Dynamics NAV ist die Entwicklungsplattform ein Teil des Produktes.

Antwort

Florian
Florian
16.09.2011 13:46:48 #

Ich finde, Microsoft hat bei .NET den Fehler begangen, das Framework zu sehr mit plattformspezifischen Teilen aufzublähen. Was ich mir gewünscht hätte wäre ein .NET Framework, das nur aus einer kompakten, portablen CLR und den von der ECMA standardisierten BCL-Klassen, inkl. Reflection und XML, besteht. Nicht mehr und nicht weniger. Einfach und überschaubar. WinForms, WPF, WCF etc. und vor allem die nicht von der ECMA standardisierten Klassen in mscorlib.dll hätten dann als darauf aufbauende, vom .NET Framework entkoppelte Technologien zur Verfügung gestellt werden sollen und nicht als integraler Bestandteil. Das Framework wäre insgesamt gesehen modularer und nicht so monolithisch, nicht benötigte Komponenten, wie beispielsweise das anspruchsvolle WPF auf ARM-Rechnern, könnten so einfach weggelassen werden, ohne das Framework selbst dabei neu erfinden zu müssen.

Antwort

hannes!
hannes! Deutschland
16.09.2011 14:26:29 #

@Florian:

Die von dir angesprochenen Technologien befinden sich allesamt in eigenen DLLs, die du auch einfach NICHT referenzieren kannst. Sonst könntest du ja z.B. kein WPF-Projekt ohne WinForms umsetzen. Kann man aber. Und es GIBT .NET auf Microcontrollern. Wie du richtig erkannt hast, bekommt man WPF dort aber nicht zum laufen.

Klar sind einige Teile plattformspezifisch (bei Weitem nicht alle!). Aber dich zwingt niemand, diese zu benutzen.

www.adafruit.com/.../

Antwort

David
David
16.09.2011 15:29:25 #

Die Programmierschnitstelle ist zum Teil gleich beim Micro Framework, aber die implementierung hat imho nichts mit dem Desktop-.NET zu tun, ähnlich Silverlight.

Antwort

Florian
Florian
16.09.2011 23:26:43 #

Ich glaube, ich habe meinen Punkt nicht ganz deutlich gemacht... Smile

Klar kann ich mit dem .NET Framework auch durchaus simple Anwendungen entwickeln, die lediglich die Standardbibliothek (mscorlib) referenzieren - darum ging es mir aber nicht, sondern eher um die Tatsache, dass so viel Komponenten in .NET "fest verbaut" sind, die ich lieber als separates Paket sehen würde.

Ein Problem für mich ist: Will ich eine Anwendung wirklich portabel machen, darf ich mich im Grunde nur darauf verlassen, das - egal auf welcher Plattform ich mich befinde - lediglich der Satz an von der ECMA standardisierten Klassen zur Verfügung steht. Soweit, so gut - aber: sieht man sich allein die zur Verfügung stehenden Klassen in Microsoft's "mscorlib" an und vergleicht diesen Satz mit der ECMA-TR ist da schon sehr viel plattformspezifischer Kram mit drin. Und ohne die ECMA-TR ständig bei der Hand zu haben ist es oft nicht einfach zu sagen, was jetzt ECMA-konform ist und was nicht...

Projekte wie Mono haben hier auch den Fehler gemacht, einfach das .NET Framework "as is" zu adaptieren. Damit bleibt man zwar weitestgehend kompatibel zu Microsoft - parallel dazu wäre es aber schön wenigstens eine Implementierung der CLI zu sehen, die nur das was im Standard steht umsetzt. Ich muss dazu wirklich mal recherchieren ob's da nicht in Mono eine Möglichkeit gibt, alles, was non-ECMA ist, bei der Kompilierung wegzulassen.

Naja, für die meisten, die sowieso nur das .NET Framework als Zielplattform sehen, ist alles oben genannte wahrscheinlich vernachlässigbar. Für ein Projekt von mir wäre es jedoch durchaus reizvoll, ein pures "bare-bones", ECMA-konformes Framework an der Hand zu haben.

Antwort

markus
markus Deutschland
20.09.2011 00:34:32 #

Wäre dies nicht interessant zu versuchen? developers.de/.../...oft-here-is-what-we-need.aspx

Antwort

peter neubert
peter neubert Deutschland
30.09.2011 20:18:03 #

Das ist nichts Neues bei Microsoft. Seit Windows 3.1 existieren immer wieder neue API's, Schnittstellen a la DDE/OLE/COM/DCOM/COM+/ActiveX/.NET/MFC/WFC und so weiter und so weiter. Seit ca. 20 Jahren renne ich als Entwickler den Dingen hinterher, bin aber bei der Programmiersprache immer bei C++ geblieben.

Antwort

Pingbacks and trackbacks (1)+

Kommentar schreiben




  Country flag
biuquote
  • Kommentar
  • Live Vorschau
Loading


© Copyright 2011 by David Tielke - Impressum