我认为如果动态拦截能够满足您的需求，那么Castle Dynamic Proxy是一个不错的解决方案。这个框架在内部被许多其他想要提供AOP功能的框架所使用。通常，大多数现有的IoC容器现在都提供了一些动态拦截机制（Spring.NET、温莎、StructureMap等）如果您已经在使用IoC容器，那么查看它的建议可能会更容易。
如果动态拦截不能满足您的需求（编织密封类、拦截非虚调用等），那么您当然需要静态编织。PostSharp是该领域中的引用。
请注意，它也存在Linfu，可以用来利用这两种AOP方式。

“最佳”是主观的。
首先，列出你所需要的特性，你的体系结构等等。然后寻找你所需要的选项，而不引入不必要的复杂性。例如，有几个是面向接口的：你的代码现在是面向接口的吗？如果不是，PostSharp可能是一个更好的选择（被编织到原始类中）。但是当然，PostSharp不能在运行时配置...当然。

当然，“最好的方法”是主观的，但对我来说，在.NET中进行面向方面编程的最好方法是使用众所周知的设计技术。例如，通过应用SOLID principles，您可以实现允许添加横切关注点所需的灵活性和模块化。如果您的设计正确，您甚至可以在没有任何框架的情况下应用大多数横切关注点。认为OOP不适合进行AOP是一种谬论。
以下是一些提示：

• 不要依赖于具体的示例，而要依赖于抽象。
• 不要在同一个类中混合横切关注点和业务逻辑。
• 通过在实现横切关注点（decorators）的类中 Package 带有业务逻辑的类来添加这些关注点。
• 在你的设计中找到共同的工件，并对它们进行同等的建模，最好使用相同类型的抽象，例如this和this。

当你已经有了正确的抽象之后，向系统添加新的横切关注点仅仅是编写一个新的装饰器类并将其 Package 在正确的实现周围的问题。如果抽象是通用的，你可以将一个装饰器 Package 在一个大的类组周围（这正是AOP所要做的）。
虽然动态代理和代码编织等技术可以让设计糟糕的应用程序更容易工作，但对于好的设计来说，确实没有其他选择。迟早你会被烧伤。这并不意味着动态代理生成和代码编织不应该使用。但如果没有一个正确的应用程序设计，即使这些技术也只会有一点点帮助。

我不知道最好的，有很多框架，没有足够的时间在一天中尝试所有。
我确实使用了PostSharp，并且惊喜地发现它是多么容易上手。
我还研究了温莎和Spring.Net的AOP，方法是不同的（运行时与编译时）。混合AOP和IoC似乎是有意义的。当你还没有使用这些框架中的一个时，开始要做很多工作，但不要让这些阻止你。
对于现在的新项目，我可能会使用Castle温莎，但这主要是因为我也想使用IoC。如果我必须快速地将AOP实现到现有的代码库中，我会使用PostSharp。

还有微软的策略注入和Unity Interception。