Diskussion:.Net-Framework

Diese Diskussionsseite dient dazu, Verbesserungen am Artikel „.Net-Framework“ zu besprechen. Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.

Füge neue Diskussionsthemen unten an:

Klicke auf Abschnitt hinzufügen, um ein neues Diskussionsthema zu beginnen.

• Diskussionsregeln
• Hilfe zu Diskussionsseiten
• Sei sachlich und freundlich!
• Greife niemanden persönlich an!
• Geh von guten Absichten aus.

Diese Diskussionsseite wurde aufgeräumt.
Einträge ohne direkten Diskussionsbezug oder nicht unterschriebene Einträge wurden ohne Archivierung entfernt, Verbleibendes ins Archiv verschoben, sofern die Diskussion als abgeschlossen erachtet wurde. Bitte nicht wieder zurückverschieben, sondern das Thema neu starten. Die Archivierung erfolgt von Zeit zu Zeit, um die Übersicht wiederherzustellen.

Dies betrifft nur Abschnitte bis zum 27. Dezember 2008. Sie sind hier auffindbar: [1].

Automatische Archivierung

Auf dieser Seite werden Abschnitte automatisch archiviert, deren jüngster Beitrag mehr als 90 Tage zurückliegt und die mindestens 2 signierte Beiträge enthalten.

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.

Stichwort Rotor

Rotor zum Download

Gibts von Microsoft für:

• Windows
• Mac OSX
• FreeBSD

Zwar nur den standardisierten Teil, aber immerhin.

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.

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ß

Visual Studio-Vollversion wirklich benötigt für Sprachen von Drittherstellern?

Es ist möglich, Programmiersprachen von Drittherstellern in Visual Studio.NET einzubinden, was die Entwicklung einer
eigenen Integrierten Entwicklungsumgebung zwar erspart, jedoch auch Kunden dazu zwingt, sich dieses relativ
teure Produkt zu kaufen. Dieses Feature ist eher für den Entwickler gedacht, der andere
Programmiersprachen, als die in Visual Studio.NET bereits integrierten, nur nebensächlich nutzen möchte.

Stimmt das wirklich? Ich meine, mich erinnern zu können, dass ich die reine Microsoft-Entwicklungsumgebung (devenv.exe) auch ohne gekaufte VS-Version installiert hatte, wahrscheinlich durch das .NET-SDK. Für was wäre die da, wenn man sie nicht mit anderen Programmiersprachen hernehmen könnte?

132.231.54.1 18:59, 28. Mär. 2007 (CEST)

Nein man Braucht kein VS. Das sieht man schon an Borlands Delphi for .NET. Das braucht nur das .NET SDK.

Anwender Tipp: Wie erkenne ich meine .NET Version

Wäre vielleicht noch angebracht, neben der 'Fachsimpelei' :) kurz zu erwähnen, wie man bei Windows die/ob installierte .NET Framework Version herausfindet. -> [2] (leider nur bis Version 2.0)

Fachchinesisch

Ich glaub, den Thread gabs schon mal, aber ich schreib es wieder:

Der Artikel ist für Laien unverständlich. Ohne sämtliche Links (und unverlinkte Begriffe) zu studieren findet man kaum raus, worum es sich bei .net überhaupt handelt. Es wäre toll, wenn wenigstens die Überschrift so formuliert wäre, dass auch ein ganz normaler PC-Nutzer weis, worum es geht. LG --hooks 13:02, 31. Mär. 2008 (CEST)

Artikel umgestellt

ich habe den Artikel nun ein bisschen umgestellt, so ist aus meiner Sicht das wichtige oben und das unwichtige weiter hinten....Ausserdem ist so der Lesefluss angenehmer...Einige unbelegte Dinge bzw unwichtige Dinge sind rausgeflogen --Bitsandbytes 20:11, 31. Mär. 2008 (CEST)

Bzgl. Plattformunabhängigkeit

Es wird noch erwähnt, dass Mono WinForms nicht komplett unterstützt. http://jpobst.blogspot.com/2008/05/big-finale.html besagt, dass auch WinForms 2.0 komplett unterstützt wird, wenn es auch noch kein offizielles Release dafür gibt. Ich hätte den Text zwar gerne geändert, aber ich weiß nicht, ob Paint .NET nur wegen WinForms nicht auf Mono läuft oder die Software einige Windowssystemfunktionen verwendet, die bei Linux eine eigene Implementierung verlangen würden.

