Behavior around unused references different from MSTest

Hi,

We hit a weird issue this morning where our test was running fine under nCrunch, but would fait with resharper or mstest. It turned out that a required DLL that is referenced in the project was copied over by nCrunch, but not mstest.

This dll is referenced in our project, but is never used directly. It is only used in the app.config to drive unity (yes, we'll leave the xml-based config of unity soon enough). MSTest sees the reference, but sees no use of it (no "using" i assume); therefore it won't copy it over. It's optimization... i guess.

While I agree this is a bad behavior on mstest's part, it would be nice if nCrunch would warn you about it so that our CI runs fine.

Here is an example (we use unity, but let's make it simpler) :

In a test project, add a reference to an other project in you solution (let's call those A.Tests and A).

Now, in a test class in A.Tests, do something like :

Activator.CreateInstance("A", "A.Namepsace.AClass");

However, never directly call a class in A, never import it or anything. If you only indirectly use the classes in A, MSTest will "optimize" things and remove A from the output folder. Activator will then try to find it and you will get an ugly error of type System.IO.FileNotFoundException. I would have pasted the output here, but it's all in french so I guess this is useless.

Here are some guys (girls too, maybe) who had the same issue : http://stackoverflow.com/questions/10486113/why-mstest-does-not-copy-referenced-project-libraries

Hope this is clear!

Thanks,
Jni

Hi Jni,

Thanks for sharing this issue. I can see how the behaviour of NCrunch in this situation could lead to builds failing, and a warning would be a useful thing to have.

Because of the way the NCrunch test environment is built, I have a feeling that it will be very challenging to implement anything that could issue a reliable warning in this sort of situation, but I'll have a bit of a think about ways this might be done.


Cheers,

Remco

Hi,

This is what I expected, it is indeed hard to mimic this behavior. However, I would look over to mstest's code (if it's open source - otherwise you would need to poke around) to see how they do it, maybe it's just a simple "grep (imports|using) <namespace>" and it would be easy to reproduce this. If they really build a dependency tree, this might get tricky though.

In any case, if you implement this in a "dumb" way, it is still better than nothing. A warning that says "MAYBE you will have trouble, try it with the mstest runner" would be better than nothing I think. Even though you don't always get it right, it would still help.

Thanks again,
Jni