Используете 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.*")]
Итак, мой вопрос к вам ... что мне не хватает? Вызовы методов в соответствии с целевыми атрибутами, похоже, не работают.
Ответы 4
Я считаю, что если вы измените AttributeTargetAssemblies на «PresentationFramework», это может сработать. (Еще не настолько хорошо PostSharp).
Сборка для WPF - это PresentationFramework.dll. AttributeTargetAssemblies требуется библиотека DLL, на которую он должен ориентироваться.
Если вы пытаетесь перехватывать вызовы внутри фреймворка (т.е. не в собственном коде), это не сработает. PostSharp может заменять код только в вашей собственной сборке. Если вы пытаетесь перехватить звонки, которые вы делаете, похоже, это должно сработать. Вы видите, что PostSharp работает в выводе сборки?
У меня есть тестовый код, который обращается к System.ObjectA.Property. Я надеюсь, что смогу использовать PostSharp в своем тестовом коде, чтобы изменить System.ObjectA.set_Property (...), чтобы вместо этого вызывать мой собственный метод. Примеры Лаоса (в частности, Trace), похоже, указывают на то, что это возможно. Я тут не прав?
PostSharp имеет новую версию, доступ к которой осуществляется со страницы «Загрузки» по ссылке «Все загрузки».
PostSharp 1.5 Ветвь разработки PostSharp, включающая новые функции, такие как поддержка Mono, Compact Framework или Silverlight, а также наследование аспектов. Загрузите из этой ветки, если вы хотите опробовать новые функции и помочь сообществу, тестируя новые разработки, и можете согласиться с низкой надежностью и стабильностью API.
В настоящее время это версия 1.5 CTP 3, но она поддерживает Silverlight.
В текущей версии PostSharp это невозможно.
PostSharp работает путем преобразования сборок до их загрузки в CLR. Прямо сейчас для этого должны произойти две вещи:
- Сборка должна быть загружена в среду CLR; у вас есть только один выстрел, и вы должны сделать его в этот момент.
- После завершения этапа трансформации вы не можете вносить никаких дополнительных изменений. Это означает, что вы не можете изменять сборку во время выполнения.
Самая последняя версия, 1.5 CTP 3, снимает первое из этих двух ограничений, но это вторая, действительно проблема. Однако это очень востребованная функция, так что не спускайте глаз:
Users often ask if it is possible to use PostSharp at runtime, so aspects don't have to be known at compile time. Changing aspects after deployment is indeed a great advantage, since it allow support staff to enable/disable tracing or performance monitoring for individual parts of the software. One of the cool things it would enable is to apply aspects on third-party assemblies.
If you ask whether it is possible, the short answer is yes! Unfortunately, the long answer is more complex.
Ошибки во время выполнения / сторонние аспекты
Автор также переходит к описанию некоторых проблем, которые возникают, если вы разрешаете модификацию во время выполнения:
So now, what are the gotchas?
- Plugging the bootstrapper. If your code is hosted (for instance in ASP.NET or in a COM server), you cannot plug the bootstrapper. So any runtime weaving technology is bound to the limitation that you should host the application yourself.
- Be Before the CLR. If the CLR finds the untransformed assembly by its own, it will not ask for the transformed one. So you may need to create a new application domain for the transformed application, and put transformed assemblies in its binary path. It's maybe not a big problem.
- Strong names. Ough. If you modify an assembly at runtime, you will have to remove its strong name. Will it work? Yes, mostly. Of course, you have to remove the strong names from all references to this assembly. That's not a problem; PostSharp supports it out-of-the-box. But there is something PostSharp cannot help with: if there are some strongly named references in strings or files (for instance in app.config), we can hardly find them and transform them. So here we have a real limitation: there cannot be "loose references" to strongly named assemblies: we are only able to transform real references.
- LoadFrom. If any assembly uses Assembly.LoadFrom, Assembly.LoadFile or Assembly.LoadBytes, our bootstrapper is skipped.
Элементы управления Silverlight расположены в сборке System.Windows.