Génération de code C #

Je cherche à créer un petit générateur de classe pour un projet. J’ai lu sur CodeDOM que la sémantique de la création des classes ne semble pas poser de problème, mais je ne sais pas comment intégrer au mieux la génération dans le processus de développement et de déploiement.

Comment dois-je déclencher la création des classes? J’ai lu que cela devrait faire partie du processus de construction, comment dois-je faire cela?
Où les classes devraient-elles être créées? J’ai lu que les fichiers ne devraient pas être édités à la main, et jamais archivés dans le contrôle de source. Devrais-je même m’inquiéter à ce sujet et simplement générer les classes dans le même répertoire que le moteur du générateur?

Les réponses à votre question dépendent en partie du but de vos classes générées.

Si les classes sont générées dans le cadre du développement , elles doivent être générées sous forme de fichiers texte et archivées dans votre GDS, comme toute autre classe.

Si vos classes sont générées dynamicment au moment de l’ exécution dans le cadre du fonctionnement de votre système, je n’utiliserais pas du tout CodeDOM. J’utiliserais la reflection.

Jetez un coup d’œil aux modèles T4 (intégrés à VS2008). Il vous permet de créer des classes “modèles” qui génèrent du code pour vous. Oleg Sych est une ressource inestimable pour cela.

Lien vers le tutoriel d’Oleg sur la génération de code .

Je connais la présence de modèles T4 (et je sais que de nombreuses personnes les utilisent), mais je ne les ai pas utilisés moi-même. En plus de ceux-ci, vous avez deux options principales:

Utilisez un SingleFileGenerator pour transformer la source directement dans le projet. Chaque fois que vous enregistrez le document que vous avez modifié, le fichier de code est automatiquement régénéré. Si vous utilisez le contrôle de source, le fichier généré sera archivé dans le cadre du projet. Il y a quelques limitations à cela:
- Vous ne pouvez générer qu’une sortie pour chaque entrée.
- Étant donné que vous ne pouvez pas contrôler l’ordre dans lequel les fichiers sont générés, et que les fichiers ne sont pas générés au moment de la construction, votre sortie ne peut être efficacement dérivée que d’un seul fichier d’entrée.
- Le générateur de fichier unique doit être installé sur la machine du développeur s’il envisage de modifier le fichier d’entrée . Comme le code généré se trouve dans le contrôle de source, s’ils ne modifient pas l’entrée, ils n’auront pas besoin de régénérer la sortie.
- Étant donné que la sortie est générée uniquement lorsque l’entrée est sauvegardée, la sortie ne devrait dépendre d’aucun autre état que le contenu exact du fichier d’entrée (même l’horloge système).
Générez du code dans le cadre de la construction. Pour cela, vous écrivez un fichier de cibles MSBuild. Pour cela, vous avez le contrôle total des entrées et des sorties, vous permettant ainsi de gérer les dépendances. L’état du système peut être traité comme une dépendance d’entrée lorsque cela est nécessaire, mais n’oubliez pas que toute génération nécessitant une génération de code prend plus de temps qu’une génération utilisant un résultat généré précédemment. Les résultats (fichiers sources générés) sont généralement placés dans le répertoire obj et ajoutés à la liste des entrées allant à csc (le compilateur C #). Limites de cette méthode:
- Il est plus difficile d’écrire un fichier de cibles qu’un SingleFileGenerator.
- La construction dépend de la génération de la sortie, que l’utilisateur modifie ou non l’entrée.
- Comme le code généré ne fait pas partie du projet, il est un peu plus difficile de visualiser le code généré pour des tâches telles que la définition de points d’arrêt.