The following assembly references have triggered this warning:
My:\path\bin\Debug\FakeItEasy.dll
<Reference Include="FakeItEasy, Version=1.7.4626.65, Culture=neutral, PublicKeyToken=eff28e2146d5fd2c, processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
<HintPath>..\packages\FakeItEasy.1.7.4626.65\lib\NET40\FakeItEasy.dll</HintPath>
</Reference>
Build/Test Issues
Incorrect "Assemblies are being referenced from the build output"
Started by Jonh04 on 5,661 views
Remco NCrunch Developer
#3598
25 Jan 2013 22:33 UTC
Hi,
This message is kicked up by NCrunch when a referenced assembly resolved from MSBuild is being pulled from the same directory as one of the build outputs from another project. It analyses the physical output from MSBuild during a build of your project, and should be very accurate.
Note that MSBuild has enormous amounts of implicit logic when resolving references. For example, the 'HintPath' shown above is only a suggestion to the resolution that there may be an assembly at the location specified - it isn't considered a hard fact. If the file doesn't exist in the suggested location, MSBuild will continue to search around a large list of potential other locations in order to find the file. This means that MSBuild assembly resolution uses a 'best effort' approach in finding assemblies.
You can gain more information about how MSBuild is locating the incorrect assembly by invoking it on the command line. Simply go to the directory of the project containing the incorrect reference and try the following:
msbuild myproject.csproj /v:d
... This will output a detailed log that describes how MSBuild is locating each of the referenced assemblies. It isn't unusual to find some unpleasant surprises!
Cheers,
Remco
This message is kicked up by NCrunch when a referenced assembly resolved from MSBuild is being pulled from the same directory as one of the build outputs from another project. It analyses the physical output from MSBuild during a build of your project, and should be very accurate.
Note that MSBuild has enormous amounts of implicit logic when resolving references. For example, the 'HintPath' shown above is only a suggestion to the resolution that there may be an assembly at the location specified - it isn't considered a hard fact. If the file doesn't exist in the suggested location, MSBuild will continue to search around a large list of potential other locations in order to find the file. This means that MSBuild assembly resolution uses a 'best effort' approach in finding assemblies.
You can gain more information about how MSBuild is locating the incorrect assembly by invoking it on the command line. Simply go to the directory of the project containing the incorrect reference and try the following:
msbuild myproject.csproj /v:d
... This will output a detailed log that describes how MSBuild is locating each of the referenced assemblies. It isn't unusual to find some unpleasant surprises!
Cheers,
Remco
Post a reply
Log in to reply.