XmlnsDefinition pour les espaces de noms récursifs

Question

j'ai un projet qui est structuré avec un espace de noms .NET ViewParts. Cela, d'autre part, se compose de nombreux sous-dossiers différents avec wpf usercontrols en eux.

J'ai ajouté un attribut XmlnsDefinition à mon fichier AssemblyInfo.cs pour mapper cet espace de noms .net à un uri pour l'utiliser dans d'autres fichiers window/usercontrol. Mais j'aimerais vraiment que l'attribut fonctionne en mode "récursif". C'est-à-dire: je veux qu'il inclue tous les sous-dossiers sous l'espace de noms .net que je spécifie. Sinon, je vais devoir aller dans le fichier AssemblyInfo.cs et ajouter une ligne chaque fois que j'ajoute un nouveau viewpart/usercontrol et c'est juste un autre pas-qui-sera-oublié-oublié ...

Est-ce possible de quelque manière que ce soit?

Answer 1

Tout est possible.

Dans ce cas, cependant, il est pas particulièrement facile. Les attributs XmlnsDefinition sont lus directement par l'analyseur XAML et n'ont pas de fonction d'espace de noms récursif. À moins que vous n'ayez réellement les attributs XmlnsDefinition sur votre assembly, l'analyseur XAML ne les ajoutera pas à sa table et vous n'obtiendrez pas les mappages souhaités.

Modification de l'analyseur XAML est pas une bonne idée parce que les entrailles que vous aurez besoin de muck avec sont susceptibles de changer. Heureusement, l'ajout automatique de XmlnsDefinitions n'est pas si difficile.

Je vais vous donner trois façons de modifier votre processus de construction pour automatiser cela. Dans chaque cas, vous commencerez par déplacer vos attributs XmlnsDefinition que vous voulez récursifs sur AssemblyInfo.cs et dans un autre fichier qui est réécrit par votre étape de construction. C'est possible parce que les attributs [assembly:] peuvent être trouvés dans n'importe quel fichier. Peu importe où ils se trouvent, le compilateur C# les ajoute au même endroit dans l'assemblage résultant.

Maintenant que votre fichier est un séparé, voici les trois approches pour reconstruire automatiquement chaque fois que vous appuyez sur F5 ou Ctrl-Shift-B ou tout autre:

1. Ajouter un événement post-construction qui charge le fichier .dll, utilise la réflexion pour énumérer les types et crée une liste d'espaces de noms avec le préfixe souhaité. Ecrivez ceci dans votre fichier "XmlnsDefinitions.cs" (il doit également supprimer le bit en lecture seule) afin que la prochaine fois que vous le compilez aura les bonnes définitions. Inconvénients: une mauvaise interaction avec le contrôle source & doit compiler deux fois pour obtenir une sortie correcte.

2. Ajouter une tâche de construction (référence Microsoft.Build.Framework et sous-classe Microsoft.Build.Framework.Task) qui construit le fichier « XmlDefinitions.cs » en tant que fichier généré par l'analyse syntaxique du code source. Incluez un appel à cette tâche dans votre fichier .csproj (ou dans un fichier .targets distinct inclus dans votre fichier .csproj). Inconvénients: Plus de travail que le n ° 1, l'écriture de l'analyseur source pour les espaces de noms compliquée par la possibilité d'espaces de noms imbriqués.

3. Ajoutez une tâche de génération qui construit le fichier "XmlnsDefinitions.cs" en réfléchissant sur la sortie .dll. Ajoutez ensuite un fichier .targets personnalisé qui compile votre application sans XmlnsDefinitions.cs, puis génère XmlnsDefintions.cs, puis compile à nouveau. Inconvénients: Processus de construction complexe, modifications msbuild complexes, affichage en raison de la compilation deux fois.