Fix SendPacketsAsync failures on macos

[antonfirsov]

While looking at the Windows failures reported in #62384, #60267, #60204, #60017 I noticed a bunch of new MacOS failures starting from 2021-12-08, which all report UnauthorizedAccessException

By default, LocalAppData is undefined on Unix, the following line will actually reference to a file named \NCLTest.Socket.SendPacketsAsync.testpayload in the working directory of the test execution process:

runtime/src/libraries/System.Net.Sockets/tests/FunctionalTests/SendPacketsAsync.cs

Line 23 in a8c2d1e

private string TestFileName = Environment.GetEnvironmentVariable("LocalAppData") + @"\NCLTest.Socket.SendPacketsAsync.testpayload";

On CI it's a known folder so the path points to stuff like /private/tmp/helix/working/A48D0921/w/C66409E5/e/System.Net.Sockets.Tests.app/Contents/Resources/\NCLTest.Socket.SendPacketsAsync.testpayload on Helix Macs. I'm not sure what goes wrong with the access to the above path, but I believe it's better to use the preferred TempFile utility to create temporary files, and this change will likely fix the UnauthorizedAccessException, since other tests using TempFile seem to be healthy right now.

Also changing the test to use the standard xunit test output instead of the legacy TestLogging.GetInstance().

[ghost]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

While looking at the Windows failures reported in #62384, #60267, #60204, #60017 I noticed a bunch of new MacOS failures starting from 2021-12-08, which all report UnauthorizedAccessException

By default, LocalAppData is undefined on Unix, the following line will actually reference to a file named \NCLTest.Socket.SendPacketsAsync.testpayload in the working directory of the test execution process:

runtime/src/libraries/System.Net.Sockets/tests/FunctionalTests/SendPacketsAsync.cs

Line 23 in a8c2d1e

private string TestFileName = Environment.GetEnvironmentVariable("LocalAppData") + @"\NCLTest.Socket.SendPacketsAsync.testpayload";

On CI it's a known folder so the path points to stuff like /private/tmp/helix/working/A48D0921/w/C66409E5/e/System.Net.Sockets.Tests.app/Contents/Resources/\NCLTest.Socket.SendPacketsAsync.testpayload on Helix Macs. I'm not sure what goes wrong with the access to the above folder, but I believe it's better to use the preferred TempFile utility to create temporary files, and this change will likely fix the UnauthorizedAccessException, since other tests using TempFile seem to be healthy right now.

Also changing the test to use the standard xunit test output instead of the legacy TestLogging.GetInstance().

Author:	antonfirsov
Assignees:	-
Labels:	area-System.Net.Sockets
Milestone:	-

[wfurt]

One good aspect of the current approach is that Helix can cleanup on test or other failures. Since the run directory is unique this is very easy. I don't know if Helix actually does: cc @MattGal
Using TempFile.Create has potential of filling up temp space.
File name starting with '' seems weird but I don't know if that is relevant.

[antonfirsov]

Unless there is a hang or a crash, TempFile.Dispose() should delete the file after every test run:

runtime/src/libraries/System.Net.Sockets/tests/FunctionalTests/SendPacketsAsync.cs

Lines 41 to 44 in 68d0d02

	public void Dispose()
	{
	_tempFile.Dispose();
	}

If we want to be more robust, it should be a feature request towards Helix, so they cleanup Path.GetTempPath() after the test process finished. Plenty of BCL tests use the TempFile util especially System.IO.* stuff, I see no reason for keeping a custom approach in SendPacketsAsync.

[MattGal]

If we want to be more robust, it should be a feature request towards Helix, so they cleanup Path.GetTempPath() after the test process finished

This is already true. The Temp path is redirected per work item to a fresh path to prevent collisions from different work coming in to the machines, and this path is cleaned up after the work item finishes running. If you see this not working it would be a bug; send along some details (correlation id of job / work item details should be plenty) to the dnceng team and it will get addressed.

[wfurt]

LGTM