EventRegister 1.0.26 feedback: localization, versioning, OutputType RRS feed

  • General discussion

  • I'm not sure what is the proper feedback channel for the Microsoft.Diagnostics.Tracing.EventRegister 1.0.26, Microsoft.Diagnostics.Tracing.EventSource 1.0.26, and Microsoft.Diagnostics.Tracing.EventSource.Redist 1.0.26 NuGet packages, so I'll just post these here.

    We've got a service that uses those packages for writing events to Windows Event Log. It thus needs a provider manifest with channels and such. The messages and maps are localized to a few languages.

    • When the project is being built on .NET Framework 4.0 (not 4.5.1), eventRegister.exe does not find the satellite assemblies that contain the localized strings, so it silently omits the corresponding <resources> elements from the manifest. The -ReferencePath option of eventRegister.exe does not solve the problem because it works by adding a handler for the AppDomain.ReflectionOnlyAssemblyResolve event and ResourceManager does not use reflection-only loads. Workaround: Add a custom target that copies the satellite assemblies to subdirectories of the directory that contains eventRegister.exe.
    • The CreateEtwManifestsAndRegDllsCore target in Microsoft.Diagnostics.Tracing.EventRegister.targets has Inputs="$(AssmName)" and does not declare any dependency on satellite assemblies.  If I edit only *.resx files and build the project, then Visual Studio compiles only the satellite assemblies and not the main assembly, and it skips the CreateEtwManifestsAndRegDllsCore target because the output files are already newer than the main assembly. The *.dll and *.man files generated by this target will then not contain the updated translations from the *.resx files. Workaround: Before building the project, touch some source file that is compiled to the main assembly.
    • When I add parameters to an event that was already defined in a previous version of the software, I'd like to keep the original definition as well, so that Event Viewer can still format the events logged by the previous version. To do that, I'd define another method with the same eventId but a higher EventAttribute.Version, and perhaps rename the original method so that the localization resources don't clash. However, if I try that, then eventRegister.exe fails and says the event ID is already in use.
    • If I define multiple events with the same Task and the same Opcode, then eventRegister.exe fails ("Event a (with ID b) has the same task/opcode pair as event c (with ID d)"). Why this restriction?
    • There seems to be no way to define task-specific opcodes, so all opcodes consume the same 8-bit space.
    • There seems to be no way to specify an OutputType (e.g. win:Win32Error) for a parameter of an event.
    • There is a good error message "a property insert in the event message is referencing a non-existent property" if I specify e.g. "{9}" in EventAttribute.Message and the method does not have that many parameters. However, if I make the same mistake in the resources to which EventSourceAttribute.LocalizationResources refer, then there is no warning. I think errors in the *.resx files are even more likely than in the *.cs file, because the list of parameters is not immediately visible.
    • When an event has many parameters, it is difficult to verify that all the "{number}" placeholders refer to the correct parameters. Because they get converted to "%number" at build time anyway, it might make sense to allow "{parameterName}" as well, both in EventAttribute.Message and in resource files.

    • Edited by ranta Wednesday, October 1, 2014 11:50 AM added links to NuGet packages by request
    Tuesday, September 30, 2014 12:10 PM

All replies

  • I think you should post the nuguet link here.
    Wednesday, October 1, 2014 2:29 AM
  • OK, I edited the original post to include the links. The packages were announced and discussed in .NET Blog:

    Wednesday, October 1, 2014 12:25 PM
  • I hit another problem today. I wanted to include newlines in the events shown by Event Viewer, so I put "\r\n" within EventAttribute.Message, and EventRegister mapped that to "%r%n" in the manifest. However, Event Viewer of Windows 7 SP1 displayed a space instead. I was able to fix that by using "\n" rather than "\r\n"; EventRegister mapped "\n" to "%n", and Event Viewer displayed a newline.

    Unfortunately, fixing this in localized strings is not so easy. EventRegister reads the localized strings from resource DLLs, which Visual Studio compiles from .resx files. The .resx files normally have Windows (CR LF) line endings, which EventRegister maps to "%r%n", which Event Viewer does not display as a newline. To get "%n" in the manifest, I have to open the .resx file as text, select Unix (LF) line endings in File / Advanced Save Options, save, and rebuild. However, if I subsequently edit the .resx file in the resource Editor of Visual Studio 2010 SP1, then it changes the insignificant line endings back to CR LF, so the file has a mixture of CR LF and LF line endings, which causes problems with some version-control software. I tried to make the line endings consistent by instead using the "&#10;" syntax within the value elements, but the resource editor replaced that with a raw LF character when saving.

    I wish there were a more convenient way to get the newlines right. Perhaps EventRegister could be changed to map CR LF to just "%n" rather than "%r%n".

    Wednesday, January 21, 2015 2:41 PM
  • When the project is being built on .NET Framework 4.0 (not 4.5.1), eventRegister.exe does not find the satellite assemblies that contain the localized strings, so it silently omits the corresponding <resources> elements from the manifest.

    Meanwhile, the EventRegister source code has been published on GitHub. It actually contains a comment claiming it would create a separate AppDomain whose application base and configuration file are suitable for the specified assembly. However, the code that assigns the AppDomainSetup properties that way has been commented out; instead, it copies the AppDomainSetup.ApplicationBase from the original application domain, and that directory typically won't contain the satellite assemblies. Related: microsoft/perfview#558, microsoft/perfview#741.

    • Edited by ranta Monday, August 5, 2019 9:23 PM remove spurious </resources>
    Monday, August 5, 2019 9:20 PM