是否可以拦截您不拥有且未创建的对象上的静态方法？
参考我对此问题的可能答案： 您如何审核 ASP.NET 成员资格表，同时记录哪些用户进行了更改？
是否可以拦截来自不属于您的代码的 ctor 的调用在您不拥有的密封内部类上，目的是在返回之前操作该对象？
具体示例：
SqlMembershipProvider，对于其所有数据访问，实例化一个连接帮助器类 System.Web.DataAccess.SqlConnectionHolder。
期望的结果是拦截此实例化，并在继续执行之前对 System.Web.DataAccess.SqlConnectionHolder 构造函数中打开的公共连接执行操作。
更新： 因此，正如莱皮对我的例子所观察到的那样，我所说的我想要的根本不是我想要的。
现在的目标是 System.Web.DataAccess.SqlConnectionHelper.GetConnection()
那么，我们可以拦截对此方法的调用吗？
internal static SqlConnectionHolder GetConnection(string connectionString, bool revertImpersonation)
这可能吗。如果是这样，一个简短的例子将不胜感激。
Referring to my possible answer to this question: How would you audit ASP.NET Membership tables, while recording what user made the changes?
Is it possible to intercept a call, coming from code you do not own, to a ctor on a sealed internal class that you do not own with the intention of manipulating the object before returning?
Concrete example:
SqlMembershipProvider, for all of it's data access, instantiates a connection helper class, System.Web.DataAccess.SqlConnectionHolder.
The desired result is to intercept this instantiation and perform an operation on the public connection that is opened in the ctor of System.Web.DataAccess.SqlConnectionHolder before letting execution continue.
UPDATE:
So, as leppie observed regarding my example, what I say I want isn't what I want at all.
The target is now System.Web.DataAccess.SqlConnectionHelper.GetConnection()
So, can we intercept the call to this method?
internal static SqlConnectionHolder GetConnection(string connectionString, bool revertImpersonation)
Is this possible. If so, an brief example would be appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
从技术上讲，这可以通过 IL 重写器实现，类似于 Postsharp 的做法。然而，鉴于您正在谈论的这是一个具有强名称的 .NET 程序集，存储在 GAC 和 ngen-ed 中，因此不太可能超越“技术上可行”的阶段。
Technically this is possible with an IL rewriter, similar to what Postsharp does. However, given that this is a .NET assembly you're talking about that has a strong name, is stored in the GAC and ngen-ed, that isn't likely to ever get past the "technically possible" stage.