Warum sollte jemand Zeit in Microsoft "Roslyn" investieren?

37

Ich habe gerade einige Whitepapers und Beispiele von Microsoft "Roslyn" gelesen und das Konzept scheint sehr interessant zu sein. Soweit ich weiß, öffnet es die Blackbox, die der Compiler ist, und bietet eine Schnittstelle, über die wir Informationen und Metriken zu in Visual Studio geschriebenem Code abrufen können.

Roslyn scheint auch die Fähigkeit zu haben, Code zu "skripten" und im laufenden Betrieb zu kompilieren / auszuführen (ähnlich dem CodeDom), aber ich habe meiner Erfahrung nach nur begrenzte Verwendungen für diese Art von Funktionalität festgestellt.

Während das Element Code Analysis & Metrics ein interessanter Bereich ist ... gibt es schon sehr lange und es gibt zahlreiche Anbieter, die bereits viel Geld in Tools für Code Analysis & Refactoring investiert haben (z. B. ReSharper, CodeRush) , nCover, etc) und sie machen einen ziemlich guten Job!

Warum sollte sich ein Unternehmen Mühe geben, etwas zu implementieren, das zu einem Bruchteil der Kosten bereitgestellt werden kann, indem eine Lizenz für eines der vorhandenen Tools erworben wird?

Vielleicht habe ich einige Schlüsselfunktionen des Roslyn-Projekts übersehen, die es außerhalb der Domäne der genannten Tools platzieren ...

.net visual-studio static-analysis

— Richard Hooper
quelle

4

Der Schwerpunkt von Roslyn liegt auf Microsoft-Praktikanten, die einen einfach erweiterbaren, verwalteten C # -Compiler erstellen. Auf diese Weise kann das Team neue Sprachfunktionen einfacher implementieren und ausprobieren. Auch die Implementierung neuer Optimierungsalgorithmen wird einfacher.

— JustAnotherUserYouMayKnowOrNot

1

Ja Penfold - Ich vermute, Sie haben ein paar Dinge übersehen. Haben Sie Dustin Campbells Interview auf Channel9 gesehen? channel9.msdn.com/Events/Ch9Live/…

— James Snell

3

Dies ist das Risiko, erfolgreiche / rentable Add-Ons für Microsoft-Produkte zu entwickeln. Möglicherweise wird dies in die nächste Version übernommen.

— JeffO

10

Sie können auch sicher sein, dass sich die Entwickler von ReSharper Gedanken über die zusätzliche Funktionalität machen, die sie einbinden können. Ja, sie haben einen C # -Parser / -Analysator geschrieben, aber die Kosten pro Feature werden erheblich sinken, wenn sie den nutzen können tatsächliche MS C # Engine.

— Binary Worrier

2

Schauen Sie sich die Skripte für eine interessante Verwendung von Roslyn an. github.com/scriptcs/scriptcs

— Ashley Davis

53

Roslyn scheint auch die Fähigkeit zu haben, Code zu "skripten" und im laufenden Betrieb zu kompilieren / auszuführen (ähnlich dem CodeDom), aber ich habe meiner Erfahrung nach nur begrenzte Verwendungen für diese Art von Funktionalität festgestellt.

On-the-Fly-Kompilierung und Ausführung ist der Hauptvorteil von Roslyn. Ich denke, Sie werden den Nutzen dieser Funktion möglicherweise unterschätzen, weil Sie in Ihrer Erfahrung noch nie auf einen Anwendungsfall gestoßen sind, bei dem sie wirklich glänzt. Und das macht Sinn; Das Erfordernis einer dynamischen Kompilierung ist wahrscheinlich eine Nischenfunktion, die jedoch einige leistungsstarke Anwendungen bietet, die ohne sie viel schwieriger wären.

Hier sind ein paar Beispiele aus dem Kopf, bei denen die dynamische Kompilierung sehr nützlich wäre. Es gibt andere Möglichkeiten, um all diese Dinge zu erreichen, aber Roslyn macht sie einfacher.

