2

We have recently taken over a project from an outsourcing company. This project uses Moles and Pex for unit testing, but since we have not had the project for long, I am not very familiar with the frameworks.

That being said, we are busy upgrading this project to run in .Net 4. I have resolved most of the issues that have jumped out, but there is one that I cannot get a handle on. Some of the unit tests cannot compile because of the error:

Could not load file or assembly 'Example.Assembly, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.

The part that baffles me is that it is a project reference and the assembly is being copied to the output directory of the unit test. Most of the other project references are found and I cannot spot any difference between the ones that work and the ones that do not. I am not sure if this problem has to do with the pex/moles frameworks, but I thought I would mention it.

I have tried the usual things of removing and adding all the references and regenerating the moles assemblies.

Has anyone else run into this problem? Any help would be greatly appreciated.

EDIT1: Ok, after some more investigation into the build output, it appears as if it is not moles, but the .accessor files that are not generated correctly. I get the exact same problem as asked in Unit test project cannot find assembly under test (or dependencies), but unlike his problem, mine does not go away after deleting the accessor.

EDIT2: Turns out is is a program called Publicize.exe which falls over with that error. Still no idea why though. Looking at Fusion logs is looks like it does not search under the working directory for the dll that it is trying to generate the accessors for. Running it manually on a bunch of assemblies from our solution, I find it works on some, but not on others. I have not been able to identify a difference between the ones that work and the ones that don't, though.

Thanks

Community
  • 1
  • 1
knersis
  • 585
  • 5
  • 13

1 Answers1

0

Ah, yes. I have read this story many times, and have the tee shirt. I run through my usual Moles first-aid kit, when encountering any issue, including this one.

Perhaps, this question will provide some help: Am I the only one getting "Assembly Not Available in the Currently Targeted Framework"?

  • Ensure the Moles framework is properly installed on the workstation and/or build server
  • Ensure the Moles assemblies are being built (see the excluded "Moles Assemblies" directory)
  • Check your build profile -- it may need to be set to full framework profile
  • Triple check your output destinations and post-build commands -- I have seems some solutions that copy the output to another location
  • Try using the Visual Studio Pex/Moles extension, if you are not already doing so

An invasive fix-all process is to simply create an all-new solution, projects, and test projects, and then copy the existing code files into them. It's surprising how many issues can be resolved for various project-related errors. Basically, a hard reboot for the entire solution.

Since you are updating to .NET 4, you may as well go to 4.5, and used the productized version of Moles, called "Fakes". You'll find Fakes in the Visual Studio 2012 release candidate. This significant feature hasn't received much attention.

Community
  • 1
  • 1
Mike Christian
  • 1,526
  • 1
  • 15
  • 27
  • It seemed that it was the private accessor generation that fell over, not the moles. Since that is basically deprecated software, I have disabled the tests that make use of it. Will re-implement them at a later stage by not accessing private variables. – knersis Jul 05 '12 at 15:18
  • That is a good idea. I am converting projects to current technology, as I encounter them. – Mike Christian Jul 09 '12 at 17:27