Swashbuckle.aspnetcore: Can't build netcoreapp2.2 project with 5.0.0-rc3

[JustArchi]

Feel free to check out my travis output.

dotnet "/home/travis/.nuget/packages/microsoft.extensions.apidescription.server/0.3.0-preview7.19365.7/build//../tools/dotnet-getdocument.dll" --assembly "/home/travis/build/JustArchiNET/ArchiSteamFarm/ArchiSteamFarm/out/source/ArchiSteamFarm.dll" --file-list "obj/ArchiSteamFarm.OpenApiFiles.cache" --framework ".NETCoreApp,Version=v2.2" --output "obj" --project "ArchiSteamFarm" --assets-file "/home/travis/build/JustArchiNET/ArchiSteamFarm/ArchiSteamFarm/obj/project.assets.json" --platform "AnyCPU"
No method 'BuildWebHost', 'CreateHostBuilder' or 'CreateWebHostBuilder' found in type 'ArchiSteamFarm.Program' with expected signatures.

I have a rather specific project in which I use kestrel and MVC with your library, but it's not asp.net core project. Therefore I don't have any generic host builders, but rather I create and start kestrel on as-needed basis.

I'm not sure what I'm supposed to do here. Of course everything worked fine with rc2, but I feel like this can be a blocker for me once 5.0.0 is released, and I don't want to miss out on the opportunity of using your awesome library. I'm not sure what is the apidescription step here (the core program builds fine, this is post-compilation step) and whether it can be ignored/fixed on your side, or perhaps we need to forward to the upstream, I believe you know better in this regard and will make the right call. From my side, the error mentioned in this issue is the direct result of upgrading to rc3, so I'm reporting to you.

Thank you in advance for looking into my issue. Feel free to use the project referenced by me above for reproducing the problem.

---

Update

Hey, thank you all for your responses.

I can confirm that <OpenApiGenerateDocuments>false</OpenApiGenerateDocuments> has solved the issue for me with no visible drawbacks, thank you a lot for that workaround.

In regards to me, I consider this issue resolved and it can be closed, but I'll keep it open in case @domaindrivendev would want it to stay to help people with similar issues. If by any chance you decide it's no longer relevant/needed, feel free to close it anytime you wish.

Thanks again for your help.

[martincostello]

I have a similar issue with rc3 for an ASP.NET Core 3.0 RC1 app.

