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