我在文档中看到，事件提供者的正确命名约定应该是＆lt;公司名称＆GT; /＆LT;产品名称＆GT; /＆LT;组件＆gt; ，根据文档here：
使用EventSourceAttribute的Name属性为您的事件源代表的ETW事件提供程序提供描述性的限定名称。默认值是事件源类型的简称，由于ETW提供程序名称共享一个计算机范围的命名空间，因此很容易导致冲突。良好的提供者名称“ - ”的示例。遵循此3元素约定将确保事件查看器在逻辑文件夹层次结构中显示事件日志：“应用程序和服务 日志/＆LT;公司名称＆GT; /＆LT;产品与GT; /＆LT;成分＆gt;”
是否可以创建包含公司和多个产品的结构？
我试图了解行为，因为当我以“CompanyName-Product”格式注册两个清单时，它们将在日志中显示为两个单独的日志，而不是将它们嵌套在CompanyName根目录下。
但是，如果我包含一个组件名称，例如“CompanyName-Product-Compontent1”，那么它们将正确地嵌套在根目录下。是否无法在没有组件的情况下创建日志结构？
例如，使用Microsoft的日志：
Microsoft
--> Windows
-->.....
Microsoft
--> SQLServerDataTools
我可以看到每个组件或多或少都在Windows目录下，但似乎只有公司和产品的提供商名称没有“Microsoft-SQLServerDataTools”之类的组件进入它自己的日志。有没有办法可以在同一公司名下嵌套？
答案 0 :(得分：1)
您不必遵循这种方法，但建议使其更有条理，更易于维护，否则最终会出现“mycompany-product”，“mycompany.product”等随机名称。 mycompanyproduct'，'product-mycompany'并且管理起来很痛苦，因为它们不遵循模式。在这种情况下，命名只是一个推荐，你可以输入你想要的名字。
关于事件源，每个名称都是一个具有自己guid的不同实体，如果你看到它们是嵌套的，可能是因为你使用的工具基于这种方法嵌套它们，但它们并不相互依赖。 / p>
要管理它们，您可以采用以下两种方法：
为每个组件\ service创建一个事件源： 这种方法将为每个事件源生成一个独立的清单，并且您将彼此隔离管理它们。您可以扩展您的服务而不必担心制动他人。您也可以通过名称或GUID单独过滤它们。
创建一个事件源并在所有服务中共享： 这样，您将使用产品名称创建一个大事件源并在组件之间共享，这种方法维护起来有点微妙，因为您必须使版本与项目保持同步，并且更改将传播到所有组件，您可以使用关键字的特定组件的单独内部事件。我不推荐这种方法。