Skip to content

System.Configuration.ConfigurationManager.Tests: use Assembly.Location to determine ThisApplicationPath. #112231

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Feb 10, 2025
Merged

System.Configuration.ConfigurationManager.Tests: use Assembly.Location to determine ThisApplicationPath. #112231

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
95657bb
System.Configuration.ConfigurationManager.Tests: use Assembly.Locatio…
tmds Feb 6, 2025
691f6cd
Remove exePath_UserLevelNone test.
tmds Feb 10, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 4 additions & 2 deletions src/libraries/System.Configuration.ConfigurationManager/tests/Mono/TestUtil.cs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -58,8 +58,10 @@ public static string ThisApplicationPath
{
get
{
return Path.Combine(AppDomain.CurrentDomain.BaseDirectory,
Assembly.GetEntryAssembly().ManifestModule.Name);
Assembly assembly = Assembly.GetEntryAssembly();
string directory = Path.GetDirectoryName(assembly.Location);
Copy link
Member

@jkotas jkotas Feb 6, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BaseDirectory is typically the directory of the entry assembly. Where is the difference in your test environment come from? Are you running the tests in some kind of atypical setup that makes BaseDirectory different from entry assembly?

Copy link
Member Author

@tmds tmds Feb 6, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is as invoked from top-level build.sh with the --test argument.

The invocation ends up looking something like:

/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

The xunit.console.dll is not in the BaseDirectory (as shown on the command line, it comes from .nuget/packages).

This code was changed long ago in https://github.com/dotnet/corefx/pull/21006/files. I assume that change was more about the ManifestModule.Name than it was about changing to use the BaseDirectory.

Copy link
Member

@jkotas jkotas Feb 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was done originally to make the test compatible with single file form factors. The description of the old PR that you have linked says that it is fixing the tests for uap-aot (aka .NET Native) that was the first single file form factor.

The problem with single file is that Assembly.Location returns empty string.

I think it would be best to delete the ThisApplicationPath property and the one test that uses it. There are other more comprehensive tests OpenExeConfiguration2 and OpenExeConfiguration2_ExePath_DoesNotExist to exercise this scenario. These other tests create the files in known locations and so they do not depend on the deployment details that may change over time.

Copy link
Member Author

@tmds tmds Feb 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your insights! I've removed the test.

string fileName = assembly.ManifestModule.Name;
return Path.Combine(directory, fileName);
}
}

Expand Down
Loading