dotnet publish outputs old packages

user_762834 0
Viewed 2286

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?

asp.net-core .net-core c#
3 Answers

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

user_14106640

Thank you for pointing out issue with --output argument !

I had a simple build mecanism :

dotnet restore src
dotnet publish src --configuration Release --output out

Everything running fine inside docker image mcr.microsoft.com/dotnet/core/sdk:3.1.

When migrating CICD from Jenkins to GitlabCI, using the same comand inside the same Docker image, I found out that my application no longer worked and I had the following error :

Could not load file or assembly 'Newtonsoft.Json, Version=12.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed'

Further investigation led me to understand that dependencies put in the out folder where not the same between Jenkins build and GitlabCI build.

I had to use theses build command to understand that the copy order was not the same with GitlabCI :

dotnet restore src
dotnet publish src --configuration Release
dotnet publish src --configuration Release --output out --no-build

The last command will output the copy order for output :

Microsoft (R) Build Engine version 16.7.2+b60ddb6f4 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.   

  SubProject1 -> /app/out/
  SubProject2 -> /app/out/
  SubProject3 -> /app/out/
  SubProject4 -> /app/out/

The order was changing whith GitlabCI.

The fix I found was to force the same order doing this :

dotnet restore src
dotnet publish src --configuration Release
dotnet publish src/SubProject1 --configuration Release --output out --no-build
dotnet publish src/SubProject2 --configuration Release --output out --no-build
dotnet publish src/SubProject3 --configuration Release --output out --no-build
dotnet publish src/SubProject4 --configuration Release --output out --no-build

If anyone can find how these subproject are ordered for the output folder, I'm interested !

user_51743580
Related