Microsoft legt .Net-Quellcodes in neuer Qualität offen

Der Software-Konzern Microsoft gewährt jetzt einen noch tieferen und einfacheren Einblick in die Quellcodes seines .Net-Frameworks und macht Entwicklern das Leben damit ein Stück einfacher. mehr... Microsoft, Visual Studio, Entwicklungsumgebung, Visual Studio 2012 Bildquelle: Microsoft Quellcode, Code, Programmiersprache, Php, Source Code Quellcode, Code, Programmiersprache, Php, Source Code Free for Commercial Use / Flickr

Diese Nachricht vollständig anzeigen.

Jetzt einen Kommentar schreiben
 
wow, vorallem mit der Lizenz Anpassung. Mono hatte bisher eine strikte klausel drin: Wer den Offiziellen Code gesehen hat darf uns leider nicht helfen. Diese Anpassung wird denen einiges leichter machen
 
@Suchiman: Jau, davon wird dann wohl auch indirekt WINE profitieren.
 
@metty2410: Warum? Wine bildet .NET nicht nach, Wine bildet die Win32 API nach. Innerhalb von Wine kannst du dann Mono für Windows oder direkt .NET Framework installieren
 
@Suchiman: Ich sagte "indirekt".
Denn wenn das .Net Framework genauer in Mono nachgebildet wird, laufen auch .Net Framework Anwendungen, die unter WINE auf Mono angewiesen sind, noch ein bisschen besser.
 
@metty2410: Achso ja über die paar Ecken, klar darüber hilft es dann auch ;) Wobei wenn man schon Wine und Windows Anwendungen nutzt kann man auch gleich das Original .NET Framework in Wine installieren.
 
@Suchiman: »Wobei wenn man schon Wine und Windows Anwendungen nutzt kann man auch gleich das Original .NET Framework in Wine installieren.« Auch wenn es prinzipiell möglich ist, MS-.NET auf WINE zu installieren, so ist es doch nicht immer erlaubt: http://msdn.microsoft.com/en-us/library/ms994405.aspx
»NOTE: IF YOU DO NOT HAVE A VALID EULA FOR ANY "OS PRODUCT" (MICROSOFT WINDOWS 98, WINDOWS ME, WINDOWS NT 4.0 (DESKTOP EDITION), WINDOWS 2000 OPERATING SYSTEM, WINDOWS XP PROFESSIONAL AND/OR WINDOWS XP HOME EDITION), YOU ARE NOT AUTHORIZED TO INSTALL, COPY OR OTHERWISE USE THE OS COMPONENTS AND YOU HAVE NO RIGHTS UNDER THIS SUPPLEMENTAL EULA.«
Das ist die alte EULA. Inzwischen wird man .NET wohl auch für Windows 7 und 8.x nutzen dürfen. Aber für WINE sicherlich nicht.
 
@theuserbl: Uhh das wusste ich auch nicht. Aber heißt eine EULA haben auch das Betriebssystem zu haben ;) ? Ich meine ich kann ja diese EULA (End User License Agreement text shit) auch haben und gelesen haben ohne das OS zu haben. Zumindest für uns dürfte es dann egal sein weil eine EULA hierzulande keine Rechtmäßigkeit hat (oder heißt das, dass wir hierzulande kein .NET nutzen dürfen ;)
 
@Suchiman: natürlich haben EULAs in Europa und Deutschland ihre Rechtmäßigkeit. Was für eine fatale Behauptung....
 
@TurboV6: Okay aber nur sehr eingeschränkt, oder hat dir schonmal ein Verkäufer ne EULA hingelegt und dich um Unterschrift gebeten? http://de.wikipedia.org/wiki/Endbenutzer-Lizenzvertrag
 
@Suchiman: im Business-Bereich - vor allem Enterprise - ist dies üblich, ja.
 
Vor allem im Bezug auf Mono freut es mich. .NET/C# ist zum entwickeln spitze und wenn noch mehr davon unter Linux geht, ist es ein win-win.
 
Der Teil mit der Lic Änderung liest sich spitze.
Ich freu mich auf C#-everywhere :)

Ja klar, es geht um das Framework ned die Sprache und es heißt noch lange nicht, dass alles umgesetzt werden kann (bis auf WCF und WPF war ja fast alles eh schon vorhanden), aber es ist trotzdem ein großer Schritt in die richtige Richtung.
 
Ich schau mir den Code grad mal an, das ist echt interessant, kann ich jedem empfehlen :) Wobei ich grade merke, mir fehlt etwas und zwar der Code zu int, double, string etc. Die primitiven Datentypen fehlen leider :/
 
@Knerd:
mscorlib/system/int32, string, double, bool, char, <-- Alles vorhanden
 
@peter_86: Boolean != bool
 
@TurboV6: Doch, in C# sind das reine Aliase (siehe z.B. http://msdn.microsoft.com/en-us/library/c8f5xwh7.aspx).
 
@CFI: nein, das ist ein Kompiler-Gefallen. Sehr leicht nachzuvollziehen: ein Enum erbt von einem int; versuch mal ein Enum von Int32 erben zu lassen: funktioniert nicht. Und warum nicht? Weil es kein Alias in diesem Sinne ist, auch wenn es in der Doku so formuliert ist. Boolean ist ein Wrapper für bool und aufgrund der implizierten Operatoren verhält es sich wie ein Alias, entspricht aber eher dem Adapter Pattern.
 
@TurboV6: Ok, mit dem enum hast du einen Sonderfall gefunden, aber "int a = 1;" und "Int32 a = 1;" resultieren in EXAKT dem selben IL-Code - habe es gerade probiert und in diesem Fall verhält es sich genau wie ein Alias...
 
@CFI: ja. Grund siehe meine Beschreibung: am Compiler kommt immer das Schlüsselwort raus.
 
@CFI: Probier das ganze mit Int64 und long und sag mir dann ob long oder Int64 raus kommt ;-) Wie können das so weiter machen mit allen "Hilfs-Structs", die .NET so zu bieten hat. Aber am Ende kann das Betriebssystem eben nur mit den primitiven Datentypen arbeiten, die es kennt: und das sind eben kein Int32 sondern int bzw. kein Int64 sondern ein long.
 
@CFI: anderes Beispiel: verwende mal den BigInteger. In C# ein gültiger "Typ" / struct, wie Boolean, Double oder Int32. Schau Dir den resultierenden Code an: nichts anderes als in int, der masktiert wird, um int.MaxValue zu übersteigen ;-)
Deswegen nennt man .NET auch Managed.
 
@TurboV6: Das meine ich eigentlich ja :D. Wie du sagst ist nach dem Compiler immer das Schlüsselwort (int, bool, byte,...) "da" und nicht mehr das Struct (Int32, Boolean, Byte,...). Warum es beim enum nicht geht, weiß ich aber nicht - müsste dort doch genau gleich zu ersetzen gehen...

Ich persönlich verwende für Variablen immer die Schlüsselwörter und für "Funktionsaufrufe" (z.B. "String.Format(...);") die Structs, da es dann farblich gut zu unterscheiden ist...
 
@CFI: na beim Enum gehts nicht, weil Int32 kein echter Alias ist. Ein echter Alias wäre dem Compiler bekannt; Int32 ist aber einfach eine Adapter-Pattern-Implementierung mit implizierten Operatoren. Deswegen funktioniert das so wie es eben aktuell ist. Das ist der vorteil der implizierten Konvertierung. Befass Dich mal damit, dann verstehst Dus.
 
@Knerd: ... weil das auch keine Klassen im Managed-Sinn sind. C# wrappt die nur aus dem Windows System (das sind aber C# Grundlagen mein Lieber).
 
@TurboV6: Das weiß ich, allerdings finde ich den Part mit dem Wrapping nicht. Oder ich bin zu doof :D
 
@Knerd: na im Prinzip ist das die Klasse Boolean (struct). private bool m_value; - "Boolean" ist ein Element des Frameworks. "bool" hingegen ein Schlüsselwort für den Compiler. Sprich: alles was am Compiler ankommt ist nachher "bool" und nicht "Boolean". Deswegen returnt Equals ( das von object erbt und von Boolean überschrieben wird) auch bool und nicht Boolean.
 
@TurboV6: Jetzt hab ich meinen Denkfehler gefunden, danke dir. Ich hab grad Framework und Compiler durcheinander geworfen :D
 
Direkt mal schauen ob und wie man die sources im Debugger verwenden kann! Aber ist das der gesammte Code? 50 MB kommt mir etwas wenig vor.
 
@happy_dogshit: 50 MB Textdateien ist jetzt nicht unbedingt wenig.... aber ja, nicht alle Bereiche von .NET stehen unter einer offenen Lizenz (allowed to read, denied to copy) oder Open Source (MSPL). Und i.d.R. kannste das Zeug nicht 1:1 im Debugger verwenden, dafür gibts DebugSymbols.
 
@happy_dogshit: Hier ist erläutert wie du diese Funktionalität in Visual Studio aktivierst: http://referencesource-beta.microsoft.com/setup.html
 
Haben wir der Konkurrenz auf dem is markt zu verdanken nehm ich an.
 
@-adrian-: Der Code ist schon seit Jahren öffentlich einsehbar, das sieht man der alten Seite auch an: http://referencesource.microsoft.com/ Allerdings war der Code immer ein wenig veraltet der da einzusehen war und stimmte häufig nach Patches nicht mehr ganz überein. Das hat einerseits in Visual Studio die Funktionalität gestört den ".NET Framework Code zu durchlaufen" und war auch nicht gerade sehr dienlich dazu am Source nachgucken zu können warum sich das eigene Programm plötzlich verändert verhält weil der Code zu dem Zeitpunkt noch nicht aktualisiert verfügbar war. Mit der neuen Webseite und aktualisiertem Code will man das nachbessern, das ging auf ein Visual Studio User Voice zurück, wie du aus dem verlinkten MSDN Artikel rauslesen kannst.
 
»Um die Arbeit mit dem Quellcode noch einfacher zu machen, hat Microsoft auch die Lizenzbestimmungen klarer gefasst.« Was wurde denn genau verändert? Wie sah die Lizenz vorher aus? Was wurde hinzugefügt, was entfernt?
 
Es scheint, daß die Mono-Entwickler nicht wissen, inwieweit ihnen die Änderung der Lizenzbestimmungen weiterhelfen könnte.
Bisher hat man herausgefunden, daß sich dieser WinFuture-Artikel auf diesen Blog-Eintrag bezieht: http://www.hanselman.com/blog/AnnouncingTheNewRoslynpoweredNETFrameworkReferenceSource.aspx
Derzeit letzter Beitrag im Mono-Forum zu diesem Thema: http://lists.ximian.com/pipermail/mono-devel-list/2014-February/041198.html
Kommentar abgeben Netiquette beachten!

Video-Empfehlungen

WinFuture Mobil

WinFuture.mbo QR-Code Auch Unterwegs bestens informiert!
Nachrichten und Kommentare auf
dem Smartphone lesen.

Folgt uns auf Twitter

WinFuture bei Twitter

Interessante Artikel & Testberichte

WinFuture wird gehostet von Artfiles