étendre le processus de compilation de BAML pour enregistrer les erreurs supplémentaires
J'ai rencontré ce même problème l'année dernière. J'écrivais ma propre extension pour laquelle je voulais des erreurs de compilation dans certains scenari et j'ai découvert que lancer une exception de ProvideValue ne fonctionnait pas car ProvideValue n'est pas appelée tant que le XAML n'est pas chargé et que l'arbre d'objets est créé.
J'ai fait quelques expériences et découvert que le message d'erreur du compilateur pour x:Static est un sous-produit d'une optimisation effectuée par le compilateur BAML. Le format BAML a en fait un concept de membre spécifique d'un type spécifique, donc quand le XAML contient x:Static le compilateur le remplace réellement par un enregistrement spécial qui référence directement le membre plutôt que de contenir le type et le nom de la méthode. Il le fait en reconnaissant explicitement la classe StaticExtension. TypeExtension a une optimisation similaire.
J'ai cherché des hooks qui me permettraient d'avoir mon propre code appelé pendant la compilation BAML, mais je n'en ai pas trouvé. La compilation BAML est principalement juste une translittération droite dans un format binaire qui correspond au XAML, avec quelques optimisations spécifiques mais ignorant la plupart du temps ce qu'elle voit.
J'ai fini par ajouter une étape supplémentaire au processus de construction, modélisant mon code de Microsoft.WinFX.targets et les autres fichiers cibles intégrés. Cette étape analyse le code XAML pour mon extension de balisage, vérifie les paramètres et génère une erreur de compilation s'ils ne sont pas corrects. Ceci est fait complètement indépendamment de la traduction en BAML. Il a fallu quelques jours de travail supplémentaires pour mettre en œuvre tout cela en fin de compte, mais j'ai beaucoup appris.
caveat à créer votre propre fichier .targets
Si vous envisagez d'ajouter votre propre fichier .targets, vous devez savoir que si vous incluez la cible dans la clé de Registre de la machine locale de SafeImports, à la fois Visual Studio et Expression Blend se plaindront de tout projet incluant votre fichier .targets. Cette clé nécessite un accès administrateur sur la machine pour la mise à jour. Cela peut ou peut ne pas être un problème selon votre scénario de déploiement. (Par exemple, une installation MSI à l'échelle de l'ordinateur le résoudrait, ou vous pouvez définir manuellement la clé si vous n'avez que quelques machines de développement). Dans mon cas cela n'avait pas d'importance puisque j'avais déjà besoin du fichier .targets personnalisé pour d'autres choses que je faisais dans ce projet.
journalisation d'erreur d'une tâche de construction
Vous n'avez pas besoin IVsErrorList d'ajouter des erreurs à Visual Studio lors d'une construction (et si vous avez fait, vous ne seriez pas en charge correctement construit la ligne de commande, Expression Blend, et d'autres outils).
Tout ce que vous devez faire est d'appeler Log.LogErrror Log.LogWarning à l'intérieur de votre tâche de construire, comme ceci:
public class CheckForErrorsInMyMarkupExtension : Task
{
... parameters here ...
public override Execute()
{
... code to load XAML and scan it for markup extension errors ...
... when you discover an error ...
Log.LogError("I saw an error");
}
}
Ces interfaces sont nouveaux dans VS2010 alors? Quand je dis "cuit", je veux dire que VS a une connaissance spécifique des extensions de balisage individuelles qui peuvent causer une erreur de compilation, ou est-ce que ce mécanisme est extensible par l'utilisation d'une interface, d'un attribut, etc. le cas pour VS2008 mais a été ouvert pour VS2010. Est-ce exact? – Grokys
Aucune interface n'existe au moins depuis VS2005. Les extensions MEF est une nouvelle et bien meilleure façon d'étendre Visual Studio – mfeingold
Hmm, regardé les docs pour IVsErrorList et je ne comprends toujours pas comment implémenter une extension de balisage personnalisée qui a généré une erreur de compilation. Mise à jour de la question pour demander un exmaple ... – Grokys