UnitTest project fails to build

1.37.0.46b + WinXP + VS2008 + R# 5.1

I have a solution with 2 library projects and a unit test project
The build fine in VS and R# can run the tests with no issues (using MSTest)

NCrunch builds the 2 library projects fine but fails on the unit test project with:

C:\Program Files\MSBuild\Microsoft\VisualStudio\v9.0\TeamTest\Microsoft.TeamTest.targets (14): Could not load file or assembly 'FindAddIn, Version=12.1.3.0, Culture=neutral, PublicKeyToken=17c64733a9775004' or one of its dependencies. The system cannot find the file specified.

the FindAddIn.dll is the target output for one of the library projects

After a bit of searching I found what looked like some working files in
C:\Documents and Settings\sam.mackrill\Local Settings\Application Data\NCrunch\5436\N

where N seems to increment on each build attempt

when I look in the _ncrunchreferences dir then indeed the FindAddIn.dll is missing

I have tried adding this dll in via Additional Files to Include

This creates an additional directory with the dll in

...NCrunch\5436\20\bin\Debug\FindAddIn.dll

but the build still fails :(

There is an option in the NCrunch configuration (for the unit test project) that allows you to copy the referenced assemblies to the workspace. It sounds like that could help.

But I'm sure Remco will answer with more details soon.

Hi Sam,

Thanks for posting! This problem is caused by a special build step used to generate the accessors you have defined in your test project. It's unfortunate that these accessors attempt to manipulate assemblies in such a way that prevents NCrunch's build optimisations from working properly. To get your project to build, you'll need to turn on the 'Copy referenced assemblies to workspace' option for your test project.

Cheers,

Remco

Hmmmm I am sure I tried that setting, I will try again and report back.

Update: Yes this option is definitely enabled for the test project

What happens if you enable the option for ALL of the projects in your solution?

The next thing would be to check the contents of the build output directory for your test project. You can easily find this by right clicking on the failed project in the NCrunch Tests Window, then under 'Advanced', choose to browse to the workspace containing the project. If the copy referenced assemblies setting is working correctly, you should see the dependencies of your test project existing inside the bin directory.

One step closer!
When I switch it on for all projects then it builds, however the tests then all fail with:

System.IO.FileLoadException: Could not load file or assembly 'FindAddIn, Version=12.1.3.0, Culture=neutral, PublicKeyToken=17c64733a9775004' or one of its dependencies. Strong name validation failed. (Exception from HRESULT: 0x8013141A)
File name: 'FindAddIn, Version=12.1.3.0, Culture=neutral, PublicKeyToken=17c64733a9775004' ---> System.Security.SecurityException: Strong name validation failed. (Exception from HRESULT: 0x8013141A)
The Zone of the assembly that failed was:
MyComputer
at SearchControlPresenterTests.SearchControlPresenterTest.AttributeValid_invalid_false()


Is this all caused by MSBuild messing around? Would things be cleaner using NUnit?

Something is different about the way your assembly is signed. Would you be able to submit a bug report using the 'NCrunch' menu at the top? I'll take a look at the log file and let you know how to work around it .. most likely you're using some kind of signing approach that isn't supported yet.

For anyone interested, 1.38b (released an hour ago) contains a new configuration flag that can be used to suppress the signing of assemblies during NCrunch builds. This can be used to work around issues like the one above, which may be caused by signing situations that are more complex than NCrunch was designed to handle.