Why is my solution building with the wrong dll version?

Question

I'm using Microsoft.SQLServer.Types to use the spacial type. I'm installing version 11.x from Nuget.

When I publish the solution using Visual studio (2013) it's copying version 11.x to the bin folder.

However, when I build using MSBuild, it's copying version 10.x into the bin folder.

Any thoughts why?

Here's the bit of the csproj file that references the dll:

<Reference Include="Microsoft.SqlServer.Types, Version=11.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=MSIL">
    <HintPath>..\packages\Microsoft.SqlServer.Types.11.0.1\lib\net20\Microsoft.SqlServer.Types.dll</HintPath>
</Reference>

Also, copy local is set to true.

Also I've got this in the web.config for that project:

<dependentAssembly>
    <assemblyIdentity name="Microsoft.SqlServer.Types" publicKeyToken="89845dcd8080cc91" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-11.0.0.0" newVersion="11.0.0.0" />
</dependentAssembly>

Is the `` and/or `` item metadata set for the reference in your `.csproj` file? — Martin Costello, Apr 28 '14 at 12:31
Hi both... I've added the bit of the csproj file that references the dll and yes it's set to private. Should I change that to _not_ be private? — Piers Karsenbarg, Apr 28 '14 at 12:35
@martin_costello I've removed the `` tag from the `` tag. It doesn't have the `` tag. — Piers Karsenbarg, Apr 28 '14 at 13:21

score 0 · Answer 1 · answered Jul 22 '22 at 21:13

tl;dr: Check all your child project references to that dll. Likely one (or more) of them is still referencing the older version.

Details:

First of all, the web.config bindingRedirect is only relevant during runtime, so that isn't related to your Publish issue.

Like you, (even 8 years later), I've also witnessed cases where Visual Studio publishes a different version of a dll than when publishing from the command line msbuild. Although I've never taken the time to prove it, my suspicion is that VS is publishing the references in a slightly different order than msbuild does. Regardless of why they differ, the solution is to fix all the child project references to that dll, not just the website project. Fortunately there is a simple way to determine which project is still referencing the old dll.

Most people change the "verbosity" level of msbuild to "quiet" or "minimal" to prevent excess logging, but if you temporarily bump that level back up to at least "normal" (-v:n) you should see a list of every dll that is getting copied into the temporary location. (Which may be something like obj\Release\Package\PackageTmp.) Searching through the log you'll likely see the correct dll get copied into that directory, possibly multiple times, followed by an older version of the same dll getting put there last which overwrites the newer version. Scrolling up from there should identify the project that needs to be updated.

Why is my solution building with the wrong dll version?

1 Answers1