我正在寻找一种在我的代码中将跟踪输出到日志文件的方法，该代码在linux上运行。
我不希望在我部署它的每个地方都将打印信息包含在二进制文件中。
它是windows，我只是使用WPP来跟踪而不将实际的跟踪字符串放在我的二进制文件中。
如何在Linux中实现这一目标？
答案 0 :(得分：1)
我对这方面的Linux工具不太熟悉，所以也许有更好的系统。但是，由于没有其他人提出任何好的建议，我会提出一个建议。 （可能不是一个很好的建议，但我现在能想到的最好的建议。）
理论上，你可以继续使用wpp。 Wpp只是一个模板系统。它扫描配置和输入文件以创建数据结构。然后它运行一个模板，填写从扫描中获得的数据值，生成tmh文件。您可以创建一组使用Linux apis而不是Windows apis的新模板，并以与其他日志解码器系统一起使用的方式记录消息字符串。
答案 1 :(得分：0)
我只是现在才注意到这个问题，只想为一个案例在故事中加上我的两分钱。我个人非常感谢Windows WPP跟踪，并认为它可能是在类似工具中进行实际开发故障排除的最佳 engineering 解决方案。
发生了两次我将WPP使用扩展到类似Unix的平台的情况。我们希望总体上使用WPP概念的强项，但仍将其用于多平台代码中。这不是移植，而是我们在Windows上配置的特定WPP使用的包装。有一次我们拥有一个Web服务，可以在Windows上执行实际的WPP预处理；听起来可能有些疯狂，但在本地网络中效果很好且有效。在每次编译发送Web请求之前执行的包装器脚本，获取处理后的文件，然后对生成的包含文件进行后处理，以使其适合于类Unix平台。第二次，我们实现了自己的简化的WPP预处理器（我们发现它还有其他用途-例如，对于生产和单元测试，我们可以生成不同的跟踪语句）。这是一个苛刻的解决方案：无论如何，您都需要在非Windows平台上的包装器后面使用一些物理跟踪框架（嗯，这显然是我们第一次实现我们自己的较低级别）。
我认为Linux世界没有一个可与WPP媲美的框架。我什至曾经想到为WPP创建一个开源移植项目可能是一个好主意。我不确定是否会要求太多。我说这是一个很棒的 engineering 解决方案。但是谁愿意做肮脏的工程呢？开源社区更喜欢抽象的面向对象的通用解决方案，流式传输以及在相应工具中的必要性较低（WPP需要特殊的管理工具和OS支持）。如今，易于编写代码是
由于WPP缺乏普及性，微软也可能会犯错（或不愿）。他们将其保留为Windows DDK附带的一个内部框架，因为它们必须为驱动程序开发人员提供一些日志记录/跟踪解决方案。甚至没有人注意到WPP也非常适合于用户空间代码。例如，用于C＃的WPP预处理程序根本就不会公开。
尽管如此，我仍然认为将WPP移植到Unix / Linux的工作可能是具有挑战性，有趣甚至是有用的尝试。如果有人决定领导它。 ：）