Использование PostSharp для перехвата вызовов объектов Silverlight?

Я работаю с PostSharp, чтобы перехватывать вызовы методов для объектов, которыми я не владею, но мой код аспекта, похоже, не вызывается. Документация в области Silverlight кажется довольно слабой, поэтому я был бы признателен за любую помощь, которую вы, ребята, можете предложить :)

У меня есть атрибут, который выглядит так:

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

И запись в моей AssemblyInfo, которая выглядит так:

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

Итак, мой вопрос к вам: что я упускаю? Вызовы методов под соответствующими целевыми атрибутами не работают.


person Gabriel Isenberg    schedule 18.09.2008    source источник


Ответы (4)


Это невозможно в текущей версии PostSharp.

PostSharp работает путем преобразования сборок перед их загрузкой средой CLR. Прямо сейчас, чтобы сделать это, должны произойти две вещи:

  • Сборка должна быть загружена в среду CLR; у вас есть только один выстрел, и вы должны сделать это в этот момент.
  • После того, как этап преобразования завершен, вы не можете вносить дополнительные изменения. Это означает, что вы не можете изменять сборку во время выполнения.

Новейшая версия 1.5 CTP 3 удаляет первое из этих двух ограничений, но проблема именно во втором. Однако это очень востребованная функция, так что будьте начеку очищенный:

Пользователи часто спрашивают, можно ли использовать PostSharp во время выполнения, чтобы аспекты не обязательно были известны во время компиляции. Изменение аспектов после развертывания действительно является большим преимуществом, поскольку позволяет персоналу службы поддержки включать/отключать трассировку или мониторинг производительности для отдельных частей программного обеспечения. Одна из замечательных вещей, которую он позволит, — это применение аспектов к сторонним сборкам.

Если вы спросите, возможно ли это, короткий ответ - да! К сожалению, длинный ответ более сложен.

Ошибки времени выполнения/сторонних аспектов

Автор также переходит к описанию некоторых проблем, которые возникают, если вы разрешаете модификацию во время выполнения:

Итак, каковы подводные камни?

  • Подключение загрузчика. Если ваш код размещен (например, в ASP.NET или на COM-сервере), вы не можете подключить загрузчик. Таким образом, любая технология создания среды выполнения связана с ограничением, заключающимся в том, что вы должны размещать приложение самостоятельно.
  • Be Before CLR. Если CLR самостоятельно найдет непреобразованную сборку, она не будет запрашивать преобразованную. Поэтому вам может потребоваться создать новый домен приложения для преобразованного приложения и поместить преобразованные сборки в его двоичный путь. Возможно, это не большая проблема.
  • Сильные имена. Если вы изменяете сборку во время выполнения, вам придется удалить ее строгое имя. Это будет работать? Да, в основном. Конечно, вы должны удалить строгие имена из всех ссылок на эту сборку. Это не проблема; PostSharp поддерживает его по умолчанию. Но есть кое-что, с чем PostSharp не может помочь: если в строках или файлах (например, в app.config) есть какие-то строго именованные ссылки, мы вряд ли сможем их найти и преобразовать. Итак, здесь у нас есть реальное ограничение: не может быть свободных ссылок на сборки со строгими именами: мы можем только преобразовывать настоящие ссылки.
  • LoadFrom. Если какая-либо сборка использует Assembly.LoadFrom, Assembly.LoadFile или Assembly.LoadBytes, наш загрузчик пропускается.
person John Feminella    schedule 16.03.2009

Я считаю, что если вы измените AttributeTargetAssemblies на «PresentationFramework», это может сработать. (У PostSharp еще нет такой возможности).

Сборка для WPF — PresentationFramework.dll. AttributeTargetAssemblies нуждается в dll, на которую он должен ориентироваться.

person MagicKat    schedule 18.09.2008
comment
Элементы управления Silverlight расположены в сборке System.Windows. - person Gabriel Isenberg; 19.09.2008

У PostSharp есть новая версия, доступ к которой можно получить, перейдя по ссылке «Все загрузки» на странице «Загрузки».

PostSharp 1.5 Ветвь разработки PostSharp, включающая новые функции, такие как поддержка Mono, Compact Framework или Silverlight и наследование аспектов. Загрузите из этой ветки, если вы хотите попробовать новые функции и помочь сообществу, тестируя новые разработки, и можете смириться с низкой надежностью и стабильностью API.

В настоящее время версия 1.5 CTP 3, но она поддерживает Silverlight.

person Bryan Bailliache    schedule 13.03.2009

Если вы пытаетесь перехватывать вызовы внутри фреймворка (т. е. не в своем собственном коде), это не сработает. PostSharp может заменить код только в вашей собственной сборке. Если вы пытаетесь перехватывать звонки, которые вы делаете, то, похоже, это должно сработать. Вы видите, что PostSharp работает в выводе сборки?

person Joel Lucsy    schedule 19.09.2008
comment
У меня есть тестовый код, который обращается к System.ObjectA.Property. Я надеюсь, что смогу использовать PostSharp в своем тестовом коде, чтобы изменить System.ObjectA.set_Property(...) так, чтобы вместо этого вызывался мой собственный метод. Примеры Лаоса (в частности, Trace), кажется, указывают на то, что это возможно. Я не прав там? - person Gabriel Isenberg; 20.09.2008