Mono.Cecil is keeping DLL file handles open during tests #3288
-
|
I'm exploring migration to v3, using xunit.v3 2.0.2. We have some integration tests which dynamically load various plug-in assemblies. As part of the test set up, the tests may move or copy these plug-ins from the original location (i.e. with the test assembly ) to somewhere else. These tests passed in v2, but some are failing in v3 with a I eventually traced the source of my grief to this line, which opens handles for every DLL in the same folder as the test assembly:
I've worked around the issue by deploying the plug-ins to a different folder so they aren't in the same location as the test assembly when |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 8 replies
-
|
Yep, that's to be expected. It's necessary for us to provide source information to Visual Studio and VS Code. We opted to load every DLL because people sometimes put test base classes in an assembly other than the test assembly, so being able to provide source for a test which originated in any loadable assembly would honestly provoke fewer bug reports than assemblies being locked because they're loaded (as moving assemblies around is not a very common operation). I'll poke around in Cecil to see if there's a way not to lock the file, but I'm guessing that would end up loading everything into RAM instead, which feels like the worse end of the tradeoff. |
Beta Was this translation helpful? Give feedback.
-
|
Could the retrieval of the assembly information by Cecil be deferred until you actually load the assembly? For example, triggered by an AssemblyLoadEvent. If you never load a particular assembly, there's no need to use Cecil to read the module definition for it. |
Beta Was this translation helpful? Give feedback.
-
|
Yep, that's a possibility. I'll open an issue for it so I don't forget. 😄 |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
FYI @sheila-stewart the updated (more dynamic) |
Beta Was this translation helpful? Give feedback.
-
|
Awesome, I wasn't expecting anything this quickly. I'll give it a try! |
Beta Was this translation helpful? Give feedback.
Yep, that's to be expected. It's necessary for us to provide source information to Visual Studio and VS Code.
We opted to load every DLL because people sometimes put test base classes in an assembly other than the test assembly, so being able to provide source for a test which originated in any loadable assembly would honestly provoke fewer bug reports than assemblies being locked because they're loaded (as moving assemblies around is not a very common operation).
I'll poke around in Cecil to see if there's a way not to lock the file, but I'm guessing that would end up loading everything into RAM instead, which feels like the worse end of the tradeoff.