Question

我一定是疯了。我遇到的问题是dotnet publish正在输出某些软件包的旧版本（特别是Microsoft.Extensions.Configuration.dll）并导致运行时问题。我的（简体）.csproj如下......

<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>

当我在我的开发机器上运行dotnet publish时，它输出正确版本的Microsoft.Extensions.Configuration.dll（1.1.2.30427）。但是，我的TeamCity构建服务器输出了它的超级旧版本（1.0.0.20622）。我尝试过几件事情，包括：

dotnet nuget locals -c all清除构建服务器上的本地缓存
包括<RuntimeFrameworkVersion>1.1.2</RuntimeFrameworkVersion>以查看是否有帮助
dotnet --info返回我本地开发人员和TeamCity服务器上完全相同的版本

我引用了一些依赖于Microsoft.Extensions.Configuration 1.1.0的库，但据我所知，这只是最小的。我明确告诉主应用程序使用1.1.2。

我错过了什么？为什么不输出我明确告诉它的包？

Answer 1

对于那些稍后看的人......

浪费了几个小时的生命，在--output使用dotnet publish标志时似乎出现了问题。

这就是我使用的导致旧库写出的内容：

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

这个（取出--output）工作正常并输出正确的库：

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

为了使它更奇怪，我的本地开发机器在任何一种情况下（有或没有--output）都能正常工作。我花了太多时间来讨论工具以找出究竟是什么问题，所以如果有人让我知道以备将来参考。

Answer 2

我最近也遇到了这个问题，绕了几个小时。不管我做什么，我发现dotnet publish MySolution.sln --configuration Release --output dist始终将Microsoft.Extensions.FileSystemGlobbing.dll的v2.0输出到dist文件夹中，即使整个解决方案中唯一一个完全不依赖它的项目（通过引用Microsoft.Extensions.Configuation.Json肯定是使用了.NET 3.1 SDK中的v3.1.0（以及后来的v3.1.2作为直接的NuGet添加）

VS 2019构建将成功，并将v3.1 DLL放入输出文件夹。如您所见，调用不带dotnet publish标志的--output会将正确的v3.1 DLL删除到bin\release\publish文件夹中。

那便是一分钱掉下来的时候； --ouput X将所有已发布的文件整理到X中，随后以与现有名称相同的名称输出文件，将覆盖较早输出的文件。我在Windows文件中搜索了*globbing.dll，发现当我不使用--output时，在不同的子文件夹中有两个版本的DLL：

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 !

由于某种原因，最近添加的UnitTests项目正在输出DLL v2.0。在解决方案资源管理器中没有将其引用为依赖项，所以我不确定为什么，但是由于它是在以后构建的，因此--output会收集较新构建但较早版本的文件并覆盖较早构建的文件-but-late-versioned file ..

现在，我需要找出为什么UnitTests输出此旧版本的原因，但是对于--output为什么要使用旧版本的原因有一个解释。可能是写了新版本的，但后来在--output过程中被旧版本覆盖了

dotnet发布输出旧包

2 个答案: