Moin,

natürlich ist da nichts unsicherer. Wenn etwas sicher ist, dann darf das OpenSource sein, denn dann ist es so oder so unknackbar. Ein Grund warum z. B. bei Verschlüsselungen auch die Algorithmen bekannt sein dürfen, denn diese muss auch sicher sein, wenn man weiß, wie es funktioniert. Also mache Dir da keine Sorgen.
Solange Du Deine Anwendung sicher programmierst, also keine Passwörter in den Code schreibst und sowas, passiert da gar nichts. Das .NET-Framework hat damit nichts zu tun, egal ob Open- oder ClosedSource

Das macht Microsoft auch nur, weil es einem Entwickler hilft, etwas in den Code zu spitzeln, wie sich manches verhält usw. Auch können Sie so besser kooperieren, um das .NET-Framework zu verbessern und auszuweiten.

Grüße

Ich denke dadurch das es Open Source wird an enorme Vorteile. Java sollte so irgendwann vom Platz vertrieben werden weil so auch Crossplattforming bald möglich sein wird und dadurch Java nur noch Nachteile im Vergleich zu .NET hat.

​Was ist mit der Sicherheit meiner Software und die das Frameworks allgemein ist diese dann angreifbarer

Den Code des .Net Frameworks kann man sich schon seit einer Ewigkeit angucken, nur verändern durfte man den Code nur für private Zwecke, was jetzt aufgehoben wurde.

Anbei: Bestimmte Teile des .NET Frameworks werden höchstwahrscheinlich weiterhin Closed-Source bleiben: Manche Codes hat Microsoft von Intel und anderen Unternehmen für viel Geld gekauft und wird diese kaum veröffentlichen (dürfen).

Dazu würde ich gerne mal ne Quelle sehen @nafets

MS hat selbst gesagt, dass das nicht bedeutet, dass sie mit der Weiterentwicklung des .Nets aufhören. Ganz im Gegenteil, privat Leute dürfen jetzt Vorschläge machen, aber diese Vorschläge werden von MS Mitarbeitern unter die Lupe genommen und evlt. übernommen.
Dadurch dass das .Net OpenSource wird, wird es vmlt. nicht nur schneller und sicherer werden, sondern auch noch Plattformunabhängig, denn die Entwickler von Mono konnten sich den Code von .Net auch bereits teilweise angucken, sie durften diesen aber nicht nachmachen, sie mussten nur angucken, wie etwas funktioniert und die Funktionalität nachahmen->Nicht alles genau gleich und vorallem Zeitintensiver.

Ich glaube kaum, dass es bedeutet, dass das .Net somit aufgegeben wird, ganz im Gegenteil ist das ein riesenschritt, der dem .Net hfftl. früher oder später die Vorherrschaft überlassen wird.

@SeriTools
Habe zwar keine direkte Aussage von Microsoft, aber Hans Passant erzählt normalerweise keinen Schrott:
stackoverflow.com/a/8870593/3742982

Hans Passant schrieb:

Microsoft purchased that code from Intel.

Ich hatte es aber anscheinend falsch in Erinnerung, so wie es aussieht, scheint dieser Code doch in irgendeiner Weise verfügbar zu sein :S

Edit: Oder doch net? Hab mir grad mal den Source von der CLI gezogen - finden kann ich zum Beispiel die ganzen Math-Funktionen nicht. Die meisten Funktionen leiten nur auf eine interne Implementation weiter, Beispiel:

@nafets ergibt fast Sinn, wenn man sowas nach außen auslagert sind ja relativ aufwendig

@jvbsl
Wenn es nur fast Sinn ergibt, wo liege ich dann falsch? Ich habe mich auch mal etwas weiter ins Framework gegraben, weiter als hierhin bin ich aber leider auch net gekommen:

Ich kann zwar kein C++, das sieht für mich aber so aus, als würde diese Methode erstmal prüfen, ob das Ergebnis sowieso schon klar ist und dann den Aufruf an eine weitere interne Funktion weiterleiten...

@nafets es ist logisch, dass man solche Funktionen in CPP oder gar ASM ebene macht, gut möglich, dass das auf ne ASM Funktion zurückführt

@jvbsl
Von welcher ich kaum glaube, dass sie öffentlich verfügbar ist/sein wird (es war schon schwer genug, an den C++-Code dranzukommen) => nicht 100% Open Source.

Die Wertetypen Byte, Int16, Int32, Int64 (inklusive der Unsigned-Versionen), Single, Double und Decimal sowie die Klassen String und Type liegen nicht im Il-Code ausprogrammiert vor. Das hat einfach den Grund, dass diese Typen auf dem Prozessor optimiert sind und/oder Teil der Runtime selber sind, was in IL so nicht funktioniert.

Vorallem was interessiert dich, wie diese Implementiert wurden? Verbessern kann man daran wohl kaum was und was diese Funktionen machen ist ja genau bekannt. Es hindert niemanden daran das auf andere Plattformen zu konvertieren, da auf ASM Ebene die Optimierungen pro Architektur eh dieselben sind.

Hoffen wir doch alle mal, dass WPF auf OpenGL portiert wird und man dann auch WPF plattformunabhängig benutzen kann. Dann brauche ich kein Angular+Typescript+node-webkit mehr.
Außerdem ist das, was mono aus einer Winforms-GUI macht unter den Linux-Systemen meist suboptimal und sieht garnicht toll aus. Das wäre bei WPF anders (Theming und so).

Übrigens haben sie vor, mit Mono zu mergen:
twitter.com/shanselman/status/532558786486370304

Der String ist übrigens ganz interessant implementiert: referencesource.microsoft.com/…tring.cs,8281103e6f23cb5c