Paint.net verwendet für Teile des UI pinvoke, es gibt einen port (paint-mono, http://code.google.com/p/paint-mono/, 3.0), der das nicht benötigt, der ist aber nicht so besonders aktuell wie Paint.Net selbst (3.31).

Es wäre aber schon nett, wenn schon mal Sharpdevelop ohne Anpassungen auf mono rennt. -- Inspectre

Version 3.5.1

Ist es zu spitzfindig festzustellen, dass es keine Version 3.5.1 gibt, sondern nur eine Version 3.5, zu der ein/das Service Pack 1 herausgekommen ist? Wenn nicht, sollte man das korrigieren, d.h. Versions- und SP-Nummer trennen. Denn Microsoft spricht auch nicht von einer Version 3.5.1, die so vielleicht jemand suchen würde...

Das ist keineswegs zu spitzfindig, sondern einfach korrekt. ;) Ich habe das inzwischen korrigiert. BSDev 20:19, 26. Nov. 2008 (CET)

Umfang der Klassenbibliothek

Unter "Klassenbibliothek" wird ein Umfang von 2500 Klassen angegeben. War das nicht der Wert für die Version 1.0? Wenn ich mich recht erinnere, ist dieser Wert bereits mit der Version 2 des .NET Frameworks auf 7500, und seit 3.5 auf 12500 angestiegen. Hab leider die Quelle vergessen und will jetzt nicht alle Klassen aufzählen :)

Ich hab's eben mal aktualisiert. -- BSDev 22:26, 25. Dez. 2008 (CET)

Schwaechen bei Remoting

Im Artikel ist die Rede davon die .Net Remoting Technologie nur einzusetzen wenn man genau ueber deren Schwaechen bescheid wuesste. Hier wuerde ich mir eine Begruendung/Verweis wuenschen, oder am besten direkt eine Info mit den Schwaechen.

Versionshistorie - Features von 1.0?

In der Versionshistorie wurden zwar die Änderungen zwischen den einzelnen Versionen erwähnt, womit jedoch das .net Framework 1.0 begonnen hat ist nicht ersichtlich. Welche Bibliotheken waren bereits verfügbar? Sollte ausgebaut werden.

nicht OMAtauglich

Könnte jemand die Einleitung um einen OMAtauglichen Absatz ergänzen (oder die gesamte Einleitung umschreiben, wäre natürlich noch schöner), damit jeder Leser zumindest eine grobe Idee hat, was .NET "tut"? Ich weiß es nach unserer derzeitigen Einleitung leider selbst noch nicht, kann also gern jeden Absatz probelesen! :o) ... Herzlichen Dank, Ibn Battuta 04:31, 22. Mär. 2009 (CET)

integraler Bestandteil

Taucht mindestens zweimal in diesem Artikel auf, ist jedoch ein Pleonasmus und damit genaugenommen falsch, denn ein Bestandteil ist immer integriert, also "integral". (nicht signierter Beitrag von 89.244.69.214 (Diskussion | Beiträge) 09:50, 29. Apr. 2009 (CEST))

Mangelnde Neutralität

"Die verschiedenen Strukturen innerhalb von .NET 2.0 sind trotz breiter Auswahl und technisch teilweise guter Ansätze, nicht ausgereift." ist reiner POV, da weder mit Quellen belegt noch vernünftig erläutert. In dieser Form sollte der Satz nicht im Artikel bleiben, daher lösche ich ihn morgen, falls sich da nichts tut. (nicht signierter Beitrag von FoxtrottBravo (Diskussion | Beiträge) 12:43, 8. Jul 2009 (CEST))

Wie werden .NET-Anwendungen "initialisiert"?

.NET-Compiler erzeugen ja keinen Maschinencode, sondern einen Zwischencode, die Common Intermediate Language, die, ähnlich dem Java Bytecode, anschließend durch eine virtuelle Maschine, die Common Language Runtime, interpretiert wird. Die .NET Assemblies (Endung ".exe" oder ".dll") enthalten aus Kompatibilitätsgründen einen "PE-Stub" (ähnlich, wie "PE-Dateien" einen "MZ-Stub" enthalten), welcher eine Fehlermeldung ausgibt, wenn er ausgeführt wird. Dies ist der Fall, wenn auf dem System keine Common Language Runtime installiert ist. Ist eine Common Language Runtime installiert, erkennt Windows anhand von Informationen im PE-Header, dass die Datei keinen Maschinencode, sondern eben Code in CIL enthält und läd die Virtuelle Maschine, um den Code auszuführen. Quelle: ECMA-335 Spezifikation, Abschnitt 25 "File format extensions to PE". MetalTux 00:37, 18. Sep. 2009 (CEST)

