Perché qualcuno dovrebbe investire tempo in Microsoft "Roslyn"?

Roslyn also appears to have the ability to "script" code and compile/execute it on the fly (similar to the CodeDom) but I have only come across limited uses for that type of functionality in my experience.

La compilazione e l'esecuzione al volo rappresentano il vantaggio chiave di Roslyn. Penso che potresti sottovalutare il vantaggio di questa funzione perché non hai mai trovato un caso d'uso nella tua esperienza in cui brilla davvero. E questo ha senso; la necessità di una compilazione dinamica è probabilmente una caratteristica di nicchia, ma avere a disposizione alcune potenti applicazioni che sarebbero molto più difficili senza di essa.

Ecco alcuni esempi in cui la compilazione dinamica sarebbe abbastanza utile. Ci sono altri modi per realizzare tutte queste cose, ma Roslyn le rende più facili.

• Avere i file plugin caricati in fase di runtime, compilati e inclusi nell'esecuzione dell'applicazione "madre".
• Creazione di un DSL che viene poi tradotto in C # in fase di runtime e compilato utilizzando Roslyn.
• Creazione di un'applicazione orientata al programmatore che prende C #, la analizza, la traduce, ecc.
• Confronto di due blocchi di codice per le loro differenze dopo la compilazione, al contrario delle differenze di "superficie" come gli spazi bianchi. Questo è noto come Diffusione semantica .

Quindi, per riassumere, tu potresti non trovare mai un uso per Roslyn, a seconda del software che usi per scrivere. Tuttavia, ci sono molti casi di utilizzo in cui Roslyn porta molto in tavola. Nessuno degli strumenti menzionati fornisce questa funzionalità. Né potevano basarsi sulla loro architettura e sui loro scopi.

Sono sicuro che le aziende che forniscono strumenti (ad es. JetBrains *) sono molto interessate a Roslyn. Microsoft vuole semplificare la creazione di strumenti, poiché una buona strumentazione incoraggia l'utilizzo dell'ecosistema di Microsoft.

* Per il blog JetBrains ( questa voce ), JetBrians ha annunciato che non useranno Roslyn. Tuttavia, immagino che qualsiasi nuovo concorrente di JetBrains (che non ha una base di codice preesistente a cui lavorare) utilizzi Roslyn; dà loro un vantaggio.

Domanda 6 in 10 domande, 10 risposte su Roslyn :

6: What are some of the practical uses for Roslyn? How will it help me as a developer?

One of the first uses of Roslyn that comes to mind is that of a business rules engine. Prior to Roslyn, evaluating user macros typically involved implementing Visual Basic for Applications (VBA), calling out to the DLR with Ruby expressions, or shelling out to the command-line compiler with dynamically generated Visual Basic or C# code and obtaining the result of running that code. These methods were less than ideal.

Roslyn will easily allow dynamic compilation and execution of C# and (eventually) Visual Basic code with the Evaluate() function, as demonstrated Eric Vogel's article "Using The Roslyn Scripting API in C#". User macros written in the same language as the application will make it easier for developers to support user macros representing business rules.

Code refactoring becomes much easier with Roslyn. Prior to Roslyn, the developers of such tools as DevExpress CodeRush and Refactor Pro and JetBrains ReSharper had to recreate much of the compiler operations as a foundation for their products. With Roslyn, refactoring developers can directly take advantage of the existing compiler capabilities. I can imagine the appearance of NuGet packages to install individual refactoring rules once Roslyn is widely available.

Attendo con impazienza il giorno in cui tutti i compilatori ordinariamente offrono Compiler as a Service (CaaS). Dobbiamo smettere di pensare che i compilatori emettano solo codice pre-linker e inizi a pensare che i compilatori emettano alberi che possono essere trasformati in più obiettivi. Tutti i compilatori dovrebbero avere una funzione per emettere alberi e facoltativamente JSON / XML. L'output può quindi essere trasformato in molti tipi di obiettivi, come ad esempio abbellito linguaggio stesso, sorgente C, IL, binario IL, Java, Javascript, LLVM, eseguibile PIC e persino codice pre-linker.

Scrivo compilatori per vivere. I miei clienti sono venduti su CaaS perché apre le porte a una fantastica flessibilità, portabilità e analisi.

Sono davvero deluso dal fatto che Microsoft non abbia implementato CaaS molto tempo fa. Ad esempio, potrebbe essere stato utilizzato come percorso di migrazione per VB6 a qualcos'altro, o da .Net a C ++.

La semplice risposta al motivo per cui MSFT sta investendo in Roslyn è che il loro codebase esistente per il compilatore C # è ora di 5 versioni vecchio - 11 anni. Questo è un tempo lungo per cui qualsiasi base di codice rimane gestibile. Inoltre, poiché stanno riscrivendo, hanno deciso di investire nel farlo in modo che tutti i suoi interni siano esposti come API.