[release/5.0] Fix EventLog on Windows ARM64 #46598
Conversation
* Make EventLog work without .NETFramework * Use a project file instead of targets to create message DLL * Add EventLogMessagesTests * Address feedback * Exclude EventLogMessage tests on net48 * Apply code review feedback Also fix one test which would fail on machine without .NETFramework. * Fix HelpLink test
Update assembly version of EventLog package and build it in servicing. Also update the package baseline to ensure that Windows.Compatibility package gets the new version.
|
Tagging subscribers to this area: @tommcdon, @krwq Issue DetailsBackport of #45884 to release/5.0 Fixes: #27742 Customer ImpactWhen writing to EventLog on a machine without .NETFramework installed messages would be missing their format DLL which is required. The result was that both in both the Event Viewer and in the message returned by our APIs the message would be shown as: Followed by the actual message string, when the expectation is that it will only contain the actual message string. Regression?No, new architecture (though seen as a regression from .NETFramework/other architectures) TestingAdded automated tests that validated the content of the message. Forced these tests to fail and then ensured they passed with fix. Validate the content of the newly added resource dll. Manual testing to simulate missing .NETFramework. RiskLow. We are growing the size of the package and the application by a small amount by adding a resource DLL but folks who decide they do not want it can choose to remove it from their application and this API will work as before. We've also chosen to keep precedence for the .NETFramework DLL, if it is present, so as not to introduce a new DLL load into existing functional applications in servicing.
|
5.0 infra doesn't traverse runtime-specific TFMs during restore. Workaround by referencing Message project everywhere, and only including it in package on windows.
Anipik
added
the
NO-MERGE
leecow
added
Servicing-approved
|
@Anipik this was approved - is it still "no merge"? |
|
Oh - I recall -it's because we're checking with aspnet about potential impact of a new file. |
Anipik
removed
the
NO-MERGE
ghost
locked as resolved and limited conversation to collaborators
Backport of #45884 to release/5.0
Fixes: #27742
Customer Impact
When writing to EventLog on a machine without .NETFramework installed messages would be missing their format DLL which is required. The result was that both in both the Event Viewer and in the message returned by our APIs the message would be shown as:
Followed by the actual message string, when the expectation is that it will only contain the actual message string.
Regression?
No, new architecture (though seen as a regression from .NETFramework/other architectures)
Testing
Added automated tests that validated the content of the message. Forced these tests to fail and then ensured they passed with fix. Validate the content of the newly added resource dll. Manual testing to simulate missing .NETFramework.
Risk
Low. We are growing the size of the package and the application by a small amount by adding a resource DLL but folks who decide they do not want it can choose to remove it from their application and this API will work as before. We've also chosen to keep precedence for the .NETFramework DLL, if it is present, so as not to introduce a new DLL load into existing functional applications in servicing.