DreamSpark

Sollte man nicht vielleicht noch hinzufügen, dass auch Schüler ab der 5. Klasse (mit ISIC) DreamSpark nutzen können?

-- leseratte123 14:46, 22. Sep. 2009 (CEST)

Kompatibilitätsprüfung von Assemblies im Execeutable-Path

Meine Änderung bezüglich der Versionsprüfung wurde ja leider kommentarlos rückgängig gemacht, daher muss ich das jetzt wohl zur Diskussion stellen. Im Abschnitt [3] ist folgender Satz enthalten:

Daher wird angenommen, dass die Version des Assemblys kompatibel zum Programm ist und daher nicht von der CLR geprüft wird.

Tatsache ist, dass die Version nicht geprüft wird. Allerdings ist die Vermutung, dass die Versionen kompatibel sind, nicht die Ursache für die "Nicht-Prüfung", sondern eine Wirkung. Stein des Anstoßes ist die Formulierung und daher nicht von der CLR geprüft wird, was ich in was nicht von der CLR geprüft wird umschreiben wollte. Wie gesagt, leider ohne Kommentar rückgängig gemacht. Was ist eure Meinung dazu? --PeterVitt 11:25, 8. Nov. 2009 (CET)

Abwärtskompatibilität neuerer .NET-Versionen

Hallo,

auch wenn vielleicht Wikipedia nicht der optimale Platz dafür ist, so stellt sich mir die Frage der Abwärtskompatibilität. Bei mir listet Windows mittlerweile 5 verschiedene .NET-Frameworks im Bereich Software auf. Benötige ich als Endanwender all diese verschiedenen Versionen oder ist die jeweils aktuelle .NET-Framework-Version in der Lage, auch Programme für bspw. .NET-Version 1.1 oder 2.0 auszuführen?

Angesichts der vielen verschiedenen Versionen, wäre eine Klärung dieses Sachverhalts von einer kundigen Person sehr schön. -- 84.188.208.118 21:26, 1. Dez. 2009 (CET)

Da mich das ganze sehr interessiert, habe ich mal nachgeforscht und diesen Newsgroup-Beitrag gefunden: http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx?dg=microsoft.public.de.german.entwickler.dotnet.framework&tid=42326464-6a46-459d-a348-53269731fd0f&cat=de_DE_8465b0b6-ea6d-46fa-962e-9a6f91dccfb0&lang=de&cr=DE&sloc=&p=1 Im zweiten Beitrag werden die Unterschiede erklärt. Möchte das jemand verarbeiten? -- 84.188.231.6 03:08, 2. Dez. 2009 (CET)

---

Eine Frage zu dem Teil: "Aktuelle Windows-Versionen besitzen eine Explorer-Erweiterung, die eine aussagekräftige Anzeige des Inhalts des GAC im Windows Explorer ermöglicht."

Was ist unter einer "aktuellen" Windows-Version zu verstehen? XP? Oder Vista? (nicht signierter Beitrag von 62.47.24.185 (Diskussion | Beiträge) 12:31, 22. Feb. 2010 (CET))

Allgemeinverständlichkeit

Siehe oben: Nicht einmal die Einleitung ist für Nicht-Fachleute verständlich. Von weiteren Artikel-Abschnitten ganz zu schweigen. Die Verlinkung ist ja schön und gut, aber wer erst die halbe Wikipedia lesen muß, um auch nur grob das Lemma zu erahnen, für den Artikel ist der Artikel leider wertlos. Daher bitte einfach mal die Mühe machen, der guten alten "Oma" (oder meinetwegen der "Tante") .NET zu erklären... was übrigens der Sinn einer Enzyklopädie (im Gegensatz zu einem Fachlexikon) ist. Und richtig - wenn der Artikel daraufhin ein paar Sätzchen länger wird, ist das kein Beinbruch. [Und nein, es geht nicht darum, die Fach-Informationen zu verwässern... nur darum, auch Ibn Battuta & Co. ahnen zu lassen, was für Fach-Informationen das überhaupt sind.] Es dankt aufrichtig Ibn Battuta 21:07, 23. Feb. 2010 (CET)

