有人有 Postsharp 制作经验吗？
有人在生产环境中使用过 Postsharp AOP 框架吗？ 有什么陷阱吗？ 为了进行一些日志记录等，Postsharp 可以与 Log4Net 结合使用吗？
任何有关将 Postsharp 与 Web 应用程序和/或 Log4Net 一起使用的教程都将受到高度赞赏。
Has anyone out there used Postsharp AOP framework in a production environment? Are there any pitfalls? In order to do some logging etc, can Postsharp be used in conjunction with Log4Net?
Any tutorials on using Postsharp with Web Apps and/or Log4Net will be highly appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我和另一位队友在几个已投入使用数月的项目中以不同的方式使用 PostSharp。 例如，在一种情况下，我使用它来记录异常情况下的方法参数值。 PostSharp Laos（包含在 PostSharp 中）是一种易于使用的注入方法调用的方式（例如，在方法进入、退出和异常时），您可以轻松地将日志调用添加到 log4net 注册的记录器。
它增加了构建时间，足以稍微改变我的构建习惯，但对于它提供的好处来说肯定不会太多，IMO。 在编写代码时，您可能希望将其从本地构建中排除，这很容易做到，因此您可以继续频繁且快速地构建，然后将其包含在构建服务器上等。
这是一个 来自 Gael（PostSharp 创建者）的优秀 PostSharp 教程...虽然它很旧，但很高兴看到这是一个贯穿。 到目前为止，在我遇到的控制台、winforms、WPF 或 WebApp 中使用它确实没有什么区别。
我还想说，一旦您弄清楚如何将老挝方面添加到项目中，重复练习就非常容易。 您应用方面的程序集/类的数量与 PostSharp 为您的构建添加的时间之间存在关系。 因此您甚至可以稍微控制构建时间问题。
至于代码，我对 PostSharp 的工作效果印象深刻……它从未搞砸过构建，使程序集无效或以其他方式弄乱代码。 我什至在 ASP.NET 应用程序中使用了它，具有代码覆盖率和性能检测（因此它与 MS 的 Assembly 检测工具配合得很好）。
总而言之，我会的。 建议您尝试一下以满足您的 log4net 要求。
I and one other teammate use PostSharp in different ways on several projects that are in production and have been for months. For example, in one case, I use it to log method parameter values in case of an Exception. PostSharp Laos (included in PostSharp) is an easy to use way of injecting method calls (on method entry, exit and on exceptions, for example) and you could easily add log calls to log4net registered loggers.
It has increased build times, enough to slightly change my build habits, but certainly not too much for the benefits it provides, IMO. While writing code, you may wish to exclude it from your local build, which is easy enough to do, so you can continue to build frequently and quickly, then include it on your build server etc.
Here's a good PostSharp tutorial from Gael (the PostSharp creator)... though it is old, it's nice to see it a run-through. There is really no difference in using it in a console, winforms, WPF or WebApp that I've encountered so far.
I would also say that once you've figured out how to add Laos aspects to a project, repeating the exercise is very easy. And there is a relationship between how many assemblies/classes you apply the aspects to and how much time PostSharp adds to your build. So you can even control the build time issues a bit.
As for the code, I am very very impressed with how well PostSharp works... it has never screwed up a build, made an assembly invalid or otherwise messed up code. And I have even used it in ASP.NET apps, with code coverage and performance instrumentation (so it's played nicely with MS' Assembly instrumentation tools).
All in all, I would def. recommend you try it out for your log4net requirements.
我们尝试使用 post Sharp 来完成一两件事，问题是它使构建时间超出了太长的时间。 如果您正在使用 CI，并且有频繁的签入方法，那么您最好拥有一台非常好的构建服务器和工作站机器。
显然 .net 4.0 将有一堆编译器钩子来使 AOP 之类的事情更容易完成。 我们的最终结论是等待。
We tried using post sharp for one or two things, the problem was that it blew the build times out way too long. If you are using CI, and have a frequent checkin methodology, you better have a damn good build server and workstation machines.
Apparently .net 4.0 is going to have a bunch of compiler hooks to make things like AOP easier to do. Our final conclusion was to wait for that.
我使用 Postsharp，我喜欢它。 它为我节省了很多我必须添加的重复代码。
我不需要 log4Net 的任何高级功能，谷歌足以了解它是如何工作的。 它只是完成工作。 到目前为止我还没有看到任何缺点。
对于 Postsharp，网站、博客上的入门指南和浏览源代码就足够了。 一个主要缺点是增加了构建时间。 我讨厌等待计算机工作。 在 Visual Studio（在快速 PC 上）中按 ctrl-shift-b 大约需要 8 秒，才能获得 +-60K loc 解决方案，其中有 2 个项目使用 postsharp 构建操作。 如果可以的话，尝试在尽可能少的项目中使用 Postsharp。
当您确实不想使用 postsharp 时，您可以创建一个包含 20 个项目的解决方案，并向每个项目添加构建后命令。 构建时间将足够长，足以惹恼团队的其他成员。
就我个人而言，我可能会在未来的项目中继续使用 Postsharp。 这些优点压倒了额外的构建时间。
I use Postsharp and I like it. It save's me a lot of duplicated code I had to add otherwise.
I did not need any advanced features for log4Net and google is enough to find out how it works. It just does the job. I haven't seen any disadvantages so far.
For Postsharp, the getting started guide on the website, the blog and browsing through the source is enough. A major disadvantage is the increased build time. I hate waiting for my computer to do work. It takes about 8 seconds to press ctrl-shift-b in visual studio (on a fast PC) for the +-60K loc solution with 2 projects using the postsharp build action. If you can, try to use Postsharp in the least amount of projects possible.
When you really don't want to use postsharp, you can create a solution with 20 projects and add the post-build command to every one of them. The build time will be long enough to annoy the rest of the team.
Personally I will probably keep on using Postsharp for future projects. The advantages overrule the extra build time.
我用的是post Sharp，我喜欢它。
后期的构建时间很烦人，但也勉强可以。
在调试模式下，我使用条件 SKIPPOSTSHARP 来消除 postsharp。
I use post sharp, I love it.
The post sharp build time is annoying but it's bare able.
In the debug mode, I use the conditional SKIPPOSTSHARP which eliminates postsharp.
根据 PostSharp 社区调查，很多公司在生产中使用 PostSharp。 令人沮丧的是他们拒绝透露身份:-(。
According to the PostSharp Community Survey, a lot of companies use PostSharp in production. The frustrating thing is that they refuse to be identified :-(.
我们在生产中确实使用 PostSharp，无论是 3.5 运行时还是 Silverlight 运行时。 要加快构建速度，您可以使用 /m: msbuild 的开关（google 使用 msbuild 进行并行构建）。 他们还承诺在即将发布的版本中大幅加快速度。
We do use PostSharp in production, both for 3.5 runtime and for Silverlight runtime. To speed up builds a bit you can use /m: switch for msbuild (google for parallel builds with msbuild). They also promise to speed it up dramatically in the upcoming release.