exePath_UserLevelNone failing when testing against source-build config

[tmds]

In our internal CI, the exePath_UserLevelNone test is failing on the main branch.

The stacktrace looks as follows:

System.Configuration.ConfigurationErrorsException: System.Configuration.ConfigurationErrorsException : An error occurred loading a configuration file: The parameter 'exePath' is invalid. (Parameter 'exePath')\n---- System.ArgumentException : The parameter 'exePath' is invalid. (Parameter 'exePath')
        at System.Configuration.ConfigurationSchemaErrors.ThrowIfErrors(Boolean ignoreLocal) in /home/tester/runtime/src/libraries/System.Configuration.ConfigurationManager/src/System/Configuration/ConfigurationSchemaErrors.cs:line 71
at System.Configuration.BaseConfigurationRecord.ThrowIfParseErrors(ConfigurationSchemaErrors schemaErrors) in /home/tester/runtime/src/libraries/System.Configuration.ConfigurationManager/src/System/Configuration/BaseConfigurationRecord.cs:line 3640
at System.Configuration.BaseConfigurationRecord.ThrowIfInitErrors() in /home/tester/runtime/src/libraries/System.Configuration.ConfigurationManager/src/System/Configuration/BaseConfigurationRecord.cs:line 258
at System.Configuration.Configuration..ctor(String locationSubPath, Type typeConfigHost, Object[] hostInitConfigurationParams) in /home/tester/runtime/src/libraries/System.Configuration.ConfigurationManager/src/System/Configuration/Configuration.cs:line 75
at System.Configuration.ClientConfigurationHost.OpenExeConfiguration(ConfigurationFileMap fileMap, Boolean isMachine, ConfigurationUserLevel userLevel, String exePath) in /home/tester/runtime/src/libraries/System.Configuration.ConfigurationManager/src/System/Configuration/ClientConfigurationHost.cs:line 485
at System.Configuration.ConfigurationManager.OpenExeConfigurationImpl(ConfigurationFileMap fileMap, Boolean isMachine, ConfigurationUserLevel userLevel, String exePath, Boolean preLoad) in /home/tester/runtime/src/libraries/System.Configuration.ConfigurationManager/src/System/Configuration/ConfigurationManager.cs:line 214
at System.Configuration.ConfigurationManager.OpenExeConfiguration(String exePath) in /home/tester/runtime/src/libraries/System.Configuration.ConfigurationManager/src/System/Configuration/ConfigurationManager.cs:line 186
at MonoTests.System.Configuration.ConfigurationManagerTest.exePath_UserLevelNone() in /home/tester/runtime/src/libraries/System.Configuration.ConfigurationManager/tests/Mono/ConfigurationManagerTest.cs:line 139
at System.RuntimeMethodHandle.InvokeMethod(Object target, Void** arguments, Signature sig, Boolean isConstructor)
at System.Reflection.MethodBaseInvoker.InvokeWithNoArgs(Object obj, BindingFlags invokeAttr) in /home/tester/runtime/src/libraries/System.Private.CoreLib/src/System/Reflection/MethodBaseInvoker.cs:line 57
----- Inner Stack Trace -----
at System.Configuration.ClientConfigPaths..ctor(String exePath, Boolean includeUserConfig) in /home/tester/runtime/src/libraries/System.Configuration.ConfigurationManager/src/System/Configuration/ClientConfigPaths.cs:line 49
at System.Configuration.ClientConfigPaths.GetPaths(String exePath, Boolean includeUserConfig) in /home/tester/runtime/src/libraries/System.Configuration.ConfigurationManager/src/System/Configuration/ClientConfigPaths.cs:line 208
at System.Configuration.ClientConfigurationHost.get_ConfigPaths() in /home/tester/runtime/src/libraries/System.Configuration.ConfigurationManager/src/System/Configuration/ClientConfigurationHost.cs:line 40
at System.Configuration.ClientConfigurationHost.GetStreamName(String configPath) in /home/tester/runtime/src/libraries/System.Configuration.ConfigurationManager/src/System/Configuration/ClientConfigurationHost.cs:line 244
at System.Configuration.Internal.DelegatingConfigHost.GetStreamName(String configPath) in /home/tester/runtime/src/libraries/System.Configuration.ConfigurationManager/src/System/Configuration/Internal/DelegatingConfigHost.cs:line 70
at System.Configuration.Internal.DelegatingConfigHost.GetStreamName(String configPath) in /home/tester/runtime/src/libraries/System.Configuration.ConfigurationManager/src/System/Configuration/Internal/DelegatingConfigHost.cs:line 70
at System.Configuration.ImplicitMachineConfigHost.GetStreamName(String configPath) in /home/tester/runtime/src/libraries/System.Configuration.ConfigurationManager/src/System/Configuration/ImplicitMachineConfigHost.cs:line 48
at System.Configuration.BaseConfigurationRecord.InitConfigFromFile() in /home/tester/runtime/src/libraries/System.Configuration.ConfigurationManager/src/System/Configuration/BaseConfigurationRecord.cs:line 551

