Skip to content
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.

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

AppDomain.CurrentDomain.BaseDirectory is directory nunit-agent.exe #1313

Closed
MDcod opened this issue Feb 5, 2023 · 7 comments
Closed

AppDomain.CurrentDomain.BaseDirectory is directory nunit-agent.exe #1313

MDcod opened this issue Feb 5, 2023 · 7 comments

Comments

@MDcod
Copy link

MDcod commented Feb 5, 2023

Hello! I think you are aware of this behavior. But just in case, one more time.

When running a test from nunit3-console. The value of AppDomain.CurrentDomain.BaseDirectory in the test will be the path to the directory from where the console runner is essentially launched.

I have seen many people mention this feature in issues. But I didn't see any workaround for this.
I can't use TestContext because the call to AppDomain.CurrentDomain.BaseDirectory is used in a third-party library.

About csproj:

  • net6.0
  • nuget Nunit v3.13.3
  • nuget NUnit3TestAdapter v4.3.1

Command
C:\NUnit.Console-3.16.2\bin\nunit3-console.exe C:\src\solution\Ttest.Project\bin\Test.Project.dll --where id=1-1002
Value of AppDomain.CurrentDomain.BaseDirectory
C:\NUnit.Console-3.16.2\bin\agents\net6.0\

Questions:

  • Please let me know if there is a workaround.
  • Are there any plans to fix this behavior?
@MDcod
Copy link
Author

MDcod commented Feb 10, 2023

There are not workarounds?

@stevenaw
Copy link
Member

Can you explain a bit about what you are trying to accomplish by changing the base directory and what you've tried so far? We'll need a bit more info to better understand and help.

As a general piece of advice, there are some work arounds and code samples listed in here which may help for your use case: nunit/nunit#1072

And there's some command line options which may help depending on what you're trying to do (for example, --work or --out) : https://docs.nunit.org/articles/nunit/running-tests/Console-Command-Line.html

@CharliePoole
Copy link
Member

@stevenaw NUnit traditionally ran tests in a separate AppDomain, which it created. The .NET Framework agents still do that. You can find the key code in the DomainManager class. That class is only built for .NET Framework. The .NET Core agents all run tests in the primary AppDomain.

Historically, this is due to the fact that our first runners for .NET Core were dealing with versions 1.0 and 1.1, where almost none of the features of AppDomain were available. Research is needed to figure out a way to set a separate base directory for the tests run by a .NET Core agent and resolve this. It may be through AppDomain or possibly in some other way.

I'm going to create an identical issue to this one in the TestCentric Gui because the same problem exists there. I'll post or link here if I figure something out. If you take this on, feel free to consult me offline.

@CharliePoole
Copy link
Member

I'm wondering why a .NET 6.0 test assembly, is expecting there to be more than one AppDomain in a process... i.e. the primary AppDomain. Perhaps this is not a bug at all.

Is this an x/y problem? Why do you need the ApplicationBase to match the current test assembly?

@ueli-werner
Copy link

We have switched to dotnet test where the behaviour is still correct.

@CharliePoole
Copy link
Member

CharliePoole commented Jun 5, 2024

I'm pretty much convinced that this is not a bug.

  1. AppDomains are somewhat minimally supported in .NET Core. In particular, they cannot be created.
  2. As a result, all code runs in the primary AppDomain of the process hosting it.
  3. Consequently, no .NET Core test assembly being executed by a test runner should expect the ApplicationBase to be anything other than that of the primary AppDomain.
  4. In addition, any assembly referenced by the test assembly will also be a .NET Core or Standard assembly, so the same limitations apply to it.

@OsirisTerje I'm inclined to close this. Do you want any others on the team to review it first?

@mikkelbu
Copy link
Member

mikkelbu commented Jun 5, 2024

Personally, I think it is fine to close this issue

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants