Could not load file or assembly error, unittest project not build

Hi,

Bug report:

Just installed NCrunch to give it a try. But encountering a build problem:

In a solution of 61 projects this is the error for one assembly that pops up:

--
NCrunch: If you are experiencing problems in getting this project to build, have a look at https://www.ncrunch.net/documentation/troubleshooting_project-build-issues
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\TeamTest\Microsoft.TeamTest.targets (14)#1: Could not load file or assembly 'Haddock.Business.Product, Version=2.9.0.7591, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
--

It seems to be saying this for the unittest-project that references all the other projects in the solution.
This means that the UnitTest project is unable to build.

NCrunch also mentions:
--
This component makes use of MS Test private method accessors, which require referenced assemblies to be copied to the component build output directory. This will have an impact on the performance of NCrunch, as extra work must be done to rebuild this component every time one of its dependencies changes.
--


We have actually "solved" this issue by configuration of NCrunch to switch the copy local attribute for ALL projects in the solution. Problem with this is that it takes NCrunch to a halt, it is far too slow.

Other interesting things that might be of interest:
- All csproj files are in its own subfolder, solution is in the main folder.
- Within the csproj files, we have deliberately inluded a small XML files which states what the SHARED output folder is like this:

<Import Project="$(SolutionDir)\SharedConfig.xml" />

The SharedConfig.xml contains something like this:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="3.5" xmlns="(- BROKEN LINK -)">
<PropertyGroup>
<OutputPath>$(SolutionDir)BUILD</OutputPath>
<WarningLevel>4</WarningLevel>
<UseVSHostingProcess>false</UseVSHostingProcess>
<TreatWarningsAsErrors>false</TreatWarningsAsErrors>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
<OutputPath>$(SolutionDir)BUILD\DEBUG</OutputPath>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<OutputPath>$(SolutionDir)BUILD\RELEASE</OutputPath>
</PropertyGroup>
</Project>


This might of course not related to the problem, but it might be, not sure?

What we also tried is to create a separate solution with the mentioned project (and all the projects it referenced) and NCrunch than works, but

What other information might we provide to solve this issue so that we can use NCrunch without having to copy-local everything?

Thanks,

Hi, thanks for posting!

I wish I could give you a better solution than needing to enable the 'Copy referenced assemblies to workspace' option (which you've already discovered), but unfortunately there is a very solid technical limitation around the way that MSTest accessors work during the build process. The build step required for the MSTest private method accessors physically requires referenced assemblies to exist in the same output directory as the test assembly. This constraint means that NCrunch isn't able to perform build optimisations as the test project must be rebuilt for any change further down the dependency tree.

So I'm afraid the only other option I can give you is to stop using MSTest accessors.


Cheers,

Remco

Remco wrote:Hi, thanks for posting!

I wish I could give you a better solution than needing to enable the 'Copy referenced assemblies to workspace' option (which you've already discovered), but unfortunately there is a very solid technical limitation around the way that MSTest accessors work during the build process. The build step required for the MSTest private method accessors physically requires referenced assemblies to exist in the same output directory as the test assembly. This constraint means that NCrunch isn't able to perform build optimisations as the test project must be rebuilt for any change further down the dependency tree.

So I'm afraid the only other option I can give you is to stop using MSTest accessors.


Cheers,

Remco

Not sure if I understand the problem. Actually, we are already letting Visual Studio output all binaries to the same output directory, so why would this problem be there for our case? All the projects have the sharedconfig.xml included so are outputed to the same output folder, right?

Also, personally I am not sure what MSTest private accessors are at the moment (but will look that up)

Remco wrote:Hi, thanks for posting!

I wish I could give you a better solution than needing to enable the 'Copy referenced assemblies to workspace' option (which you've already discovered), but unfortunately there is a very solid technical limitation around the way that MSTest accessors work during the build process. The build step required for the MSTest private method accessors physically requires referenced assemblies to exist in the same output directory as the test assembly. This constraint means that NCrunch isn't able to perform build optimisations as the test project must be rebuilt for any change further down the dependency tree.

So I'm afraid the only other option I can give you is to stop using MSTest accessors.


Cheers,

Remco

Hi Remco! Ok we removed the MSTest private accessor, it indeed existed for the haddock.business.product project.

Now the unittest project is building but gives the following exception:

--
NCrunch: If you are experiencing problems in getting this project to build, have a look at https://www.ncrunch.net/documentation/troubleshooting_project-build-issues
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\TeamTest\Microsoft.TeamTest.targets (14)#1: The "BuildShadowTask" task failed unexpectedly.
System.NullReferenceException: Object reference not set to an instance of an object.
at Microsoft.VisualStudio.TestTools.BuildShadowReferences.BuildShadowTask.Execute()
at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask(ITaskExecutionHost taskExecutionHost, TaskLoggingContext taskLoggingContext, TaskHost taskHost, ItemBucket bucket, TaskExecutionMode howToExecuteTask, Boolean& taskResult)
--

What would this mean?

Melle wrote:

Remco wrote:Hi, thanks for posting!

I wish I could give you a better solution than needing to enable the 'Copy referenced assemblies to workspace' option (which you've already discovered), but unfortunately there is a very solid technical limitation around the way that MSTest accessors work during the build process. The build step required for the MSTest private method accessors physically requires referenced assemblies to exist in the same output directory as the test assembly. This constraint means that NCrunch isn't able to perform build optimisations as the test project must be rebuilt for any change further down the dependency tree.

So I'm afraid the only other option I can give you is to stop using MSTest accessors.


Cheers,

Remco

Hi Remco! Ok we removed the MSTest private accessor, it indeed existed for the haddock.business.product project.

Now the unittest project is building but gives the following exception:

--
NCrunch: If you are experiencing problems in getting this project to build, have a look at https://www.ncrunch.net/documentation/troubleshooting_project-build-issues
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\TeamTest\Microsoft.TeamTest.targets (14)#1: The "BuildShadowTask" task failed unexpectedly.
System.NullReferenceException: Object reference not set to an instance of an object.
at Microsoft.VisualStudio.TestTools.BuildShadowReferences.BuildShadowTask.Execute()
at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask(ITaskExecutionHost taskExecutionHost, TaskLoggingContext taskLoggingContext, TaskHost taskHost, ItemBucket bucket, TaskExecutionMode howToExecuteTask, Boolean& taskResult)
--

What would this mean?

Ok: sorry, had to remove the Private Accessor from the solution as well, and now NCrunch is happily zooming... will give some more feedback later..

Thanks so far!

Thanks, glad you managed to work it out! And nice going for removing the private accessors. They are problematic for reasons far beyond NCrunch.