dotnet publish outputs old packages

Question

I must be going crazy. I am hitting an issue where a dotnet publish is outputting older versions of some packages (specifically Microsoft.Extensions.Configuration.dll) and it's causing a runtime issue. My (simplified) .csproj is as follows...

<Project Sdk="Microsoft.NET.Sdk.Web">

  <PropertyGroup>
    <VersionPrefix>1.0.0</VersionPrefix>
    <TargetFrameworks>net462</TargetFrameworks>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore" Version="1.1.2" />
    <PackageReference Include="Microsoft.AspNetCore.Hosting.WindowsServices" Version="1.1.2" />
    <PackageReference Include="Microsoft.AspNetCore.Mvc" Version="1.1.2" />
    <PackageReference Include="Microsoft.AspNetCore.StaticFiles" Version="1.1.2" />
    <PackageReference Include="Microsoft.Extensions.Configuration" Version="1.1.2" />
    <PackageReference Include="Microsoft.Extensions.Logging.Debug" Version="1.1.2" />
  </ItemGroup>
  <ItemGroup>
    <DotNetCliToolReference Include="BundlerMinifier.Core" Version="2.3.327" />
    <DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="1.0.1" />
    <DotNetCliToolReference Include="Microsoft.DotNet.Watcher.Tools" Version="1.0.1" />
  </ItemGroup>

</Project>

When I run a dotnet publish on my dev machine, it outputs the proper version of Microsoft.Extensions.Configuration.dll (1.1.2.30427). However, my TeamCity build server outputs a super old version of it (1.0.0.20622). I have tried several things including:

• dotnet nuget locals -c all to clear the local cache on the build server
• including <RuntimeFrameworkVersion>1.1.2</RuntimeFrameworkVersion> to see if that helps
• dotnet --info returns the exact same versions on my local dev and the TeamCity server

I am referencing some libraries that have dependencies on Microsoft.Extensions.Configuration 1.1.0, but to my knowledge that would just be the minimum. I'm explicitly telling the main app to use 1.1.2.

What am I missing? Why won't it output the packages that I'm telling it explicitly to pull?

Answer 1

I recently had this issue too and went round in circles for hours. No matter what I did I was finding that dotnet publish MySolution.sln --configuration Release --output dist kept outputting v2.0 of Microsoft.Extensions.FileSystemGlobbing.dll to the dist folder even though the only project in the whole solution that had any dependency on it at all (via a refernce to Microsoft.Extensions.Configuation.Json was definitely using v3.1.0 from the .NET 3.1 SDK (and later v3.1.2 as a direct NuGet add)

VS 2019 build would succeed, and put a v3.1 DLL in the output folder. As you found, calling dotnet publish without the --output flag would drop the correct v3.1 DLL in the bin\release\publish folder...

And that was when the penny dropped; --ouput X collates all the published files into X and subsequent outputting of files with a same name as the existing, would overwrite earlier outputted files. I did a windows file search for *globbing.dll and found that when I didn't use --output there were two versions of the DLL in different subfolders:

MySolution\MyProject1\bin\release\publish\Microsoft.Extensions.FileSystemGlobbing.dll  <-- v3.1 as expected
MySolution\MyProject1.UnitTests\bin\release\publish\Microsoft.Extensions.FileSystemGlobbing.dll  <-- v2.0 !

The UnitTests project recently added is, for some reason, outputting v2.0 of the DLL. It's not cited as a dependency in the solution explorer so I'm not sure why, but because it was being built later, --output was collecting the later-built-but-earlier-versioned file and overwriting the earlier-built-but-later-versioned file..

Now I need to find out why the UnitTests are outputting this old version, but there's an explanation for why --output leaves you with an old version; possibly the new version was written, but then was later overwritten with an old version as part of the --output process

Answer 2

For those looking here later...

After hours of wasted life, it seems something is awry when using the --output flag with dotnet publish.

This was what I was using that was causing older libraries to write out:

dotnet publish Foo.sln --framework net462 --configuration Release --output C:\test\dist

And this (taking out --output) works just fine and outputs the proper libraries:

dotnet publish Foo.sln --framework net462 --configuration Release

To make it weirder, my local dev machine works fine in either case (with or without --output). I've spent too much time fighting tooling to figure out what is actually wrong, so if someone does just let me know for future reference.