.Net Logger（编写自己的vs log4net /企业记录器/ nlog等）
我在一个拥有约50多名开发人员的IT部门工作。 它曾经是大约100多名开发商，但由于经济衰退而被削减。
当我们的部门规模扩大时，我们已经做出了雄心勃勃的努力来建立一个特殊的建筑群。
该小组决定做的一件事是创建我们自己的内部记录器。 他们认为这是一项如此简单的任务，我们可以花费资源并自己完成。 现在我们遇到了性能问题和查看生成日志的困难，一些员工对我们在这样的基础设施上花费资源而不是专注于服务我们的业务和使用已经存在的东西如log4net或Enterprise Logger感到沮丧。
你能否帮我列出你不应该创建自己的.net记录器的原因。
也有理由为什么你应该得到一个公平的观点:)
我会采取不同的方法。 如何首先将公共接口引入您自己的库，例如Common Infrastructure Libraries（ http://netcommon.sourceforge.net/ ）。 然后，您可以逐步将所有项目移动到该接口，如果您自己的库不适合大型项目的工作，那么只需切换到一个开源框架（甚至是商业解决方案）。
HTH Alex
在我上一份工作中，几乎所有的基础设施都是由我们编写的，而不是使用一些现成的产品。 （以及“所有基础设施”我的意思是所有的 – 记录，消息传递，数据库，容器等等）。
它最大的缺点之一是它使我们花费大部分时间来处理与最终用户无关的事情，而不是添加更多function。
从那份工作中，我学会了始终专注于你的产品要解决的问题 。 贵公司是否正在开发伐木工？ 记录器的质量会影响您的客户吗？ 我不这么认为。
你的预算和人力有限 – 明智地使用它。 不要重新发明轮子。 如果您将注意力集中在他们需要的事情上，我相信您的公司和您的客户将会受益。
在我目前的项目中，我使用NHibernate作为ORM框架，而不是在其他项目中使用的内部框架。 而不是修复旧的ORM框架中的错误，我的重点是项目的主要路线图。 此外，NHibernate拥有自己的路线图，这意味着额外的function将来自我公司没有太多资源。
我使用自定义日志记录API，它使用提供者模型设计，允许插入外部日志框架。我已经为Log4Net，EntLib和System.Diagnostics.Trace记录器开发了提供程序。
这与Common Infrastructure Libraries基本相同。
这意味着内部开发没有明确依赖外部日志框架，但您仍然可以从您喜欢的日志框架的所有function中受益。 在实践中，我们通常使用Log4Net，但已经使用EntLib的客户除外。
- 它需要花钱。
- 这是很久以前完成的。
- 你并不像你想象的那么特别。 如果你是，那就做点什么吧。
- 也许你并不像你想象的那么聪明。
- 你是否人手过多？ 然而？
我不同意那些看到人们到处重新发明轮子的人。 轮可以是数据库服务器，操作系统或编程语言。 然而，像ORM框架或这个log4net这样的东西在市场上没有足够的时间被认为是轮子。 其中许多产品的生命周期很短，它们被新方法所取代，只考虑你看到了多少个ORM框架，然后微软推出了LINQ。 记录不是一个可以学习的坚实的学科，它非常依赖于平台。 因此，考虑使用可能过时的日志框架（log4net vs nlog），浪费时间学习它，并不排除构建自己的日志记录的选项。 我用ORM映射完成了这个，对我来说，构建一些ORM类比学习nHybernate更好。
我写了自己的一个，因为我认为（A）它基于一个标准.NET类的TraceListener和（B）它使用起来很简单，也许是因为我想写一个。
但现在我在我的新项目中使用NLog并在一些旧项目中替换它！
我错了吗？ 对我来说两者都很好，我使用NLog的原因是我想要一个需要几乎重写我的自定义TraceListener的function。 结果是一个1或2小时的教程，示例应用程序对我来说更便宜。 这不是普遍的情况; 但有助于获得有关记录问题的更清晰的图像。
如果您的日志记录解决方案有这样的特殊要求，即现成的解决方案不起作用，那么制作自定义版本可能是值得的。
如果这是争论，可以考虑下载一个开源框架并尝试自定义它。