Swashbuckle.aspnetcore: Could not load file or assembly 'System.Threading' when running Swashbuckle.AspNetCore.Cli command

Created on 29 Mar 2019  路  14Comments  路  Source: domaindrivendev/Swashbuckle.AspNetCore

Version: 5.0.0-rc2
Concerning: Swashbuckle.AspNetCore.Cli

I've upgraded our project from version 4.0.1 to 5.0.0-rc2 which also includes the CLI tool.
Project file contents:

        [...]
        <PackageReference Include="Swashbuckle.AspNetCore" Version="5.0.0-rc2" />
        <PackageReference Include="Swashbuckle.AspNetCore.Swagger" Version="5.0.0-rc2" />
    </ItemGroup>

    <ItemGroup>
      <DotNetCliToolReference Include="Swashbuckle.AspNetCore.Cli" Version="5.0.0-rc2" />
    </ItemGroup>

We use the CLI tool in a Azure DevOps pipeline to generate a swagger.json file with the following command.

Get-SwaggerFileFromAssembly.ps1 -Environment Development -SwaggerFileLocation swagger-development.json -SwaggerStartupAssemblyLocation .\bin\release\netcoreapp2.1\[name DLL removed].dll v1

The Powershell script contains the following content:

[CmdletBinding()]
param (
    [Parameter(Mandatory = $true)]
    [string] $Environment,

    [Parameter(Mandatory = $true)]
    [string] $SwaggerFileLocation,

    [Parameter(Mandatory = $true)]
    [string] $SwaggerStartupAssemblyLocation,

    [Parameter(Mandatory = $true)]
    [string] $SwaggerDocName
)

$env:ASPNETCORE_ENVIRONMENT=$Environment
dotnet swagger tofile --output $SwaggerFileLocation $SwaggerStartupAssemblyLocation $SwaggerDocName

When running this script locally, everything works as expected.
In Azure DevOps, I get the following Exception:

Unhandled Exception: System.IO.FileLoadException: Could not load file or assembly 'System.Threading, Version=4.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
   at System.Console.get_Out()
   at Swashbuckle.AspNetCore.Cli.Program.Main(String[] args)

Azure DevOps agent is Hosted VS2017.

Most helpful comment

I'm able to reproduce in a netcoreapp2.2 project with the cli tool 5.0.0-rc2.

I'm assuming this is because the dotnet core cli tool package is targeting netcoreapp2.1. I was able to bump the target framework version on master to netcoreapp2.2 and use that dll directly as a temp workaround.

All 14 comments

Some extra information; it seems to work on Windows but running the command on macOS throws the same exception.

Having the same issue on my machine, with .Net Core 2.2

I have same problem with VS 2019, ASP.NET Core 2.2, Swashbuckle 5.0.0-rc2.

In version 5.0.0-beta, this problem does not occur.

As I can't repro this it would be really helpful if someone on this thread put together, and point me to, a minimal sample application that repo's the issue clearly and concisely.

@yuft Which OS are you using? Windows or macOS?
@aetos382 I assume you're using Windows because you mention VS 2019? Or is it VS 2019 for Mac?

The reason I'm asking is because I can't reproduce it on a Windows environment so far.
Only on a macOS environment.

@thomasvdb
I am using Windows 10 Pro with VS2017 & vscode , dotnet core sdks are as follows. I get the same error with 'dotnet run'.

2.1.202 [C:\Program Files\dotnet\sdk]
2.1.502 [C:\Program Files\dotnet\sdk]
2.1.503 [C:\Program Files\dotnet\sdk]
2.1.505 [C:\Program Files\dotnet\sdk]
2.1.602 [C:\Program Files\dotnet\sdk]
2.2.102 [C:\Program Files\dotnet\sdk]
2.2.104 [C:\Program Files\dotnet\sdk]
2.2.202 [C:\Program Files\dotnet\sdk]

Tried a minimal example.
This sample runs on Windows 10 Enterprise (version 1809) without problem.
This sample does not run on Windows Server 2016 (version 1607) Datacenter
WebApplication2.zip

Command used:
dotnet swagger tofile --output .\swagger.json .bin\Debug\netcoreapp2.2\WebApplication2.dll 聽v1

output on windows server:
image

Hope this helps

@thomasvdb I'm using VS2019 on Windows 10 Pro (1809).
It also occurred when working only with the dotnet CLI without using Visual Studio.

On my machine, executing following commands (without any options) in the directory where only this file is placed will reproduce the problem.

  • dotnet restore
  • dotnet swagger

I'm using dotnet SDK ver. 2.2.203.