From looking through some CI logs: 5fd3f22 is good, and ef0c712 is bad.

The test failure happens on the main branch. The test is passing on the 9.0 branch.

cc @ViktorHofer @omajid

[dotnet-policy-service]

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

[steveharter]

The test failing on Mono:

at MonoTests.System.Configuration.ConfigurationManagerTest.exePath_UserLevelNone() in /home/tester/runtime/src/libraries/System.Configuration.ConfigurationManager/tests/Mono/ConfigurationManagerTest.cs:line 139

runtime/src/libraries/System.Configuration.ConfigurationManager/tests/Mono/ConfigurationManagerTest.cs

Line 139 in 81efcad

SysConfig config = ConfigurationManager.OpenExeConfiguration(name);

[tmds]

Although there is Mono in the name, the test also runs and fails with CoreCLR.

[steveharter]

I see - those are probably tests ported from Mono.

On the "bad" commit ef0c712 I don't see where the failure happened. I see 11\21 success and when I click on that, I see 5 test failures - is it the "runtime-libraries stress-http" one that failed (no build available any longer)?

[tmds]

The CI failure happens on our internal CI which builds the runtime repo in a source-build configuration including tests, and then executes test. I assume this is a test bug that only exists in that configuration.

I will look into this further. I opened up an issue in case someone might have an idea what triggered the regression.

[tmds]

I looked closer at this test, in our CI it gets invoked as:

/home/tester/runtime/artifacts/bin/testhost/net10.0-linux-Debug-x64/dotnet exec --runtimeconfig System.Runtime.Caching.Tests.runtimeconfig.json --depsfile System.Runtime.Caching.Tests.deps.json /home/tester/.nuget/packages/microsoft.dotnet.xunitconsolerunner/2.9.2-beta.25080.7/build/../tools/net/xunit.console.dll System.Runtime.Caching.Tests.dll -xml testResults.xml -nologo -notrait category=IgnoreForCI -notrait category=OuterLoop -notrait category=failing 
  popd

The exePath that shows up in the exception is the path that is determined here:

runtime/src/libraries/System.Configuration.ConfigurationManager/tests/Mono/TestUtil.cs

Lines 57 to 64 in 27f045d

	public static string ThisApplicationPath
	{
	get
	{
	return Path.Combine(AppDomain.CurrentDomain.BaseDirectory,
	Assembly.GetEntryAssembly().ManifestModule.Name);
	}
	}

This causes it to try and find the xunit.console.dll at artifacts/bin/System.Configuration.ConfigurationManager.Tests/Debug/net10.0/ where there is no such dll. I believe it should be finding the dll that is passed as the argument to dotnet exec.

This code was changed long long ago in dotnet/corefx#21006.

I assume that change is about the Assembly.GetEntryAssembly().ManifestModule.Name.

I think the directory should be Path.GetDirectoryName of the Assembly.GetEntryAssembly().Location instead of AppDomain.CurrentDomain.BaseDirectory that is used now.

@ViktorHofer @steveharter does that make sense?