Plugin-Dateien, die zur Laufzeit geladen, kompiliert und in die Ausführung der übergeordneten Anwendung einbezogen werden.
Erstellen eines DSL, das zur Laufzeit in C # übersetzt und mit Roslyn kompiliert wird.
Erstellen einer programmiererorientierten Anwendung, die C # verwendet, analysiert, übersetzt usw.
Vergleichen von zwei Codestücken auf ihre Unterschiede nach dem Kompilieren im Gegensatz zu nur "Oberflächen" -Differenzen wie Leerzeichen. Dies ist als Semantic Diff bekannt .

Zusammenfassend lässt sich sagen, dass Sie für Roslyn möglicherweise nie eine Verwendung finden, je nachdem, für welche Software Sie Ihre Zeit mit dem Schreiben verbringen. Es gibt jedoch viele Anwendungsfälle, in denen Roslyn viel auf den Tisch bringt. Keines der von Ihnen genannten Tools bietet diese Funktion. Sie konnten sich auch nicht auf ihre Architektur und ihren Zweck stützen.

— RationalGeek
quelle

+1 für sematische Diff. Bei Interesse hier ein Link zu einem kommerziellen Produkt in der Entwicklung, das Roslyn für semantisches Diff verwendet. (Vollständige Offenlegung - Ich habe keine Verbindung zu ihnen, ich habe gerade gesehen, wie ihr Produkt auf Jon

— Skeets

@ RationalGeek - Vielen Dank für die Beispiele, ich hatte das DSL => C # -Routenbeispiel nicht in Betracht gezogen ... Ich kann mir einige Szenarien vorstellen, in denen das in Geschäftsanwendungen sehr mächtig wäre. Viele der anderen Beispiele, die ich gesehen habe (nicht nur Ihre), überschneiden sich sehr stark mit den zuvor erwähnten Refactoring-Tools. Der andere Teil meiner ursprünglichen Frage war, warum jemand das Geld in die Entwicklung von Werkzeugen investieren sollte, um diese Analyse durchzuführen, wenn es einige ausgezeichnete Werkzeuge gibt, die zu einem Bruchteil der Kosten vorgerollt wurden ... aber ich nehme an, es ist immer Platz für ein anderes (hoffentlich) besser) Werkzeugsatz! :)

— Richard Hooper

@Penfold es gibt immer Platz für neue Entwicklertools ... :-)

— RationalGeek

1

Semantic Diff dient nicht nur zu Kompilierungszwecken. Jedes Versionskontrollsystem benötigt ein diff, und die meisten verwenden ein dummes diff. Tausche einfach 2 Funktionen aus und sieh

— dir

Hier ist eine große Neukompilierung: Automatische Neukompilierung beim Schreiben von ASP.NET-Apps, ohne dass die Web-App neu erstellt und bereitgestellt werden muss. Schließlich in ASP.NET vNext angekündigt, wird es die Arbeit in C # buchstäblich wie eine Skriptsprache machen ... außer es ist sowohl typsicher als auch performant. Ich sehe dies als den Anfang dieses allgemeinen Ansatzes, der irgendwann seinen Weg in Rich-Client-Apps (Mobilgeräte, Desktops) finden wird, damit Sie Ihren Code zur Laufzeit ändern können. Mit Web-Apps ist es viel einfacher, da per Definition jede Anfrage statusfrei ist - aber mit der Zeit wird sie auch in andere App-Architekturen Eingang finden.

— Marchy

12

Ich bin sicher, dass Unternehmen, die Werkzeuge anbieten (z. B. JetBrains *), großes Interesse an Roslyn haben. Microsoft möchte die Erstellung von Tools vereinfachen, da gute Tools die Nutzung des Microsoft-Ökosystems fördern.

