L'avantage le plus évident de ce type de compilateur "déconstruit" est qu'il permet à l'ensemble du processus de compilation-exécution d'être appelé à partir des applications .Net. Hejlsberg a présenté un programme C # qui transmettait quelques extraits de code au compilateur C # sous forme de chaînes; le compilateur a renvoyé le code d'assembly IL résultant en tant qu'objet, qui a ensuite été transmis au Common Language Runtime (CLR) pour exécution. Voilà! Avec Roslyn, C # acquiert la capacité d'un langage dynamique à générer et appeler du code au moment de l'exécution.
J'ai pu le faire depuis la sortie de .NET 4 avec CSharpCodeProvider.CompileAssemblyFromSource lequel j'utilise en fait dans un projet ASP.Net écrit il y a quelque temps qui fait exactement cela - permet à un utilisateur de taper du code dans une zone de texte, de choisir des assemblys / espaces de noms pour référencer, puis exécutez et affichez la sortie de ce code à la volée pour les tests de code d'environnement en direct sur Windows Azure.
Fait CodeDompartie de / un précurseur de Roslyn? Quel est l'avantage spécial de Roslyn CodeDom?
Clause de non - responsabilité : je travaille pour Microsoft dans l'équipe Roslyn.
CodeDom est un précurseur de Roslyn, mais n'est que marginalement lié. Essentiellement, CodeDom est un moyen simple et (quelque peu) indépendant du langage de générer du code qui a été ajouté dans .NET 1.0 pour prendre en charge les concepteurs (à la WinForms). Étant donné que CodeDom était une tentative de fournir un modèle unifié capable de générer du code en C #, VB et d'autres langages, il manque de haute fidélité avec l'un des langages qu'il prend en charge (c'est pourquoi vous ne pouvez pas créer une instruction switch avec CodeDom). CSharpCodeProvider.CompileAssemblyFromSource est simplement un wrapper autour de l'exécution de csc.exe.
Roslyn est un animal complètement différent. Il s'agit d'une réécriture des compilateurs C # et VB à partir de zéro en utilisant du code managé - C # en C # et VB en VB (les versions de csc.exe et vbc.exe qui sont livrées aujourd'hui sont écrites en code natif). L'avantage de les créer en code managé est que les utilisateurs peuvent référencer les vrais compilateurs en tant que bibliothèques à partir d'applications .NET (aucun wrapper n'est nécessaire).
Lors de la création de chaque composant du pipeline du compilateur, nous avons exposé les API publiques en haut:
Analyseur -> API de l'arborescence de syntaxe
Importation de table de symboles / de métadonnées -> API de symbole
Binder -> API de liaison et d'analyse de flux
Émetteur IL -> Émettre l'API
Roslyn peut être utilisé comme un générateur de code source sophistiqué C # et VB, mais c'est là que s'arrête la similitude avec CodeDom. Les API Roslyn Compiler peuvent être utilisées pour analyser le code, effectuer une analyse sémantique, compiler et évaluer le code de manière dynamique, etc.
En plus des compilateurs, l'équipe Roslyn reconstruit également les fonctionnalités de Visual Studio C # et VB IDE en plus des API du compilateur public. Ainsi, les API du compilateur sont suffisamment riches pour créer les outils de conception de Visual Studio, tels que IntelliSense et le refactoring de la méthode d'extraction. De plus, au niveau des couches au-dessus du compilateur, Roslyn propose des services d'analyse ou de transformation de données de plus haut niveau. Par exemple, il existe des services de mise en forme du code à l'aide des règles de mise en forme C # et VB, ou de recherche de toutes les références à un symbole particulier dans une solution.
Vraiment, il n'y a pas qu'un seul avantage spécial de Roslyn par rapport à CodeDom. Là où CodeDom répondait à un besoin de génération de code très spécifique, Roslyn s'attaque à tout l'espace d'outillage de langage en fournissant un cadre pour vous permettre de créer à peu près n'importe quel type d'outil de langage C # ou VB auquel vous pouvez penser.
@Dustin: Roslyn prendra-t-elle en charge d'autres langues? JavaScript (.NET), par exemple?
Diego Barros
@Dustin: C'est parfait pour créer une expérience IDE complète qui peut renforcer la qualité du code dans mon organisation, même si je ne vois pas de remplacement complet de la révision manuelle du code, mais je constate une augmentation considérable de la qualité. Bientôt!
Jerric Lyns John
Ce serait génial si quelqu'un avait déjà créé un outil basé sur Roslyn pour convertir du code qui utilise CodeDom en code qui utilise SyntaxFactory de Roslyn ... (En partie parce que .Net Core a Roslyn mais pas de CodeDom et que j'utilise une bibliothèque construite autour de CodeDom )
Emyr
43
CodeDom vous permet de compiler - mais il ne vous donne pas la possibilité d'obtenir vraiment des informations sur le code lui-même (autres que les erreurs du compilateur). Fondamentalement, c'est une boîte noire où vous dites "compilez ceci" et vous dites "j'ai réussi" ou "j'ai échoué, voici quelques erreurs".
Roslyn vous permet d'inspecter complètement et de créer le code à la volée. Cela inclut des choses comme pouvoir voir / inspecter les commentaires dans un morceau de code source, des informations détaillées sur la structure complète, etc. ou des transformations là-dessus.
Compte tenu des informations de syntaxe complètes et riches, vous disposez d'une énorme quantité de contrôle et de flexibilité supplémentaires. C'est ainsi que, par exemple, l'exemple fonctionne qui copie un bloc de code C # et le colle en tant que code VB.NET. Avec Roslyn, vous pouvez faire plus que simplement compiler - vous pouvez également manipuler le code proprement. Cela devrait rendre de nombreux outils beaucoup plus simples à générer, car des choses comme les refactorisations peuvent être effectuées très simplement car les outils comprennent la syntaxe complète, y compris les méta-informations (comme les commentaires), et peuvent simplement travailler avec elles directement.
Une grande différence que je vois: avec CodeDom, chaque fois que vous compilez du C # ou VB.NET, cela se produit hors du processus. CSC.exe ou VBC.exe sont les vrais ouvriers derrière la scène.
Si vous souhaitez construire un service, en termes d'architecture, d'évolutivité, d'isolation, etc. (vous évoquez Azure), ce n'est pas très bon.
Avec Roslyn, c'est en cours.
Je suppose que c'est l'une des raisons pour lesquelles ils l'appellent "Compiler as a service".
En outre, CodeDom est une API relativement pauvre, manque de nombreuses fonctionnalités et n'est pas vraiment à jour, car elle a été conçue principalement pour prendre en charge la génération automatique de code des concepteurs d'interface utilisateur Visual Studio. Je pense que Roslyn fera beaucoup mieux car c'est écrit par les gars qui écrivent les compilateurs. J'espère que cela fera la différence.
PS: Une différence notable entre CSC.exe et VBC.exe: Roslyn semble être pur .NET (et utilise CCI ).
Roslyn permet un contrôle beaucoup plus fin de l'ensemble du processus - par exemple, vous pouvez analyser la chaîne et même générer du code supplémentaire (à la volée dans le processus de compilation basé sur l'analyse), etc.
CodeDom "utilise simplement le compilateur" tandis que Roslyn est "un compilateur en tant que service avec un accès complet aux (sous-) parties" ... avec Roslyn, vous êtes "à l'intérieur du compilateur" et pouvez voir à quoi ressemble le code du point de vue du compilateur vous permettant de changer les choses d'une manière actuellement impossible.
Par exemple, vous pouvez utiliser Roslyn pour étendre C # - quelque chose de très pratique et bien meilleur que l'état actuel de l'implémentation AOP.
Pour une vue d'ensemble de l'état actuel de Roslyn et des différents niveaux d'accès et de contrôle qu'il fournit, voir http://msdn.microsoft.com/en-us/hh500769
METTRE À JOUR
Microsoft vient de mettre à disposition un nouveau CTP avec des fonctionnalités supplémentaires et de nombreux changements / ajouts d'API. Pour plus de détails, cliquez ici .
En fait, il n'est pas vrai que vous puissiez utiliser Roslyn pour étendre C # avec des mots clés supplémentaires.
Dustin Campbell
merci ... corrigé ... bien que pas dans la première version je suis jolie que cela sera possible ...
Yahia
2
@DustinCampbell, que faire si vous gérez une erreur de compilation que le pseudo mot-clé a causée en générant du code?
Rodrick Chapman
3
Vous auriez besoin de faire une réécriture avant de la transmettre au compilateur. Tout d'abord, analysez le code avec vos mots-clés spéciaux. Le code analysera et, à moins que l'analyseur ne puisse en faire des queues ou des queues, les mots-clés non valides apparaîtront comme SkippedTokenTrivia dans l'arborescence résultante. Ensuite, détectez les mots-clés ignorés et réécrivez l'arbre avec un code valide (par exemple, tissage AOP). Enfin, transmettez la nouvelle arborescence au compilateur. C'est certainement un hack, et il n'est pas garanti de fonctionner avec les futures versions de Roslyn. Par exemple, l'analyseur pourrait ne pas produire le même arbre pour le code cassé dans les versions futures.
Dustin Campbell
@DustinCampbell: mais y aura-t-il quelque chose permettant le tissage AOP en finale de Roslyn? Mon tissage Mono.Cecil INPC fonctionne très bien tel quel, mais si je pouvais écrire, public notifying string Name {get;set;}ce serait encore plus génial
CodeDom vous permet de compiler - mais il ne vous donne pas la possibilité d'obtenir vraiment des informations sur le code lui-même (autres que les erreurs du compilateur). Fondamentalement, c'est une boîte noire où vous dites "compilez ceci" et vous dites "j'ai réussi" ou "j'ai échoué, voici quelques erreurs".
Roslyn vous permet d'inspecter complètement et de créer le code à la volée. Cela inclut des choses comme pouvoir voir / inspecter les commentaires dans un morceau de code source, des informations détaillées sur la structure complète, etc. ou des transformations là-dessus.
Compte tenu des informations de syntaxe complètes et riches, vous disposez d'une énorme quantité de contrôle et de flexibilité supplémentaires. C'est ainsi que, par exemple, l'exemple fonctionne qui copie un bloc de code C # et le colle en tant que code VB.NET. Avec Roslyn, vous pouvez faire plus que simplement compiler - vous pouvez également manipuler le code proprement. Cela devrait rendre de nombreux outils beaucoup plus simples à générer, car des choses comme les refactorisations peuvent être effectuées très simplement car les outils comprennent la syntaxe complète, y compris les méta-informations (comme les commentaires), et peuvent simplement travailler avec elles directement.
la source
Une grande différence que je vois: avec CodeDom, chaque fois que vous compilez du C # ou VB.NET, cela se produit hors du processus. CSC.exe ou VBC.exe sont les vrais ouvriers derrière la scène.
Si vous souhaitez construire un service, en termes d'architecture, d'évolutivité, d'isolation, etc. (vous évoquez Azure), ce n'est pas très bon.
Avec Roslyn, c'est en cours.
Je suppose que c'est l'une des raisons pour lesquelles ils l'appellent "Compiler as a service".
En outre, CodeDom est une API relativement pauvre, manque de nombreuses fonctionnalités et n'est pas vraiment à jour, car elle a été conçue principalement pour prendre en charge la génération automatique de code des concepteurs d'interface utilisateur Visual Studio. Je pense que Roslyn fera beaucoup mieux car c'est écrit par les gars qui écrivent les compilateurs. J'espère que cela fera la différence.
PS: Une différence notable entre CSC.exe et VBC.exe: Roslyn semble être pur .NET (et utilise CCI ).
la source
Roslyn permet un contrôle beaucoup plus fin de l'ensemble du processus - par exemple, vous pouvez analyser la chaîne et même générer du code supplémentaire (à la volée dans le processus de compilation basé sur l'analyse), etc.
CodeDom "utilise simplement le compilateur" tandis que Roslyn est "un compilateur en tant que service avec un accès complet aux (sous-) parties" ... avec Roslyn, vous êtes "à l'intérieur du compilateur" et pouvez voir à quoi ressemble le code du point de vue du compilateur vous permettant de changer les choses d'une manière actuellement impossible.
Par exemple, vous pouvez utiliser Roslyn pour étendre C # - quelque chose de très pratique et bien meilleur que l'état actuel de l'implémentation AOP.
Pour une vue d'ensemble de l'état actuel de Roslyn et des différents niveaux d'accès et de contrôle qu'il fournit, voir http://msdn.microsoft.com/en-us/hh500769
METTRE À JOUR
Microsoft vient de mettre à disposition un nouveau CTP avec des fonctionnalités supplémentaires et de nombreux changements / ajouts d'API. Pour plus de détails, cliquez ici .
la source
public notifying string Name {get;set;}ce serait encore plus génial