帮我为 asp.net 应用程序找到一个摩擦最小的日志记录解决方案

Question

假设，为了争论，我有 30 个需要日志框架的 asp.net Web 应用程序（和站点，blerg）。我目前的解决方案是使用 Enterprise Library Logging。在网站上进行此操作涉及以下步骤：

1. 添加对两个程序集（EL Logging 和 Common）的引用
2. 将代码添加到 Global.asax.cs 以进行通用未处理错误捕获
3. 在 enterpriseLibrary.config 中复制，从另一个已经有日志记录的应用复制
4. 复制到 FileConfigurationSource.cs（允许您覆盖对 enterpriseLibrary.config 的硬编码路径的要求）
5. 将 FileConfigurationSource.cs 中的命名空间更改为新项目
6. 从另一个项目中复制特定于 EL 的 web.config 部分（2 个部分）
7. 在 web.config 中为新项目中的 EL 更改命名空间
8. 测试并确保其正常工作（通常通过使数据库脱机）

所有这些都是我所说的摩擦。如果您问我，那是很多违反 DRY 的行为，尤其是在所有 enterpriseLibrary.config 设置中。理想情况下，添加日志记录将是一个两步过程——这将有助于我在整个团队中采用它。

我想知道 .net 是否有一个没有所有这些重复的日志记录解决方案？我能找到的所有这些（log4net、nlog、EL Logging）似乎都使用这种“每个应用程序都有自己的配置，并且有很多重复”的模式。也许我错过了一些东西。

实际上，我们的每个应用程序都将拥有一个与其他应用程序 99% 相同的日志记录解决方案。它们在存储日志的位置和应用程序的名称上会有所不同。有没有办法使用三大日志记录解决方案之一，让您在机器级别或更集中的位置设置日志记录行为？我意识到有一个集中的日志配置有缺点。

同样重要：必须能够动态更改日志记录级别（不在 web.config 中存储日志记录配置，导致应用重启）并且日志记录必须可配置为部署的一部分（不希望在 Beta 服务器上发送严重错误的电子邮件）。这两个使使用 web.config 转换变得困难，因为在 .config 上运行转换作为构建的一部分而不是 web.config 很困难。

Answer 1

我找到了一个与您类似的问题的完美解决方案。

我有十个控制台应用程序、两个 ASP .NET 网站和三个 SharePoint webparts记录到一个目录，日志按日期、应用程序名称分隔等。该解决方案非常可配置且灵活并且允许动态更改配置。

所有这些荣耀都由NLog 实现，它允许单个配置文件是来自应用程序特定配置文件的included。

更具体地说，在我们的例子中，每个项目都包含 individual NLog 配置，内容如下：

<?xml version="1.0" encoding="utf-8" ?>
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      autoReload="true">
  <include file="PATH TO THE SHARED CONFIG" /> <!-- change this line -->
</nlog>

对于web应用，单独的NLog配置can be read from：

• 标准网络应用文件web.config
• web.nlog 与 web.config 位于同一目录中
• NLog.config 在应用程序目录中
• NLog.dll.nlog 在NLog.dll 所在的目录中

共享配置文件可以放置在ASP .NET 进程可以读取的任何地方，并且还有autoReload="true" 允许即时修改。在我们的例子中，它为日志消息定义了不同的targets，例如电子邮件、不同目录中的日志文件等等。