Diskussion:Dot Net

aus Wikipedia, der freien Enzyklopädie

Du hast neue Nachrichten auf deiner Diskussionsseite.

[Bearbeiten] Verteilte Programmierung

Die verschiedenen Strukturen innerhalb .NET (Substrukturen wie MS Queuing Services gar nicht alle unterschieden) sind sicherlich, trotz breiter Auswahl und technisch teilweise guter Ansätze, noch nicht der Weisheit letzter Schluss, hier hat auch schon der Microsoft-Chef (Bill Gates) Nachbesserung gefordert. Insbesondere die .NET Remoting Services sollten nur dann eingesetzt werden, wenn man über ihre Schwächen und Limitierungen genau Bescheid weiß. In Bezug auf Web Services bietet .NET jedoch eine der technisch führenden Implementierungen an.

Wo sind die Belege dafür, d.h. wann und wo hat Gates Verbesserung gefordert, und was sind die erwähnten "Schwächen und Limitierungen"? -- Andreas Tanner 14:39, 26. Feb. 2007 (CET)

[Bearbeiten] Abhängigkeiten?

Mir fehlt ein Hinweis darauf, inwieweit .Net für den Nutzer proprietäre Abhängigkeiten schafft oder tatsächlich relativ offen ist wie Java. --Bertram 14:06, 10. Nov 2004 (CET)