* Laut dem JetBrains-Blog ( dieser Eintrag ) hat JetBrians angekündigt, dass sie Roslyn nicht verwenden werden. Ich stelle mir jedoch vor, dass alle neuen Mitbewerber von JetBrains (die nicht über eine bereits vorhandene Codebasis verfügen, auf der sie arbeiten können) Roslyn verwenden werden. es gibt ihnen einen Vorsprung.

Frage 6 in 10 Fragen, 10 Antworten auf Roslyn :

6: Was sind einige der praktischen Anwendungen für Roslyn? Wie hilft es mir als Entwickler?

Eine der ersten Anwendungen, die Roslyn in den Sinn kommt, ist die Verwendung einer Business Rules Engine. Vor Roslyn umfasste die Evaluierung von Benutzermakros in der Regel die Implementierung von Visual Basic für Applikationen (VBA), das Aufrufen des DLR mit Ruby-Ausdrücken oder das Weiterleiten an den Befehlszeilencompiler mit dynamisch generiertem Visual Basic- oder C # -Code und das Abrufen des Ausführungsergebnisses dieser Code. Diese Methoden waren weniger als ideal.

Roslyn ermöglicht auf einfache Weise die dynamische Kompilierung und Ausführung von C # und (möglicherweise) Visual Basic-Code mit der Funktion Evaluate (), wie Eric Vogels Artikel "Verwenden der Roslyn Scripting API in C #" gezeigt hat. Benutzermakros, die in derselben Sprache wie die Anwendung geschrieben sind, erleichtern Entwicklern die Unterstützung von Benutzermakros, die Geschäftsregeln darstellen.

Mit Roslyn wird Code-Refactoring viel einfacher. Vor Roslyn mussten die Entwickler von Tools wie DevExpress CodeRush und Refactor Pro sowie JetBrains ReSharper einen Großteil der Compileroperationen als Grundlage für ihre Produkte neu erstellen. Mit Roslyn können Refactoring-Entwickler die vorhandenen Compiler-Funktionen direkt nutzen. Ich kann mir vorstellen, wie NuGet-Pakete aussehen, um einzelne Refactoring-Regeln zu installieren, sobald Roslyn weit verbreitet ist.

— Brian
quelle

4

"Benutzermakros, die in derselben Sprache wie die Anwendung geschrieben sind, erleichtern Entwicklern die Unterstützung von Benutzermakros, die Geschäftsregeln darstellen." - was könnte möglicherweise falsch laufen!

— gbjbaanb

9

Ich bin gespannt auf den Tag, an dem alle Compiler Compiler as a Service (CaaS) routinemäßig anbieten. Wir müssen aufhören zu denken, dass Compiler nur Pre-Linker-Code ausgeben, und anfangen zu denken, dass Compiler Bäume ausgeben, die in mehrere Ziele umgewandelt werden können. Alle Compiler sollten über eine Funktion zur Ausgabe von Bäumen und optional über JSON / XML verfügen. Die Ausgabe kann dann in viele Arten von Zielen umgewandelt werden, z. B. verschönerte gleiche Sprache, C, IL-Quelle, IL-Binärdatei, Java, Javascript, LLVM, ausführbare PIC-Datei und sogar Pre-Linker-Code.

Ich schreibe Compiler für den Lebensunterhalt. Meine Kunden werden über CaaS verkauft, weil dies die Tür zu fantastischer Flexibilität, Portabilität und Analyse öffnet.

Ich bin wirklich enttäuscht, dass Microsoft CaaS vor langer Zeit nicht implementiert hat. Beispielsweise könnte es als Migrationspfad für VB6 zu etwas anderem oder .Net zu C ++ verwendet worden sein.

— BSalita
quelle

1

Die einfache Antwort, warum MSFT in Roslyn investiert, ist, dass die vorhandene Codebasis für den C # -Compiler jetzt 5 Versionen alt ist - 11 Jahre. Es ist eine lange Zeit, bis eine Codebasis überschaubar bleibt. Da sie neu schreiben, haben sie beschlossen, in dieses Verfahren zu investieren, damit alle seine Interna als APIs verfügbar gemacht werden.

— John Tasler
quelle