First, draw up a list of the features you need, your architecture, etc. Then look for options that do what you need, without introducing unnecessary complexity. For example, several are interface oriented: is your code currently interface oriented? If not, PostSharp might be a better choice (being weaved into the original classes). But of course, PostSharp can't be configured at runtime... horses for courses.
I don't know about best, there are a lot of frameworks and not enough hours in the day to try them all.
I did use PostSharp and was pleasantly surprised how easy it is to get started with it.
I also looked into AOP with Castle Windsor and Spring.Net, the approach is different (runtime vs compile time). Mixing AOP and IoC seems to make sense. When you're not using one of these frameworks yet it's a lot more work to get started but don't let that stop you.
For new projects now I'd probably use Castle Windsor, but that's mostly because I'd also want to use IoC. If i had to quickly implement AOP into an existing code base I'd use PostSharp.
I think that Castle Dynamic Proxy is the solution of choice if dynamic interception can handle your needs. This framework is used internally by a lot of other frameworks that want to offer AOP capabilities. Typically, most of existing IoC containers now provide some dynamic interception mechanisms (Spring.NET, Castle Windsor, StructureMap, etc.) If you already work with an IoC container, maybe it could be easier to look at what it proposes.
If dynamic interception can't address your needs (weaving sealed class, intercepting non-virtual call, etc.), then you certainly want static weaving. PostSharp is the reference in this domain.
Note that it also exists Linfu, that can be used to leverage both AOP fashions.
The best way to do aspect-oriented programming in .NET is by using well known design techniques. For instance, by applying the SOLID principles you can achieve the flexibility and modularity you need to allow adding cross-cutting concerns. If you have the design right, you will even be able to apply most cross-cutting concerns without any framework. It is a fallacy to think that OOP is unsuited for doing AOP.
Here are some pointers:
Don't depend on concrete instances, but depend on abstractions.
Don't mix cross-cutting concerns and business logic in the same class.
Adding cross-cutting concerns by wrapping classes with business logic in classes that implement those concerns (decorators).
Find common artifacts in your design and model them equally, preferably using the same type of abstractions. Take a look at this and this for instance.
When you've got the right abstractions in place, adding new cross-cutting concerns to the system is just a matter of writing a new decorator class and wrapping it around the right implementations. If abstractions are generic, you can wrap a single decorator around a large group of classes (which is exactly what AOP is about).
Although techniques such as dynamic proxies and code weaving could make it easier to work with a badly designed application, there is truly no alternative for good design. Sooner or later you will get burned. This doesn't mean that dynamic proxy generation and code weaving should not be used though. But without a proper application design even those techniques will just be marginally helpful.