Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error

Could not load file or assembly error, unittest project not build
Melle
#1 Posted : Monday, July 2, 2012 1:22:05 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 7/2/2012(UTC)
Posts: 5
Location: Haarlem, the Netherlands

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/...ng_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,
Remco
#2 Posted : Tuesday, July 3, 2012 8:48:17 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,143

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
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
Melle
#5 Posted : Tuesday, July 3, 2012 10:05:42 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 7/2/2012(UTC)
Posts: 5
Location: Haarlem, the Netherlands

Remco;2333 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)
Melle
#3 Posted : Tuesday, July 3, 2012 10:50:31 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 7/2/2012(UTC)
Posts: 5
Location: Haarlem, the Netherlands

Remco;2333 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/...ng_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
#4 Posted : Tuesday, July 3, 2012 11:10:07 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 7/2/2012(UTC)
Posts: 5
Location: Haarlem, the Netherlands

Melle;2341 wrote:
Remco;2333 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/...ng_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!

Remco
#6 Posted : Tuesday, July 3, 2012 11:42:00 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,143

Thanks: 959 times
Was thanked: 1290 time(s) in 1196 post(s)
Thanks, glad you managed to work it out! And nice going for removing the private accessors. They are problematic for reasons far beyond NCrunch.
Users browsing this topic
Guest
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

YAF | YAF © 2003-2011, Yet Another Forum.NET
This page was generated in 0.072 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download