Utilisation de PostSharp pour intercepter les appels d’objets Silverlight?

StackOverflow https://stackoverflow.com/questions/97733

  •  01-07-2019
  •  | 
  •  

Question

Je travaille avec PostSharp pour intercepter les appels de méthode à des objets que je ne possède pas, mais mon code aspect ne semble pas avoir été appelé. La documentation semble assez laxiste dans la zone Silverlight, je vous serais donc reconnaissant de votre aide.)

J'ai un attribut qui ressemble à: 

public class LogAttribute : OnMethodInvocationAspect
{
    public override void OnInvocation(MethodInvocationEventArgs eventArgs)
    {
        // Logging code goes here...
    }
}

Et une entrée dans AssemblyInfo qui ressemble à: 

[assembly: Log(AttributeTargetAssemblies = "System.Windows", AttributeTargetTypes = "System.Windows.Controls.*")]

Alors, ma question est la suivante: qu'est-ce qui me manque? Les appels de méthode sous les cibles d'attribut correspondantes ne semblent pas fonctionner.

Était-ce utile?

La solution

Cela n'est pas possible avec la version actuelle de PostSharp.

PostSharp fonctionne en transformant des assemblages avant d’être chargés par le CLR. À l'heure actuelle, pour faire cela, deux choses doivent se produire:

  • L'assemblage doit être sur le point d'être chargé dans le CLR; vous n’avez qu’une chance, et vous devez le prendre à ce stade.
  • Une fois la transformation terminée, vous ne pouvez plus apporter de modifications. Cela signifie que vous ne pouvez pas modifier l'assembly au moment de l'exécution.

La dernière version, 1.5 CTP 3, supprime le premier de ceux-ci. deux limitations , mais c’est la seconde qui pose vraiment le problème. Il s'agit toutefois de une fonctionnalité très sollicitée , alors gardez l'œil ouvert. pelé:

  

Les utilisateurs demandent souvent s’il est possible d’utiliser PostSharp au moment de l’exécution, de sorte que les aspects ne doivent pas nécessairement être connus au moment de la compilation. Changer d’aspect après le déploiement est en effet un grand avantage, car il permet au personnel d’assistance d’activer / désactiver le suivi ou la surveillance des performances pour des parties individuelles du logiciel. L’une des choses intéressantes qu’elle permettrait de faire est d’appliquer des aspects aux assemblages tiers.

     

Si vous demandez si c'est possible, la réponse courte est oui! Malheureusement, la réponse longue est plus complexe.

Des pièges liés aux aspects d'exécution / tiers

L'auteur décrit également certains des problèmes qui surviennent si vous autorisez la modification au moment de l'exécution:

  

Alors maintenant, quels sont les pièges?

     
      
  • Brancher le programme d'amorçage. Si votre code est hébergé (par exemple, dans   ASP.NET ou sur un serveur COM), vous   ne peut pas brancher le bootstrapper. Donc tout   la technologie de tissage d'exécution est liée à   la limitation que vous devriez héberger   l'application vous-même.
    •   
  • Être avant le CLR. Si le CLR trouve l'assemblage non transformé par lui-même,   il ne demandera pas le transformé   un. Donc, vous devrez peut-être créer un nouveau   domaine d'application pour le transformé   application, et mettre transformée   assemblées dans son chemin binaire. Ses   peut-être pas un gros problème.
    •   
  • Noms forts. Ough. Si vous modifiez un assemblage au moment de l'exécution, vous devrez   enlever son nom fort. Est-ce que ça marchera?   Oui surtout. Bien sûr, vous devez   enlever les noms forts de tous   références à cet assemblage. C'est   Pas de problème; PostSharp le soutient   hors de la boîte. Mais il y a quelque chose   PostSharp ne peut pas aider avec: s'il y a   sont des références fortement nommées dans   des chaînes ou des fichiers (par exemple dans   app.config), on peut difficilement les trouver   et les transformer. Nous avons donc ici un   vraie limitation: il ne peut y avoir   "Références en vrac" fortement nommé   assemblées: nous ne pouvons que   transformer de vraies références.
    •   
  • LoadFrom. Si un assemblage utilise Assembly.LoadFrom, Assembly.LoadFile   ou Assembly.LoadBytes, notre   le programme d'amorçage est ignoré.
    •   

Autres conseils

Je pense que si vous remplacez AttributeTargetAssemblies par "PresentationFramework", cela pourrait fonctionner. (N'ayez pas encore PostSharp en bas).

L'assembly pour WPF est PresentationFramework.dll. AttributeTargetAssemblies a besoin de la dll qu’elle devrait cibler.

PostSharp a une nouvelle version, accessible depuis le lien de la page Téléchargements vers "Tous les téléchargements".

PostSharp 1.5 La branche de développement de PostSharp, qui comprend de nouvelles fonctionnalités telles que la prise en charge de Mono, Compact Framework ou Silverlight et l’héritage d’aspect. Téléchargez depuis cette branche si vous souhaitez essayer de nouvelles fonctionnalités et aider la communauté en testant de nouveaux développements, et pouvez accepter une fiabilité et une stabilité inférieures des API.

La version est actuellement à 1,5 CTP 3, mais elle prend en charge Silverlight.

Si vous essayez d'intercepter des appels dans le cadre (c'est-à-dire pas dans votre propre code), cela ne fonctionnera pas. PostSharp ne peut remplacer le code que dans votre propre assemblage. Si vous essayez d'intercepter les appels que vous passez, il semble que cela devrait fonctionner. Voyez-vous PostSharp en cours d'exécution dans la sortie de la construction?

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top