De fakto ist Java nicht offen. Einer der Eigenschaften von Java ist aber das (leider wenig performante) Zeichnen jeglicher Grafik durch die eignenen ZeichnungsRoutinen (zumindest mittels Swing/AWT). Das ist der Punkt der Java so "portabel" macht und das Java Programme auch sicher überall dort laufen wo es java gibt. (nein das ist kein Märchen auch wenn es mal mit rechtsklick oder so Probleme geben mag) Bei .NET wird man wohl in 99% der Fälle (in Wirklichkeit 100%) egal mit welcher Sprache "System.Windows.*" benutzen und sich damit direkt wieder in Windows Abhängigkeiten begeben. Reine Konsolen .NET Programme (z.B. C#) laufen auch Problemlos unter linux (habe selbst größere Programme in c# unter mono laufen lassen, ging gut). "System.Windows.*" ist eigentlich nichts anderes als eine gekapselte klassische Windows Gui-Api (mfc/gdi). Ergo: .NET ist im Grunde gut portierbar (was ja mit Mono auch gemacht wird), nur die GUI Bindings nicht. Und wieviele Windows32 Programme ohne GUI kennt ihr denn? Was im Artikel leider fehlt ist das der Windows Server 2003 schon eine Menge "managed code" enthält und sich damit zusehends in Richtung .net bewegt. Checkup 13:28, 17. Nov 2004 (CET)

Du scheinst vergessen zu haben, dass es noch ASP.NET gibt, was anscheinend eine Zielrichtung von Mono ist. So gibt es z. B. ein Apache-Plugin, was ASP.NET unterstützen soll.

Außerdem ist in Windows 2003 Server nur der UDDI-Dienst in managed Code geschrieben worden, wärend der Rest weiterhin unmanaged ist. Das ist auch der Grund, warum die ursprüngliche Bezeichnung Windows .NET Server fallen gelassen wurde.

J Schmitt 19:00, 17. Nov 2004 (CET)

Das ist hier bestimmt die falsche Stelle, aber ich wollte loswerden, daß mich der Satz "Keine der verwendeten Technologien ist völlig neu, aber in der Gesamtheit ist .NET eine Innovation." insofern stört als ich denke, daß er aus dem Microsoft-Werbeprospekt kopiert wurde und zu .NET rein gar nichts informatives aussagt. Bitte streichen. (KL)

[Bearbeiten] Ado.net

sollte der verwaiste kleine Artikel eingebunden werden? --Cherubino 03:35, 8. Dez 2004 (CET)

[Bearbeiten] einheitliche Typsystem

'Insbesondere das vereinheitlichte Typsystem ("Common Type System"),

Ich finde hier sollte noch mal detaillierter beschrieben werden, wie das Typsystem funktioniert und was genau die Vorteile davon sind.

[Bearbeiten] Stichwort Rotor

Rotor zum Download

Gibts von Microsoft für:

Windows
Mac OSX
FreeBSD

Zwar nur den standardisierten Teil, aber immerhin.

[Bearbeiten] CIL ist _nicht_ Sprachenunabhängig

Sonst könnte man ja z.B. _richtiges_ (ISO-)C++ auch in die CIL übersetzen. Das geht jedoch nicht. Tatsache ist, dass die CIL für C# entwickelt wurde. Nun ist C# mächtiger (oder für die VM "anspruchsvoller") als Java, daher muss auch die zugehörige Virtuelle Maschine und ihre Sprache mehr können. Somit ist es problemlos möglich, Java-Programme in CIL-Code zu übersetzen, auch für viele Skriptsprachen geht es. So gesehen ist die CIL für mehr Sprachen geeignet, als der JavaBytecode, aber eben längst nicht für alle Programmiersprachen. --RokerHRO 15:14, 30. Apr 2005 (CEST)

[Bearbeiten] Mischung von Managed und Unmanaged Code

Zitat:

Die bisher einzige Sprache, mit der man sowohl managed als auch unmanaged Code in einer einzigen Programmdatei mischen kann, ist C++/CLI (Managed C++).

Falsch. Mischung ist z.B. auch in "Borland Delphi" möglich. Korrektur momentan wegen Sperrung des Artikels leider nicht möglich NineBerry 22:36, 17. Jul 2005 (CEST)

[Bearbeiten] Sperrung

Ich habe den Artikel gesperrt, da immer wieder ein Weblink eingefügt oder gelöscht wird. Es geht dabei um http://www.codezone.de/. Ich hebe die Sperrung wieder auf, sobald an dieser Stelle eine Einigung erfolgt. Jetzt ist also die Gelegenheit für die Beteiligten hier in die Diskussion Argumente zu schreiben, wieso der Link relevant für .NET ist oder auch nicht. Viel Erfolg. -- Dishayloo [ +] 08:37, 15. Jul 2005 (CEST)

Wenn man die Seite zum ersten Mal betritt, begrüsst sie einen mit "es ist ein Fehler aufgetreten. Die von Ihnen gewählte Seite ist nicht vorhanden oder kann momentan nicht angezeigt werden.", und beim Klicken auf Content->ASP.NET erhalte ich eine "Seite" mit dem Inhalt "Seite /ASP_NET.Codezone wurde nicht gefunden." Solange das so ist, braucht man über den Link IMHO nicht mal anfangen zu diskutieren. --Eike 23:21, 21. Jul 2005 (CEST)

Mach mal wieder auf, der Artikel ist stilistisch teilweise unschön. Stimme aus dem Off

@Eike: Bei mir funzt der Link. Scheint aber beim oberflächlichen Draufschauen nur teilweise etwas mit .NET zu tun zu haben, sondern ein allgemeines Microsoft-Entwickler-Community-Portal.

Bei mir (Mozilla) hat er beim ersten Aufruf den Fehler angezeigt, bei jedem weiteren die letzte Seite, die ich aufgerufen hatte. Ich hab mal den Cache gelsöcht, dann kam wieder der Fehler... --Eike 10:36, 22. Jul 2005 (CEST)

@Stimme: Ich habe die Sperrung aufgehoben, werde aber danach schauen, ob wieder wegen dem Link hin- und hereditiert wird. -- Dishayloo [ +] 01:09, 22. Jul 2005 (CEST)

[Bearbeiten] Sun ONE vs. J2EE

Hallo, habe Sun ONE im ersten Abschnitt durch J2EE ersetzt. Sun ONE ist die J2EE-Entwicklungplatform die von Sun vertrieben wird. Sun ONE ist also das Pendant zum Microsoft Visual Studio. .NET hingegen ist nur eine Sammlung von APIs und Architekturbausteinen. .NET ist also das Pendant zur J2EE Platform. --DanielSHaischt 23:34, 18. Sep 2005 (CEST)

[Bearbeiten] Falscher Satzbau in "Ausführungsgeschwindigkeit"

Im Abschnitt 2.2 (Ausführungsgeschwindigkeit) ist der Absatz "Auf Grund der starken Unterscheidung..." unvollständig, denn nach der Klammer sollte noch etwas folgen. Auch ist nicht ersichtlich, was der Abschnitt genau aussagen will. Falls jemand Änderungsvorschläge hat - Bitte! Sonst werde ich den Abschnitt bald löschen. --Snooper77 10:57, 14. Okt 2005 (CEST)

[Bearbeiten] Lesenswerte-Diskussion

pro - zumindest für mich als Laien klingt es ziemlich gut. -- Achim Raschka 07:34, 11. Okt 2005 (CEST)
Contra - Selbstdarstellung. Wo bleibt der neutrale Standpunkt? -- FriedhelmW 13:29, 11. Okt 2005 (CEST)
contra. Auch wenn ich keine Probleme mit dem neutralen Standpunkt habe. Der Artikel ist mir zu wenig omatauglich, undefinierte Begriffe wie "Assembly", "virtuelle Laufzeitumgebung" u.a. werden einfach verwendet. Die Geschichte ist wiedermal eine (geschachtelte!) Liste. Der Unterschied zwischen "managed" und "unmanaged" Code könnte etwas besser erklärt werden. Unklar ist mir auch, welche "bestimmte Arten von Programmen" mit Garbage Collection schneller laufen sollen (obwohl ich es eigentlich wissen sollte? ;-) ). Der englische Artikel hat ein paar hübsche Diagramme, die die Struktur des ganzen Wirrwars etwas verdeutlichen. Die Kommentare im Wiki-Quelltext und einige Textstellen ("...") lassen den Artikel unfertig erscheinen. --Kurt seebauer 14:49, 12. Okt 2005 (CEST)