However, I could not create an environment to reproduce the problem on docker container (I used this Dockerfile).

I ran this container on both Linux Containers and Windows Containers on Docker for Windows, but both successfully displayed the usage of "dotnet swagger" command.

I'm able to reproduce in a netcoreapp2.2 project with the cli tool 5.0.0-rc2.

I'm assuming this is because the dotnet core cli tool package is targeting netcoreapp2.1. I was able to bump the target framework version on master to netcoreapp2.2 and use that dll directly as a temp workaround.

@domaindrivendev any reason why the cli's target framework version can't be upgraded to netcoreapp2.2?

OK I think I've worked out the problem.

TLDR: Make sure you don't have SDK version 2.1.2 or 2.1.202 installed. There might be other versions that also cause problems, but I can confirm that 2.1.400 and above seem to be fine.

Baseline, ensure that you don't have any 2.0.x runtimes installed (which somehow come with 2.1.2 and 2.1.202 SDKs).

The long version

I had two computers one of which it worked on and the other it didn't work. Both machines were Windows 10 using Visual Studio 2019 Preview (16.3.0 Preview 1).

It turns out that you can enable Host Tracing for dotnet core which provides diagnostic information about the runtime and binding it does when starting up.

I dumped the (extremely verbose) output to a file in which I found the following for the machine that didn't work:

Runtime config [C:\Users\Matthew\.nuget\packages\swashbuckle.aspnetcore.cli\5.0.0-rc2\lib\netcoreapp2.0\dotnet-swagger.runtimeconfig.json] is valid=[1]
--- The specified framework 'Microsoft.NETCore.App', version '2.0.0', apply_patches=1, version_compatibility_range=minor is compatible with the previously referenced version '2.0.0'.
--- Resolving FX directory, name 'Microsoft.NETCore.App' version '2.0.0'
Can't get the size of the SDK location registry value or it's empty, result: 0x2
Searching FX directory in [C:\Program Files\dotnet]
Attempting FX roll forward starting from version='[2.0.0]', apply_patches=1, version_compatibility_range=minor, roll_to_highest_version=0, prefer_release=1
'Roll forward' enabled with version_compatibility_range [minor]. Looking for the lowest release greater than or equal version to [2.0.0]
Found version [2.0.3]
Applying patch roll forward from [2.0.3] on release only
Inspecting version... [1.0.3]
Inspecting version... [1.1.0]
Inspecting version... [2.0.3]
Inspecting version... [2.0.9]
Inspecting version... [2.1.11]
Inspecting version... [2.1.12]
Inspecting version... [2.1.2]
Inspecting version... [2.1.3-servicing-26724-03]
Inspecting version... [2.1.4]
Inspecting version... [2.1.6]
Inspecting version... [2.1.7]
Inspecting version... [2.1.8]
Inspecting version... [2.1.9]
Inspecting version... [2.2.1]
Inspecting version... [2.2.2]
Inspecting version... [2.2.3]
Inspecting version... [2.2.5]
Inspecting version... [2.2.6]
Inspecting version... [3.0.0-preview7-27912-14]
Changing Selected FX version from [] to [C:\Program Files\dotnet\shared\Microsoft.NETCore.App\2.0.9]
Chose FX version [C:\Program Files\dotnet\shared\Microsoft.NETCore.App\2.0.9]

Notice the lines about 'Roll forward'. It was looking for the lowest version greater than or equal to 2.0.0 and so found 2.0.3. It then was allowed to roll forward the patch from 2.0.3 to 2.0.9.

On the machine that DID work, no 2.0.x versions were found and the first it matched greater than or equal to 2.0.0 was 2.1.12. Obviously there's a problem in the 2.0.x series of libraries.

Now that's all fine except that I didn't have a 2.0.x series SDK installed (hint use dotnet --list-sdks). But when I checked the runtimes 2.0.x series runtime WAS installed (hint use dotnet --list-runtimes).

So I figured it must have come with one of the other SDK installs. After removing 2.1.2 and 2.1.202 I found that the offending 2.0.x series runtimes were also uninstalled.

Now it works on the machine that didn't originally (and incidentally matches the 2.1.2 runtime).

Closing as @heatonmatthew appears to have found a resolution/workaround

I seem to have the issue in Azure cloud only with 2.2, how can I uninstall packages with azure cli?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

NinoFloris picture NinoFloris  路  3Comments

govin picture govin  路  3Comments

m-demydiuk picture m-demydiuk  路  3Comments

JoelAdamWeiss picture JoelAdamWeiss  路  4Comments

jluqueba picture jluqueba  路  4Comments