SingleFile usage of EventLog may not be able to access resource dll

[ericstj]

Description

It was raised during tactics that System.Diagnostics.EventLog relies on a loose native resource dll to register event log resources with Windows and this loose resource dll may not play well with single file. Relevant probing path: https://github.com/dotnet/runtime/blob/e55c908229e36f99a52745d4ee85316a0e8bb6a2/src/libraries/System.Diagnostics.EventLog/src/System/Diagnostics/EventLog.cs#L703

We do have fallback to use the .NETFramework copy of this dll, so the scenario where this would not work is a machine without .NETFramework and customer using Single File and logging messages to the event log. In that case their messages would be formatted incorrectly as shown in https://github.com/dotnet/runtime/issues/72245.

Reproduction Steps

Hypothetical: Build simple console application an application that uses EventLog, registers an event source, and logs to it.
Publish for single file. Run this on a machine without .NETFramework.

Expected behavior

Logs appear normally in Event Log.

Actual behavior

Hypothetical: Logs appear with an error doing to missing the dll with formatting strings, similar to https://github.com/dotnet/runtime/issues/27742

Regression?

No, new scenario

Known Workarounds

Install .NETFramework.
Make the app framework dependent on ASP.NET or WindowsDesktop. Manually deploy a resource DLL and write a registry key.

Configuration

Windows, SKUs without .NETFramework

Other information

No response

[dotnet-issue-labeler[bot]]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[ghost]

Tagging subscribers to this area: @agocke, @vitek-karas, @vsadov See info in area-owners.md if you want to be subscribed.

Issue Details

---

### Description It was raised during tactics that System.Diagnostics.EventLog relies on a loose native resource dll to register event log resources with Windows and this loose resource dll may not play well with single file. Relevant probing path: https://github.com/dotnet/runtime/blob/e55c908229e36f99a52745d4ee85316a0e8bb6a2/src/libraries/System.Diagnostics.EventLog/src/System/Diagnostics/EventLog.cs#L703 We do have fallback to use the .NETFramework copy of this dll, so the scenario where this would not work is a machine without .NETFramework and customer using Single File and logging messages to the event log. In that case their messages would be formatted incorrectly as shown in https://github.com/dotnet/runtime/issues/72245. ### Reproduction Steps Hypothetical: Build simple console application an application that uses EventLog, registers an event source, and logs to it. Publish for single file. Run this on a machine without .NETFramework. ### Expected behavior Logs appear normally in Event Log. ### Actual behavior Hypothetical: Logs appear with an error doing to missing the dll with formatting strings, similar to https://github.com/dotnet/runtime/issues/27742 ### Regression? No, new scenario ### Known Workarounds Install .NETFramework. Make the app framework dependent on ASP.NET or WindowsDesktop. Manually deploy a resource DLL and write a registry key. ### Configuration Windows, SKUs without .NETFramework ### Other information _No response_

Author:	ericstj
Assignees:	-
Labels:	`area-Single-File`, `untriaged`
Milestone:	-

[vitek-karas]

One way to fix this would be to build System.Diagnostics.EventLog.Messages.dll as a native dll. There's no need for it to be a managed assembly, it's main purpose is to store Win32 resources, it has not code in it. I assume it's a managed .dll because it was easy to build it that way.

Single-file will by default leave native libraries next to the exe - they won't be bundled. Only if they are bundled then we would run into this problem, all that would mean is we would have to be able to locate the file (there are solutions for that) - but it would always be a file on disk (we don't have the ability to bundle native dlls without extraction).

[agocke]

I think it is a native DLL actually. So this would only be a problem in two cases: extraction, and maybe in FX-dependent if we don't look in the runtime directory (I hope we do).

[agocke]

This might be another thing to look at if we build a WindowsDesktop-specific host.

[vitek-karas]

I'm pretty sure it's managed: https://github.com/dotnet/runtime/blob/main/src/libraries/System.Diagnostics.EventLog/src/Messages/System.Diagnostics.EventLog.Messages.csproj (I also checked the file from the NuGet package and ILSpy sees it as managed assembly)