Common.Logging 有其他选择吗？
编辑：Common.Logging 2.1.1 于 2012 年 6 月 9 日发布，Github 页面 相当活跃，作者专门评论了项目的健康状况。
我们正在考虑使用Common.Logging 在一个新的 .NET 项目中，但我有点担心该项目似乎已变得不活跃。 主页上次更新于 2009 年，SourceForge 上提供的最新版本 于 2010 年创建。我已经找到了 与 NLog 2 不兼容，我担心这可能会成为一个问题随着时间的推移，更大的问题。我注意到 Enterprise Library 5.0 没有被列为兼容，但我还没有尝试过。
是否有其他替代方案提供类似的通用接口？
EDIT: Common.Logging 2.1.1 was released on June 9, 2012 and the Github page is fairly active, with the author commenting specifically on the health of the project.
We're looking at using Common.Logging in a new .NET project but I'm a bit concerned that the project seems to have become inactive. The homepage was last updated in 2009 and the latest version available on SourceForge was created in 2010. I've already found an incompatibility with NLog 2 and I'm concerned that this may become a bigger problem over time. I have noticed that Enterprise Library 5.0 isn't listed as being compatible but I've not tried it.
Are there any other alternatives that provide a similar common interface?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我已经使用 Common.Logging 四年了，并且我能够将它与 NLog2 一起使用。为了彻底回答你的问题，我们需要首先仔细看看 Common.Logging。 Common.Logging 为您带来了两个好处：
从 1.x 开始，Common.Logging 允许您独立于日志记录框架编写应用程序。因此，您可以轻松地从一种日志记录框架更改为另一种日志记录框架，甚至无需重新编译应用程序。这对于公共库的开发特别有用，公共库可以被使用不同日志框架的各种应用程序使用。
从 2.x 开始，Common.Logging 允许您聚合来自各种日志框架的日志信息。假设我们正在开发一个应用程序并希望利用两个第三部分库，例如 A3rd.dll 和 B3rd.dll。 A3rd.dll 使用 log4net，但 B3rd.dll 使用 NLog。现在如何将 A3rd.dll 和 B3rd.dll 中的日志信息合并到一个日志文件（或日志监控系统）中？ Common.Logging 可以提供帮助，例如，它可以从 NLog 捕获日志消息并将其发送到 log4net，然后让 log4net 将其写入日志文件或发送到 log4net 可以执行的任何地方。
现在，回到 NLog2。 NLog2 中的日志记录 API 向后兼容 NLog1，但用于配置和定位的 API 已更改。因此，如果您需要的只是将日志消息发送到 NLog2，您可以简单地进行程序集重定向（请参阅我的答案：NLog v2 可以与 Common.Logging 一起使用）。
话虽这么说，如果您想使用 Common.Logging 将 NLog2 消息聚合到其他日志记录框架，则程序集重定向方法将不起作用。必须创建 NLog2 特定适配器。
就像@Kugel 所说，不活跃可能意味着稳定和成熟。由于 Common.Logging 可与各种日志记录框架配合使用，因此每次受支持的日志记录框架发布时，不太可能发布新版本。否则可能会带来更多的混乱而不是帮助。因此，应始终首先考虑程序集重定向。只有当确实出现不兼容问题时，就像我提到的 NLog2 消息重定向一样，才向邮件列表发送电子邮件，我确信有人会介入并提供帮助。
干杯，
肯尼思
I have been using Common.Logging for four years, and I'm able to use it with NLog2. To answer your question thoroughly, we need to take a closer look at Common.Logging first. Common.Logging gives you two benefits:
Since 1.x, Common.Logging let you write your application independent of the logging framework. So you can easily change from one logging framework to another without even recompiling your application. This is particular useful to the development of common library, which may be used by various applications that use different logging frameworks.
Starting 2.x, Common.Logging let you aggregate the logging information from various logging frameworks. Let's say we are developing an application and want to leverage two 3rd part libraries, say A3rd.dll and B3rd.dll. A3rd.dll uses log4net, but B3rd.dll uses NLog. Now how do you consolidate the log information from A3rd.dll and B3rd.dll into one log file (or log monitoring system)? Common.Logging can help, for example, it can capture the log message from NLog and send it over to log4net, and then let log4net to write it to the log file or send it to anywhere that log4net can do.
Now, back to NLog2. The logging API in NLog2 is backward compatible with NLog1, but the API for configuration and targeting were changed. So if all you need is to send the log message to NLog2, you can simply do assembly redirect (see my answer here: Can NLog v2 be used with Common.Logging).
That being said, if you want to aggregate NLog2 message to other logging framework using Common.Logging, the assembly redirect approach won't work. A NLog2 specific adapter has to be created.
Like @Kugel said, inactive could mean stable and mature. As Common.Logging works with various logging framework, it is unlikely to release a new version every time one of the supported logging framework makes a release. It could be otherwise more confusion than help. Hence, assembly redirect should always be considered first. Only when there is really an incompatibility issue arise, like I mentioned about the NLog2 message redirecting, send an email to the mailing list and I'm sure somebody will jump in and help.
Cheers,
Kenneth
bclcontrib-abstract 项目的这个区域似乎正在发生一些事情：
< a href="http://code.google.com/p/bclcontrib-abstract/source/browse/Contoso.Abstract.NLog/Abstract/NLogServiceLog.cs" rel="nofollow">http://code.google.com/p/bclcontrib-abstract/source/browse/Contoso.Abstract.NLog/Abstract/NLogServiceLog.cs
尝试过
BclContrib-Abstract .NLog 0.1.5NuGet 包我不喜欢它位于 Contoso 命名空间下的方式（Contoso.Abstract.NLog）。It looks like there's something going on in this area of the bclcontrib-abstract project:
http://code.google.com/p/bclcontrib-abstract/source/browse/Contoso.Abstract.NLog/Abstract/NLogServiceLog.cs
Having tried the
BclContrib-Abstract.NLog 0.1.5NuGet package I'm not liking the way that it sits under the Contoso namespace (Contoso.Abstract.NLog).如果我想使用不受支持的库（例如 NLog2），看起来一种选择是实现自定义
FactoryAdapter。我不确定这有多困难，但这可能是一个选择：更新：
这是我第一次尝试NLog 2 的实现，使用风险自负。欢迎任何评论：
https://gist.github.com/1107148
if I want to use an unsupported library (e.g. NLog2) it looks like one option would be to implement a custom
FactoryAdapter. I'm not sure how difficult this would be, but it could be an option:Update:
Here is my first attempt at an implementation for NLog 2, use at your own risk. Any comments welcome:
https://gist.github.com/1107148