Visual Studio does not reference the assembly from the nuget package / build directory correctly

Question

I have a C # project (ProjectA) that calls another C # project (ProjectB) in a separate process. The structure of the output directory of the assembly:

/ProjectA.exe
/ProjectB/ProjectB.exe

Version versions of ProjectA and ProjectB for the same assembly, in this case Newtonsoft.Json.dll.

The assembly output directory structure is achieved by adding the Nuget package for ProjectB to ProjectA. ProjectA and ProjectB are in separate solutions and are built separately. The nuget package for ProjectB was created with the following .nuspec and .targets.

<?xml version="1.0"?> <package> <metadata> <id>ProjectB</id> <version>$version$</version> <title>ProjectB</title> <authors>me</authors> <owners>me</owners> <requireLicenseAcceptance>false</requireLicenseAcceptance> <description>ProjectB</description> <copyright>Copyright 2016</copyright> <tags>ProjectB</tags> </metadata> <files> <file src="x64\Release\*" target="build" /> <file src="ProjectB.targets" target="build/ProjectB.targets" /> </files> </package> 

.

 <?xml version="1.0" encoding="utf-8"?> <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> <ItemGroup> <NativeLibs Include="$(MSBuildThisFileDirectory)*" /> <Content Include="@(NativeLibs)"> <Link>ProjectB\%(FileName)%(Extension)</Link> <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory> </Content> </ItemGroup> </Project> 

My problem is that ProjectA refers to the new version of Newtonsoft.Json.dll from the ProjectB package / assembly directory nuget instead of the old version of Newtonsoft.Json.dll, which is part of the ProjectA solution. They are different versions, so this causes problems at runtime. I understand that I can simply update the version of Newtonsoft.Json.dll in ProjectA solution, but I want to be able to solve a more general case when this is not possible. How can I prevent Visual Studio from finding the wrong Newtonsoft.Json.dll file?

Answer 1

As a result, adding a group of related elements to all ProjectB assemblies always caused problems with introducing the wrong version of the assembly in ProjectA. I had to resort to the robocopy postbuild team to do what I wanted. This has the disadvantages that ProjectB assemblies are not copied when ProjectA refers to another project, but for me this is not critical. If Microsoft ever fixes this behavior with magic build goals , then the nuget package in the original question should work fine. Below are the .nuspec and .targets files with a robocopy workaround.

 <?xml version="1.0"?> <package> <metadata> <id>ProjectB</id> <version>$version$</version> <title>ProjectB</title> <authors>me</authors> <owners>me</owners> <requireLicenseAcceptance>false</requireLicenseAcceptance> <description>ProjectB</description> <copyright>Copyright 2016</copyright> <tags>ProjectB</tags> </metadata> <files> <file src="x64\Release\*" target="build/ProjectB" /> <file src="ProjectB.targets" target="build/ProjectB.targets" /> </files> </package> 

.

 <?xml version="1.0" encoding="utf-8"?> <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> <Target Name="ProjectBCopyTarget" AfterTargets="Build"> <Exec Command="robocopy /PURGE $(MSBuildThisFileDirectory)ProjectB $(TargetDir)ProjectB || if %ERRORLEVEL% LSS 8 exit 0"/> </Target> </Project> 

Answer 2

EDIT: This answer is not really working. The behavior of VisualStudio is very incompatible with what assembly it decides to use. Sometimes removing an assembly from the output directory will result in a change in the version of the assembly that becomes familiar. Apparently, any assembly files associated with the project can be selected by MSBuild at compile time. See my other answer .

I found that if I put all ProjectB assemblies in a separate subdirectory of the nuget package / build directory, then MSBuild will not use them as links. The nuget work package for ProjectB was created with the following .nuspec and .targets.

 <?xml version="1.0"?> <package> <metadata> <id>ProjectB</id> <version>$version$</version> <title>ProjectB</title> <authors>me</authors> <owners>me</owners> <requireLicenseAcceptance>false</requireLicenseAcceptance> <description>ProjectB</description> <copyright>Copyright 2016</copyright> <tags>ProjectB</tags> </metadata> <files> <file src="x64\Release\*" target="build/ProjectB" /> <file src="ProjectB.targets" target="build/ProjectB.targets" /> </files> </package> 

.

 <?xml version="1.0" encoding="utf-8"?> <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> <ItemGroup> <NativeLibs Include="$(MSBuildThisFileDirectory)ProjectB\*" /> <None Include="@(NativeLibs)"> <Link>ProjectB\%(FileName)%(Extension)</Link> <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory> </None> </ItemGroup> </Project> 

Apparently, MSBuild is looking in the same directory as the ProjectB.targets file to map assemblies, but not subdirectories. This "magic" behavior from MSBuild really needs to be fixed by Microsoft. See Related Comment on this Question