NUnit [TearDown] fails — what process is accessing my files?

Question

Final Edit: I found a solution to the problem (at the bottom of the question).

I\'ve got an Nunit problem that\'s causing me grief. Edit:

Answer 1

Tear down is executed after each test.

This attribute is used inside a TestFixture to provide a common set of functions that are performed after each test method is run.

You should try to delete them all with TestFixtureTearDown:

    [TestFixtureTearDown]
    public void finish()
    {
        //Delete all file
    }

Maybe one test is using the file that you try to delete in an other test. <-- [Stewart] As I stated in the question, it happens when I run only one test, so this isn't possible.

Update You do not give enough information about what you are doing. Have you try to clean up all the Test file with only 1 test in your test file and try it? [Stewart] Yes. If it works [Stewart] (it doesn't) then it's that you have multiple test problem (they access each other). You need to cut down the problem to find the source. Then, come back here we will help you. for the moment it's only guessing that we can give you. [Stewart] I have already done these cut-downs of the problem that you suggest, you'll find that they're in my original question!

Answer 2

Is it possible that the file is in the process of being closed (I.e. SQLLite doesn't release it immediately)?

You could try putting the db close in a delay loop, (maybe one second between each attempt), and only throwing the exception after a few (5 or so) iterations through the loop.

Answer 3

Thanks for pointing this out!

The problem is not related to SQLite, but rather to memory management in general. After your test has run, the objects pointing to files have no scope anymore, but they still exist in memory.

Hence, there's still references to the files and you can't delete / move them.

Answer 4

Thanks for the posted answer at the bottom. I was digging for hours for exactly the same case and

GC.Collect ();
GC.WaitForPendingFinalizers ();

did the trick.

Answer 5

First step would be to find who is holding a handle to the file in question.

Get a copy of Process Explorer Run it. Press Ctrl+F and enter the name of the file. It would show you a list of processes accessing it.

Answer 6

Do you have Antivirus running? Some AV products scan the file when they see them being closed. If the AV software still has the file open when you come to delete it, you'll see this problem. You could retry the delete after a small delay.

I've also seen this happen with search indexers.