Habe die Einleitung mal etwas umformuliert, so sollte das Allgemeinverständlicher sein ohne viel an Genauigkeit zu verlieren. Und viel einfacher gehts auch nicht mehr im enzyklopädischen Rahmen. Baustein raus. --Tinnef 20:18, 31. Mär. 2010 (CEST)

Plattformunabhängigkeit

Soweit ich weiss ist das aktuelle Mono vollständig zu .NET 3.5 kompatibel.

Der Artikel meint das Mono nur Teilweise bis garnicht 3.5 unterstützt.

http://www.mono-project.com/Compatibility

Laut den Release Notes sollen sogar schon teile von .NET 4.0 teilweise implementiert sein die über einen bestimmten Parameter beim kompilieren benutzt werden können.

Also denke ich sollte man das Teilweise bis garnicht in ein zu 95% umwandeln oder so.

Zitat von der Mono Homepage: The easiest way to describe what Mono currently supports is: Everything in .NET 3.5 except WPF and WF, limited WCF. (nicht signierter Beitrag von 80.128.208.13 (Diskussion | Beiträge) 01:14, 18. Mär. 2010 (CET))

.Net als Plattform zur Softwareentwicklung

.Net wird z.B. in der aktuellen iX, Nr4 im Titelthema als ebnsolche bezeichnet. Care to elaborate? --Tinnef 15:49, 4. Apr. 2010 (CEST)

Wie es sogar im Artikel .Net#Konzept steht: Die Laufzeitumgebung ist die CLR, und Bestandteil von .Net. .Net selbst ist IMHO mehr als nur eine Laufzeitumgebung. --Tinnef 19:09, 4. Apr. 2010 (CEST)

Nach deiner Definition ist dann jeder Prozessor eine Plattform zu Softwareentwicklung. Assembler braucht man dafür dann aber nicht. Oder steckt im .NET der Compiler von ASP/Java/VB/C#/C++ nach CIL schon drin? Ich fürchte nicht. Allerdings könnte es schwierig sein, erstmal einfach so Software zu entwickeln ohne Compiler, zumindest ohne Hex-Editor. Ist bei .NET ein Hex-Editor dabei? Bibliotheken allein sind keine Entwicklungsumgebung. --Trac3R 01:03, 5. Apr. 2010 (CEST)

Bei genügend großem Abstraktionsgrad ist auch meine Schreiptischplatte eine Plattform zur Softwareentwicklung. Allerdings sehe ich nicht, inwieweit solch philosophischen Betrachtungen den Artikel voran bringen können. Fakt ist, ich habe eine Quelle für meine Formulierung angegeben (iX). Über die Qualität der Quelle kann man natürlich streiten, aus der Luft gegriffen ist das zumindest nicht. Ich benutze .Net auf jeden Fall zur Softwareentwicklung, ich kenne das als allgemein üblichen Sprachgebrauch. Ich sehe auch regelmäßg z.B. Stellenauschreibungen, in denen .Net-Entwickler gesucht werden. Microsoft bezeichnet .Net auf seiner Homepage als "eine offene Plattform für die Anwendungsentwicklung" [4]. Warum Du jetzt Assembler etc ins Spiel bringst, erschliesst sich mir nicht. Ist das ein Strohmannargument? Natürlich kann man auch Software entwickeln ohne Einen Hexeditor, oder Assemblercode zu schreiben. Dafür gibt es unter anderem den Compiler/Linker.

Warum allerdings ausgerechnet "Laufzeitungebung" als Sammelbegriff herhalten soll erschließt sich mir überhaupt nicht. Im Artikel selbst wird die Laufzeitumgebung als Teil von .Net verwendet. Ist .Net aber mehr als eine Laufzeitumgebung, wenn die Laufzeitumgebung ein Teil von .Net ist? Wenn du an der Bezeichnung hängst, dann sollst Du deinen Willen haben. Wäre aber schön, wenn Du das nochmal begründen würdest.

Wie wäre es mit dem Begriff "Framework", der in der de-Wikipedia ja vorhanden ist? Es wird zwar irgend jemand ankommen und mit seiner Oma argumentieren, aber da kann man wohl nichts machen. --Tinnef 21:14, 6. Apr. 2010 (CEST)

Microsoft .NET Framework 4 RC

Am 10.02.2010 ist Microsoft .NET Framework 4 Release Candidate veröffentlicht worden. http://www.microsoft.com/downloads/details.aspx?FamilyID=a9ef9a95-58d2-4e51-a4b7-bea3cc6962cb&displaylang=en --Babalu7 17:08, 5. Apr. 2010 (CEST)