The build fails on macOS (but not Windows or Linux) with the following error:

  GenerateOpenApiDocuments:
    dotnet "/Users/travis/.nuget/packages/microsoft.extensions.apidescription.server/0.3.0-preview7.19365.7/build//../tools/dotnet-getdocument.dll" --assembly "/Users/travis/build/martincostello/api/src/API/bin/Release/netcoreapp3.0/API.dll" --file-list "obj/API.OpenApiFiles.cache" --framework ".NETCoreApp,Version=v3.0" --output "obj" --project "API" --assets-file "/Users/travis/build/martincostello/api/src/API/obj/project.assets.json" --platform "AnyCPU" 
  Generating document named 'api'.
  Writing document named 'api' to 'obj/API_api.json'.
  System.TimeoutException: Process dotnet timed out after 2 minutes.
     at Microsoft.Extensions.ApiDescription.Tool.Exe.Run(String executable, IReadOnlyList`1 args, String workingDirectory, Boolean interceptOutput)
     at Microsoft.Extensions.ApiDescription.Tool.Commands.InvokeCommand.Execute()
     at Microsoft.Extensions.ApiDescription.Tool.Commands.CommandBase.<>c__DisplayClass0_0.<Configure>b__0()
     at Microsoft.DotNet.Cli.CommandLine.CommandLineApplication.Execute(String[] args)
     at Microsoft.Extensions.ApiDescription.Tool.Program.Main(String[] args)
  Process dotnet timed out after 2 minutes.
/Users/travis/.nuget/packages/microsoft.extensions.apidescription.server/0.3.0-preview7.19365.7/build/Microsoft.Extensions.ApiDescription.Server.targets(41,5): error MSB3073: The command "dotnet "/Users/travis/.nuget/packages/microsoft.extensions.apidescription.server/0.3.0-preview7.19365.7/build//../tools/dotnet-getdocument.dll" --assembly "/Users/travis/build/martincostello/api/src/API/bin/Release/netcoreapp3.0/API.dll" --file-list "obj/API.OpenApiFiles.cache" --framework ".NETCoreApp,Version=v3.0" --output "obj" --project "API" --assets-file "/Users/travis/build/martincostello/api/src/API/obj/project.assets.json" --platform "AnyCPU" " exited with code 1. [/Users/travis/build/martincostello/api/src/API/API.csproj]

Failed builds:

1. macOS on Travis CI
2. macOS on Azure Pipelines

I'm not even sure why it's trying to do this, as it's not something I've explicitly enabled.

I tried bumping the version to the latest RC1 release of the dependency in my project, but that didn't fix it either.

Looking at the package version history in NuGet.org it looks like the 0.3 versioning is a mistake, and it's actually a part of ASP.NET Core 3.0, so might explain why this doesn't work for @JustArchi on ASP.NET Core 2.2.

[martincostello]

The above looks like a bug in ASP.NET Core 3.0, which I've reported here: https://github.com/aspnet/AspNetCore/issues/14232

The macOS build failure can be fixed by setting the following MSBuild property:

<OpenApiGenerateDocuments>false</OpenApiGenerateDocuments>

[JoJo2406]

I can confirm I have a similar build issue from when I upgraded from rc2 to rc3. Any projects that targeted netcoreapp2.2 would get the following build error (net48 works fine):

System.NullReferenceException: Object reference not set to an instance of an object.    
 at Microsoft.Extensions.Hosting.HostFactoryResolver.GetServiceProvider(Object host)
 at Microsoft.Extensions.ApiDescription.Tool.Commands.GetDocumentCommandWorker.Process()    

Severity    Code    Description Project File    Line    Suppression State
Error   MSB3073 The command "dotnet "C:\Users\Joe\.nuget\packages\microsoft.extensions.apidescription.server\0.3.0-preview7.19365.7\build\/../tools/dotnet-getdocument.dll" --assembly "Z:\Repos\ukgd\src\Services\Courier\FedEx.API\bin\Debug\netcoreapp2.2\win-x64\FedEx.API.dll" --file-list "obj\FedEx.API.OpenApiFiles.cache" --framework ".NETCoreApp,Version=v2.2" --output "obj" --project "FedEx.API" --assets-file "Z:\Repos\ukgd\src\Services\Courier\FedEx.API\obj\project.assets.json" --platform "x64" --runtime "win-x64" " exited with code 7.  FedEx.API   C:\Users\Joe\.nuget\packages\microsoft.extensions.apidescription.server\0.3.0-preview7.19365.7\build\Microsoft.Extensions.ApiDescription.Server.targets 41  

I tried bumping both the net core sdk from 2.2.402 to 3.0.100 and microsoft.extensions.apidescription.server from 0.3.0-preview7.19365.7 to both 3.0.0-rc1.19457.4 and 3.0.0 but with no luck.

Only solution that worked was by setting the property as above:

<OpenApiGenerateDocuments>false</OpenApiGenerateDocuments>

[domaindrivendev]

I believe the real issue here is with the latest .NET Core SDK, although it will only manifest itself with SB 5.0.0-rc3 and above. This is because the latest version of SB exposes an implementation of Microsoft.Extensions.ApiDescriptions.IDocumentProvider, a pre-defined contract that newer versions of the SDK _automatically_ looks for and if an implementation is present, leverages to generate OpenAPI documents at build-time.

This means, if you're using a version of the SDK that has this behavior AND a version of SB that exposes an implementation of IDocumentProvider, then the Swagger generator will be invoked at build-time. If an exception is raised as part of this invocation, then you'll see an error similar to the above.

I've seen some instances where the exception is being surfaced from within the generator and other cases where it's raised from the SDK tooling that's invoking the generator.

Either way, I think the SDK should handle these failures more gracefully - providing the full stack trace front and center with the build error, and possibly even downgrading to a warning rather than a build error.

In the meantime, I think the proposal above to disable the new SDK behavior in your csproj file is the best path forward if you're experiencing this issue.

[nphmuller]

To improve the error the SDK throws update to the latest version of Microsoft.Extensions.ApiDescription.Server, like described in https://github.com/domaindrivendev/Swashbuckle.AspNetCore/issues/1226#issuecomment-530894591

Since ApiDescription.Server starts an instance of the application just after its build, most errors are probably startup related. The latest version of the package will return the proper startup error nicely.

There are also certain edge cases during startup which won't really work with ApiDescription.Server. I've asked for clarification here: https://github.com/aspnet/AspNetCore/issues/14410

[JustArchi]

Hey, thank you all for your responses.

I can confirm that <OpenApiGenerateDocuments>false</OpenApiGenerateDocuments> has solved the issue for me with no visible drawbacks, thank you a lot for that workaround.

In regards to me, I consider this issue resolved and it can be closed, but I'll keep it open in case @domaindrivendev would want it to stay to help people with similar issues. If by any chance you decide it's no longer relevant/needed, feel free to close it anytime you wish.

Thanks again for your help.

[Vaccano]

Just curious, what does <OpenApiGenerateDocuments>false</OpenApiGenerateDocuments> change?

Most settings options turn a feature on or off, or change its functionality. What does this setting turn on or off?

[cosmin19]

The above looks like a bug in ASP.NET Core 3.0, which I've reported here: aspnet/AspNetCore#14232

The macOS build failure can be fixed by setting the following MSBuild property:

<OpenApiGenerateDocuments>false</OpenApiGenerateDocuments>

Works on Windows too. Thanks !!!