Contra in der Geschichte fehlt noch woher vieles aus der FCL kommt, nämlich Hejlsberg hat das von Delphi (VCL) mitgebracht und auf .NET Compact Framework wird nur sehr kurz eingegangen

[Bearbeiten] Welche Programmiersprachen gibt es sonst noch ! für ! .NET ?

Zurzeit können .NET-Anwendungen in mehr als 20 Sprachen erstellt werden,
z. B. in C++, Microsoft® Visual Basic .NET, JScript® und C#, der neuesten Sprache
von Microsoft. Eine Vielzahl weiterer Sprachen von Drittanbietern steht außerdem
zum Erstellen von .NET Framework-Anwendungen zur Verfügung, beispielsweise COBOL,
Eiffel, Perl, Python, Smalltalk und andere.
Quelle: http://www.microsoft.com/germany/msdn/library/net/MicrosoftNETFramework.mspx

Wo anderes hatte ich sogar von über 30 Sprachen gelesen, aber keine genaue Auflistung :-( Gibt es wo eine Liste aller Programmiersprachen (über 30 Sprachen) die auch mit dem .NET laufen (bzw. dafür angepasst wurden)?! --84.174.119.23 12:57, 3. Nov 2005 (CET)

Eine (evtl. nicht mehr aktuelle) Liste findet sich z.B. bei: http://dotnetpowered.com/languages.aspx zudem lassen sich über IKVM natürlich auch alle Sprachen die in Java kompilieren können auch direkt in .Net kompilieren.

[Bearbeiten] von oben hierher verschoben

(vom Verschieber: bitte fügt neue Diskussionsbeiträge unten an und macht für neue Diskussionen eigene Gliederungspunkte an. Und unterschreibt eure Beiträge mit vier Tilden (~~~~), damit ersichtlich ist, wer wann was neues geschrieben hat. --Kurt seebauer 18:00, 18. Nov 2005 (CET))

Der Artikel gehört über weite Teile komplett neu geschrieben. Er enthält fast ausschließlich Wertungen oder Meinungen des jeweiligen Autors ohne auch nur den Versuch von objektiver Betrachtung. Der ständige Vergleich mit Java ist wenig hilfreich, oft inhaltlich falsch und wiederspricht sich selbst innerhalb des Artikels mehrmals. Die Englische Version ist wesentlich besser. Vielleich sollte man die einfach übersetzen und hier verwenden?

Konkret wäre es wohl besser den Artikel komplett aufzuspalten in einen Artikel über den CLI-Standard und einen über Microsofts Implementierung davon: .Net. Momentan werden einige Sachverhalte (z.B. JIT 4 mal erläutert, oft auch noch unterschiedlich). Praktisch alle Inhalte werden zwei mal vorgestellt: Einmal in Kapitel zwei und dann ab Kapitel 3 (z.B. 2.2 Ausführungsgeschwindigkeit vs. 6 Ausführungsgeschwindigkeit). Die Wiedersprüche sind eklatant (.Net hat keine nennenswerte Verbreitung vs. historisch zu bezeichnenden Bruch). Oder:

Für den Erfolg von .NET war es wichtig, die Entwicklergemeinde von C++ für .NET zu gewinnen; Daher war Geschwindigkeit bei .NET von Anfang an ein wesentliches Designziel. Dies ist ein wesentlicher Unterschied zu den ersten JVMs.

Da sich .NET und JVMs technisch gesehen ähneln (Zwischencode wird auf stackbasierter VM ausgeführt und von einem JIT-Compiler dynamisch optimiert), ist die Ausführungsgeschwindigkeit der Java-Implementierung von Sun mit der .NET-Laufzeitumgebung von Microsoft vergleichbar.

Also gleich oder doch nicht??

Oft steht auch einfach nur Blödsinn in dem Artikel:

Da die Hotspot-Engine von SUN zuerst durch Profiling feststellt, für welche Methoden sich eine Optimierung lohnt, stimmen leider viele Microbenchmarks nicht mit der tatsächlich im Produktiveinsatz erreichten Performance überein.

Ein Microbenchmark, der mit der Produktivperformance übereinstimmt - das ist ja ein Wiederspruch an sich. Dann wäre es ja kein Microbenchmark. Was hat das denn überhaupt in einem Artikel über .Net zu suchen?

Der Abschnitt Attribute besteht, wie viele anderen Stellen auch, zu 25% nur aus JAVA-Inhalten - was haben diese dort verlohren. Ein Vergleich ist ja sicherlich sinnvoll - aber nicht alle 5 Zeilen und nicht in dem Umfang. Der Java-Artikel hat das wesentlich besser gelöst.

Anders als bei Java, kann .NET verschiedene, von der Laufzeitumgebung unterstützte Programmiersprachen ausführen.

den Satz würd ich streichen,ich denke der Autor verwechselt die Sprache JAVA mit der Java Virtual Machine, für die gibts sehr wohl auch andere Sprachen siehe: http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html 195.243.149.235

Satz präzisiert. Der folgende Absatz erläutert den Sachverhalt nochmals. Java als Sprache und Laufzeitsystem unterstützt in der Spezifikation keine anderen Sprachen außer Java und dessen JSR-Erweiterung Java 1.5 / Generizität. Daher ist der Satz im Zusammenhang mit CLS und CLR von .NET richtig. Im Falle von Java wäre er falsch, da nicht spezifiziert.

Ich find' das immer noch unglücklich formuliert, ich sehe nur den Unterschied das es von SUN keine anderen Compiler für die JVM als Java gibt. Die JVM kann durchaus auch mit anderen Compilern benutzt werden. Ich schlage folgende Formulierung vor.

Anders als Suns Java Virtual Machine, wurde die .NET-Laufzeitumgebung (Common Language Runtime, kurz CLR) bereits durch den Hersteller mit Compilern für verschiedene Hochsprachen unterstützt. Hierzu existiert die so genannte Common Language Specification (CLS).

Welche Hersteller sind das? Und welche anderen Hersteller gibt es für Java und wo ist das spezifiziert. Die Spezifikation der JVM liegt bei Sun und wurde von Sun definiert... und die sieht neben Java nur Java vor. Alles andere sind vielleicht private Projekte - aber bisher kenne ich keine Hochsprache, die von der JVM unterstützt wird (und JPython ist in der Summe auch Java und außerdem keine Hochsprache, sondern eine Skriptsprache, die Java erzeugt). PS Im Deutschen verwendet man keine Hochkommata um den Plural auszudrücken: Sun's -> Suns (genug Besserwisserei für heute ;-) TG 03:00, 20. Feb 2004 (CET)

Lies den Absatz noch mal, da fehlte zwar ein "der" aber es ging hier um .NET. Du hast natürlich recht wenn du sagst das Sun nur Java als Sprache für die JVM definiert hat und auch anbietet, aber die Behauptung es gäbe keine anderen Compiler dafür ist falsch, ob das "Hobby" Projekte sind (Hast du die Liste überhaupt angesehen?) oder nicht tut nichts zur Sache. Es gibt keine Mechanismen die verhindern würden das nur vom Java Compiler erzeugter Bytecode auf der JVM laufen würde und es gibt genug Implementierungen die das belegen.195.243.149.235 21:02, 22. Feb 2004 (CET)

Inoffiziell. Hier geht es aber um offizielle Fakten. Die Sprachdefinition, der Sprachstandard als auch die VM-Spezifikation unterstützen es nicht. Und nicht jedes Hobby-Projekt gehört in Wikipedia-Artikel. .NET unterstützt es offiziell, Java offiziell nicht. Daher sollen die Artikel auch entsprechend neutral bleiben. Ggf. weise im Java-Artikel über einen Weblink darauf hin - aber nicht jedes Hobby-Projekt ist für einen enzyklopdäd. Artikel relevant.

Es geht mir nicht um jedes Hobby Projekt sondern um die Unterscheide zwischen CRL und JVM. Ehrlich gesagtt bezeifle ich das du die Spezifaktion der JVM jemals gelesen hast, dort steht nämlich nur drin das die JVM nicht jede beliebige Sprache gleich gut geeignet sei (was zweifellos auch für die CLR zutrifft).

Genau darum geht es doch das die eben NICHT für die CLR zutrifft. Hier können die Sprachen sich unterscheiden und trotzdem stellt die CLS sicher, dass sich vollständig kompatibel sind (z.B. Verwendung von Pointern in C#). Wenn du die CLI-Spezifikation auch mal angeschaut hättest, hättest du vielleicht sogar festegstellt, dass dort Java fast so oft genannt wird wie C#.

Auch die CLR ist nicht für jede Sprache gleich gut geeignet. Die CLS stellt nur sicher, daß Sprachimplementierungen, die für die CLS geschrieben sind, kompatibel sind, sie stellt nicht sicher, daß sich jede Sprache ohne Abstriche und ohne Abweichungen von der ursprüngliche Sprachdefinition auf der CLR implementieren läßt. Oefe 17:17, 2. Apr 2006 (CEST)

Zitat Although this chapter concentrates on compiling source code written in the Java programming language, the Java virtual machine does not assume that the instructions it executes were generated from such code. While there have been a number of efforts aimed at compiling other languages to the Java virtual machine, the current version of the Java virtual machine was not designed to support a wide range of languages. Some languages may be hosted fairly directly by the Java virtual machine. Other languages may be implemented only inefficiently.

Ein Hinweis das die Spezifikation auf Java beschränkt sie lese ich auch nicht.

Zitat The Java virtual machine knows nothing of the Java programming language, only of a particular binary format, the class file format. A class file contains Java virtual machine instructions (or bytecodes) and a symbol table, as well as other ancillary information.

Quelle: http://java.sun.com/docs/books/vmspec/2nd-edition/html/VMSpecTOC.doc.html 195.243.149.235 22:21, 22. Feb 2004 (CET)

"(beispielsweise sind auch 2004, über fünf Jahre nach der Fertigstellung von C#, die verbreitetsten Betriebssysteme noch wesentlich in C geschrieben)."

Soll das heissen, dass Betriebssysteme in Zukunft in C# geschrieben werden sollen? Na, da bin ich aber gespannt ... (nicht wirklich, ich halte diesen Satz fuer Bloedsinn) -- twm

Fast unerwartet scheint der Anklang der .NET-Technologie bei Anbietern marktenger Programmiersprachen oder in Forschung und Lehre.

Was bitte sind marktenge Programmiersprachen? Und was bitte ist ein unerwarteter Anklang von X? Das sind Vermutungen bzw. Meinungen und keine Tatsachen Benutzer:Sebastian.Dietrich, 10.7.2006

[Bearbeiten] Geschichte aus der Zukunft

unter der überschrift "Geschichte" befindet sich ein Eintrag für Februar 2006. bin der Meinung das sollte in "Ausblick" gehören - oder wer hat da seine Zeitmaschine angeworfen ??? --Tom82 15:40, 14. Dez 2005 (CET)

[Bearbeiten] Maschinencode, aber nicht schneller?

Das hier ist etwas verwirrend finde ich: "Des Weiteren kann man mit .NET auch Programme in bereits kompiliertem Maschinencode vorinstallieren, wodurch sich insbesondere (und nur) die erstmaligen Ladezeiten bei Programmen mit größeren Klassenmengen reduzieren." Es ist doch so, dass NGen (darum geht's ja wohl hier) eben keinen Maschinencode erzeugt, sondern Bytecode, der nur auf den jeweiligen Prozessor optimiert ist. Wenn es tatsächlih Maschinencode wäre, wäre es ja nicht nur bei mersten Start sondern immer signifikant schneller. "als Neuerung" ist mir auch nicht klar, das ging doch mit .net schon immer. also vielleicht eher: "Des Weiteren kann man mit .NET auch Programme in bereits kompiliertem Bytecode im sogenannten Global Assembly Cache (GAC) vorinstallieren, wodurch deren erstmalige Ausführung beschleunigt wird, da hier dann kein Kompilieren durch den JIT mehr nötig ist. "

NGen erzeugt Maschinencode (engl. native code). Quelle: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cptools/html/cpgrfnativeimagegeneratorngenexe.asp Oefe 21:39, 20. Feb 2006 (CET)

[Bearbeiten] Die CIL hieß früher Microsoft Intermediate Language (MSIL), wurde aber im Rahmen der Standardisierung durch die ECMA umbenannt.

Bei ECMA heißt es CIL, bie Mircosoft weiterhin MSIL.

[Bearbeiten] Linkfarm

wenn ihr die Linkfarm am Ende des Artikels so schick findet, bitte. @IP, von welcher Diskussion redest du? Sehr fein von dir, anonym aufzutreten, so dass man nichtmal mit dir diskutieren kann. --Kurt seebauer 22:30, 22. Mär 2006 (CET)

Darum geht es nicht. Wenn Dich die Links stören, dann entferne die Links aus den Einträgen und nicht die ganze Liste. Wenn Dich das Aussehen der Liste stört, dann überlege Dir, wie man sie "schöner" macht und lösche nicht einfach die gesamte Liste. Und wenn Du zu so etwas keine Lust hast: dann lass es bleiben! So einfach! Ist halt nur ärgerlich für denjenigen/diejenige, der/die solche Listen angefangen hat zu erstellen bzw. an ihr arbeitet. Wichtig finde ich ist, dass diese Liste direkt in dem .NET Artikel steht, statt bspw. auf eine externe Seite zu verlinken (Letzteres kann man noch zusätzlich machen, als WebLink), weil wenn der extrene Link nicht mehr existiert kommt man zumindest nicht schnell an eine Liste von .NET-fähigen Programmiersprachen. Und da WikiPedia ein "besseres Lexikon" ist, sollte man solche wichtigen Informationen auch speichern und hier geordnet und "zentral" sammeln. Wo man die Sachen findet und downloaden kann, ist ja schliesslich auch bei Google oder anderen Suchmaschinen rauszufinden, das sehe ich ein. Für mich persönlich ist die Liste relevant, da ein .NET-Merkmal nunmal die Sprachvielfältigkeit ist. --GeneralPD

Ich finde die Liste auch wichtig auf Grund des Merkmals Sprachvielfalt. Sonst kann ich mich den Vorrednern nur anschließen. P.S. Zwei der Reverts deiner Löschaktion waren von mir. --Fox

So, hab mir mal die Mühe gemacht, die Liste der Sprachen in Tabellenform zu bringen und die Links rauszuhauen. --GeneralPD

[Bearbeiten] Unterschied Lauffähigkeit Framework und SDK

Hallo.

Ich hätte mir im Artikel einen Hinweis zum Unterschied auf die Lauffähigkeit des Frameworks und des SDKs auf bestimmten Plattformen gewünscht.

Leider ist es so, daß das Framework (1.0, 1.1, 2.0) auch auf Windows 98 läuft, das SDK aber nicht. Noch nicht einmal das SDK 1.0 . Warum das so ist, wird mir immer ein Rätsel bleiben, denn ich hätte angenommen, daß, wenn das Framework auf einer Plattform lauffähig ist, das SDK es das auch sein sollte - sooo große Unterschiede sollte es doch eigentlich nicht geben, so meine Annahme.

Die Annahme ist aber sicher nicht richtig. Einen ziemlichen Unterschied dürfe z.B. der Debugger sein, der Bestandteil des SDKs ist. Der müsste für Win9x aufgrund der komplett unterschiedlichen OS-Architektur wohl auch komplett neu geschrieben werden. Ausserdem sind noch einige native Tools Teil des SDKs, die die NT APIs verwenden.

Und ich möchte keine Bemerkungen vom Typ "kauf dir doch mal ein *modernes* Betriebssystem" hören. Ich komme mit Windows 98 gut zurecht, warum also soll ich upgraden ? Zumal DOS-basierte

Naja - von einem Nutzer kann ich das Argument ja noch halbwegs nachvollziehen - aber von einem Entwickler???

Programme auf "modernen" Windows Betriebssystemen zunehmend nicht mehr laufen (einmal vom Einsatz von Emulatoren abgesehen).--Alrik Fassbauer 16:10, 26. Mai 2006 (CEST)

[Bearbeiten] Satzbau in: * 2001–2002 – Verwirrung: Im Zuge des ..

Könnte vielleicht jemand mit .net-know-how die Sätze in diesem Paragraphen grammatikalisch richtig stellen? Gruß

[Bearbeiten] verstehen

sorry der Artikel ist nur für ITs verständlich....

Danke, den gleichen Eindruck habe ich auch. Beispiel Abschnitt "CIL, CLR und Reflexion": Von "Assembly" ist die Rede, obwohl dieser Begriff nirgends erklärt wird. Der Begriff kann auch nicht zum Thema ".NET" vom Leser als bekannt vorausgesetzt werden, ist es doch eine der neuen Begrifflichkeiten, die erst mit .NET gekommen ist.

Anderes Beispiel: Abschnitt "Vorteile" Hier ist von vielen Vorteilen von .NET die Rede, aber es wird nur ein einziger aufgeführt. --213.61.168.82 17:34, 13. Mär. 2007 (CET)

[Bearbeiten] Überarbeitung?

Als jemand, der als Technologieberater (oder Developer Evangelist) im Bereich der .NET Plattformtechnologien arbeitet (bei Microsoft) haben sich mir beim Lesen des Artikels an mehreren Stellen Kommentare aufgedrängt, die ich gerne diskutieren würde.

Einmal ist es so wie ein Vorschreiber anmerkte, daß es keine "Omatauglichkeit" gibt, sprich: Vielleicht wäre eine etwas ausgebautere allgemeinere Beschreibung ganz am Anfang wünschenswert? Eine Art Executive Summary? Zwar läßt sich bei einer solchen Technologie nicht vermeiden, daß es später spezifischer wird, aber der Einstieg sollte noch jedem einen Eindruck vermitteln können was gemeint ist.

Vielleicht ließe sich das einfacher erreichen indem der Artikel in mehrere Teile zerlegt wird? Themenvorschläge: 1. .NET Generell 2. CLR / CLI 3. .NET Framework Bibliotheken 4. .NET Framework 3.0 (weil es sich dabei im Grunde um Framework 2.0 PLUS zusätzliche Bibliotheken handelt)

Der Artikel bedarf IMO auch an einigen Stellen einer sachlichen Korrektur, beispielsweise Aussagen zur Performance und den vorhandenen APIs bzw. auch deren Vergleiche mit Java sind z.T. falsch oder widersprüchlich.

Überhaupt taucht der Begriff "Java" im gesamten Artikel fast häufiger als ".NET" auf. Wie wäre statt dessen ein eigener Absatz, in dem sachlich und ausführlich auf Gemeinsamkeiten und Unterschiede eingegangen wird anstatt durch den gesammten Artikel hindurch ständig Vergleiche zu Java zu ziehen, die oft noch nicht mal korrekt sind? Stattdessen wären sachliche Hinweise auf ähnliche Grundkonzepte in konzentrierter Form sicherlich nützlich.

Einige Kommentare im Text lassen es mir allgemein auch an Neutralität und Sachlichkeit mangeln. Schon die Historie enthält in einem der ersten Sätze z.B. die Behauptung, daß es für Microsoft untypisch sei, anerkannte Experten zu engagieren. Mal davon abgesehen, daß das eine aus der Luft gegriffene Behauptung ist fragt man sich was das nun in einem Artikel über .NET an sachlichem Mehrwert bringt?

So, bin jetzt mal auf Kommentare gespannt. Ich bin mir etwas unsicher, ob ich mich selbst an die Überarbeitung des Artikels machen sollte. Schließlich arbeite ich beim Hersteller besagter Technologie und will nicht den Eindruck erwecken, eine Werbeveranstaltung zu bezwecken. Auf der anderen Seite qualifiziert mich meine Tätigkeit eigentlich in der Sache. Wenn jemand Lust hat, sich an meiner Stelle damit ausgiebiger zu befassen, biete ich in jedem Fall meine Hilfe als Resource an... DirkPrimbs 02:01, 5. Aug 2006 (CEST)

Hallo DirkPrimbs, finde deine Idee grundsätzlich gut. Und eigentlich spricht doch auch nix dagegen das ein erstes Redesign von die erstellt wird, schließlich bist du ja scheinbar Experte in diesem Bereich. In anderen Bereichen der Wikipedia hat es sich dazu als sinnvoll herausgestellt einen extra Artikel im Benutzerbereich zu erstellen und dort die ersten Schritte zum Redesign zu unternehmen. Du könntest ja damit anfangen und im weiteren dann den Link zu diesem Artikel hier posten. So können wir das dann hier diskutieren, verbessern und den Vorwurf der Werbekampagne aus dem Weg gehen (-: Daniel Bovensiepen 15:14, 5. Aug 2006 (CEST)

Da ich viele der Wünsche von dem Microsoft-Spezialisten durchaus berechtigt finde, habe ich mich des Artikels angenommen.

Notizen meiner Änderungen:

unnötige Java-Relationen entfernt
eine einfache Erklärung am Anfang hinzugefügt - dafür wurde "Konzept" gestrichen
Historie überarbeitet
Java in einen eigenen Abschnitt beschrieben
Aussagen zu .NET bzgl. Java und .NET-Performance revidiert

Allerdings sehe ich die vielen Vergleiche zu Java über den ganzen Artikel hinweg durchaus als berechtigt an. Microsoft traf die Entscheidung zu .NET nunmal wegen Lizenzproblemen mit Sun's Java, und .NET ist Java auch sehr ähnlich, es ist eben nur eine lizenzfreie Idee. Also muss Microsoft - und damit auch die Spezialisten - sich den Vergleich mit Java und die Kritik gefallen lassen.

Wen es trotzdem stört, kann ja ein Textbaustein "Überarbeiten" setzen. Ansonsten ist der Artikel NEUTRAL. --sToneHeaRT 17:27, 9. Nov. 2006 (CET)

83.236.201.101: Wo bitte ist das denn neutral? Siehe den Abschnitt drunter zum Thema Ausführungsgeschwindigkeit. Daran kann ich nichts Neutrales finden. Lediglich eine pro .NET Behauptung....

[Bearbeiten] Ausführungsgeschwindigkeit

Für den Erfolg von .NET war und ist es wichtig, die Entwicklergemeinde von C++ für .NET zu gewinnen. Daher war Geschwindigkeit bei .NET von Anfang an ein wesentliches Designziel. Wie weiter oben schon erwähnt, wird ein Anwender von .NET-Applikationen keinen Tempo-Unterschied zu herkömmlichen Applikationen bemerken.

Inzwischen sind zahlreiche Spiele in C# und für .NET entwickelt worden. Spieler bemerken aber auch hier keinen Einbruch in der Performance ihrer Software.

83.236.201.101: Wer hat den diesen Stiefel zusammengeschrieben? Bis auf die ersten beiden Sätze hab ich alles gelöscht. Da dieser erste Satz für sich alleine jedoch recht nutzlos ist, würde es Sinn machen den ganzen Abschnitt zu entfernen. Aber so einen geistigen Abfall hab ich echt selten hier gelesen. Klingt wie 'ne Microsoft Marketingbroschüre. Es wurden ja nichtmal Belege oder Beispiele aufgeführt. Da hätte man auch gleich schreiben können ".NET ist ganz furchtbar viel doll schneller als alles was es sonst so gibt" ...

83.236.201.101: Zusatz: Der erste Abschnitt Ausführungsgeschwindigkeit sollte ganz gelöscht werden. Wie ich eben gesehen habe gibt es diesen kurioserweise zwei mal. Der obere enthält den hier erwähnten subjektiven Blödsinn während der zweite Abschnitt zu dem Thema einen wesentlich fundierteren Eindruck macht. Leider ist die DB im Moment gesperrt.

[Bearbeiten] Sicherheit?

Also der Abschnitt über die Sicherheit ist doch ein schlechter Witz. .NET kann höchstens dafür sorgen, daß legitime Applikationen sich selbst einschränken können, um die Fehleranfälligkeit zu verringern, aber gegen illegitime Applikationen funktioniert das nicht. Zum einen liegt es daran, daß der Verifier als "safe" deklarierten "unsafe" Code nicht zuverlässig rausfiltern kann, zum anderen hat die gesamte Klassenbibilothek so gut wie nirgendwo einen Referenzschutz implementiert, sodaß Applikationen interne höherprivilegierte Threads beeinflussen können.

Hast du Belege dafür, dass der Verifier unsafe Code nicht erkennen kann? AFAIK ist es eher so, dass der Verifier nicht jeden sicheren Code erkennen kann und ihn deshalb als unsicher annimmt (wie bei Java). Das ist zwar nur eine konservative Art der Validierung, lässt aber schon wirklich nur sicheren Code zu. Das mit der Klassenbibliothek verstehe ich auch nicht. Die Bibliothek selber muss natürlich auch Berechtigungen prüfen, was sie auch tut. Wenn du beispielsweise keine I/O-Berechtigung und keine Berechtigung zum nutzen von unsafe Code hast, dann wird es dir nicht gelingen, I/O durchzuführen - du kannst keine Win32-APIs oder ähnliches aufrufen und aus der Klassenbibliothek kriegst du auch SecurityExceptions. Gruß, Michael --88.64.5.185 12:10, 15. Feb. 2007 (CET)

Von „http://de.wikipedia.org../../../d/o/t/Diskussion%7EDot_Net_9c6e.html“