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

Compile test dll which is loaded in TestCentric - Cannot compile because it's being used by another process #1186

Open
rowo360 opened this issue Feb 12, 2025 · 4 comments
Labels
Bug Something isn't working as expected.

Comments

@rowo360
Copy link
Contributor

rowo360 commented Feb 12, 2025

Describe the bug
While developing some NUnit tests in Visual Studio, I already opened the test dll in TestCentric and ran the tests to confirm that the tests are working as expected.
However when editing and compiling the NUnit tests again, Visual Studio complains that the dll cannot be generated because the dll is used by another process. Visual Studio even provides a list of processes: it's the Net462 Pluggable Agent process and sometimes in addition also the TestCentric Runner process.

This happens very frequently or almost all the time. However the TestCentric Runner process is only listed sometimes, I didn't figure out yet when it happens. In that case it's not sufficient to close the test project in TestCentric, but I must close TestCentric completly.

ShadowCopy is enabled - here's a screenshot from the settings:

To Reproduce
Steps to reproduce the behavior:

  1. Load test project
  2. Run tests
  3. Switch back to Code editor and edit+compile test project
  4. Error => test dll is being used by another process

Environment (please complete the following information):

  • TestCentric Version: Version:2.0.0-beta6
  • OS: Windows 11
  • Target Runtime for your test assembly: .NET Framework 4.8
@rowo360 rowo360 added the Bug Something isn't working as expected. label Feb 12, 2025
@rowo360
Copy link
Contributor Author

rowo360 commented Feb 12, 2025

I made a few attempts to find out something about this problem, but I guess I need some guidance here. At least to tackle down this problem and to provide some hints about the root cause.

For example I debugged into the TestCentric.Agent.Core process to find out which component is responsible for the assembly loading. I finally came accross the NUnit3FrameworkDriver class and its Load method. I think that is the correct location, isn't it? However I wonder about the Assembly.LoadFrom(...) statement and whether the new AppDomain is used here at all?

@rowo360
Copy link
Contributor Author

rowo360 commented Feb 12, 2025

And I don't really understand at all, how the 'Testcentric Runner' process is blocking the test assembly. I didn't spot any assembly loading code there and also debugging + listing all loaded assemblies (AppDomain.GetAssemblies()) didn't show up the test assembly.

@rowo360
Copy link
Contributor Author

rowo360 commented Feb 19, 2025

Over the last few days, I have looked at this assembly loading stuff, compared with TestCentric 1.X, tried out a few things and overall learned a lot. Therefore I can state now, that it's a TestCentric.Agent issue. Maybe it's best to move this issue to the TestCentric.Agent project? And yes of course, it's specific to .NET Framework 4.8

The crucial part is in the class NUnit3FrameworkDriver and the _testAssembly = Assembly.LoadFrom(testAssemblyPath); statement which loads the test assembly in the agent process. With this statement the assembly is blocked for any changes (for example rebuild), because there's no separate AppDomain and no ShadowCopy involved at all.

I spotted in the history this commit Changes to NUnit3Driver which introduced this Assembly.LoadFrom() statement.
For testing purpose I restored the previous NUnit3FrameworkDriver version and yes indeed, the current problem would be solved.

That would be a solution, but we would certainly get other problems again, because this change was also made with a purpose, wasn't it?

I made one attempt to solve this issue by keeping the current implementation and only restoring the crucial parts from the previous version. That worked - which is fine. But it's important to decide which code part to keep and which part is OK to restore. I think I need some guidance here. For now I thought that I need to remove the Assembly.LoadForm() and need to restore the _testDomain.CreateInstanceAndUnwrap() statement. But one idea might be that I create a PR for this proposal and we discuss it on the concrete code level.

@CharliePoole: Thanks for your input how to proceed best!

@CharliePoole
Copy link
Contributor

I hadn't noticed this issue before this morning. I'll take a look at it sometime today.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Something isn't working as expected.
Projects
None yet
Development

No branches or pull requests

2 participants