Using PostSharp to intercept calls to Silverlight objects?

Question

Hi all,

I'm working with PostSharp to intercept method calls to objects I don't own, but my aspect code doesn't appear to be getting called. The documentation seems pretty lax in the Silverlight area, so I'd appreciate any help you guys can offer :)

I have an attribute that looks like:

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

And an entry in my AssemblyInfo that looks like:

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

So, my question to you is... what am I missing? Method calls under matching attribute targets don't appear to function.

Answer 1

I believe if you change AttributeTargetAssemblies to "PresentationFramework", it might work. (Don't have PostSharp down that well yet).

The Assembly for WPF is PresentationFramework.dll. The AttributeTargetAssemblies needs the dll that it should target.

Answer 2

If you're trying to intercept calls within the framework (i.e., not in your own code), it won't work. PostSharp can only replace code within your own assembly. If you're trying to intercept calls you're making, then it looks like it should work. Do you see PostSharp running in the build output?

Answer 3

PostSharp has a new version, which is accessed from the Downloads page link to "All Downloads".

PostSharp 1.5 The development branch of PostSharp including new features like support for Mono, Compact Framework or Silverlight, and aspect inheritance. Download from this branch if you want to try new features and help the community by testing new developments, and can accept inferior reliability and stability of APIes.

The version is currently at 1.5 CTP 3 but it has support for Silverlight.

Answer 4

This is not possible with the present version of PostSharp.

PostSharp works by transforming assemblies prior to being loaded by the CLR. Right now, in order to do that, two things have to happen:

• The assembly must be about to be loaded into the CLR; you only get one shot, and you have to take it at this point.
• After the transformation stage has finished, you can't make any additional modifications. That means you can't modify the assembly at runtime.

The newest version, 1.5 CTP 3, removes the first of these two limitations, but it is the second that's really the problem. This is, however, a heavily requested feature, so keep your eyes peeled:

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.

Runtime/third-party aspect gotchas

The author also proceeds to outline some of the problems that happen if you allow modification at runtime:

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.