Aspnetcore: Microsoft.Extensions.ApiDescription.Server 3.0.0-rc1.19457.4 causes build to fail on macOS

Created on 22 Sep 2019  路  24Comments  路  Source: dotnet/aspnetcore

Describe the bug

_Originally found via https://github.com/domaindrivendev/Swashbuckle.AspNetCore/issues/1266#issuecomment-533895107_

When Microsoft.Extensions.ApiDescription.Server is in the dependency tree of an ASP.NET Core 3.0 application, the application fails to build on macOS with the following error:

/Users/travis/.nuget/packages/microsoft.extensions.apidescription.server/3.0.0-rc1.19457.4/build/Microsoft.Extensions.ApiDescription.Server.targets(62,5): error : System.TimeoutException: Process /Users/travis/build/martincostello/api/.dotnetcli/dotnet timed out after 2 minutes. [/Users/travis/build/martincostello/api/src/API/API.csproj]
/Users/travis/.nuget/packages/microsoft.extensions.apidescription.server/3.0.0-rc1.19457.4/build/Microsoft.Extensions.ApiDescription.Server.targets(62,5): error :    at Microsoft.Extensions.ApiDescription.Tool.Exe.Run(String executable, IReadOnlyList`1 args, IReporter reporter, String workingDirectory, Boolean interceptOutput) [/Users/travis/build/martincostello/api/src/API/API.csproj]
/Users/travis/.nuget/packages/microsoft.extensions.apidescription.server/3.0.0-rc1.19457.4/build/Microsoft.Extensions.ApiDescription.Server.targets(62,5): error :    at Microsoft.Extensions.ApiDescription.Tool.Commands.InvokeCommand.Execute() [/Users/travis/build/martincostello/api/src/API/API.csproj]
/Users/travis/.nuget/packages/microsoft.extensions.apidescription.server/3.0.0-rc1.19457.4/build/Microsoft.Extensions.ApiDescription.Server.targets(62,5): error :    at Microsoft.Extensions.ApiDescription.Tool.Commands.CommandBase.<>c__DisplayClass14_0.<Configure>b__0() [/Users/travis/build/martincostello/api/src/API/API.csproj]
/Users/travis/.nuget/packages/microsoft.extensions.apidescription.server/3.0.0-rc1.19457.4/build/Microsoft.Extensions.ApiDescription.Server.targets(62,5): error :    at Microsoft.Extensions.CommandLineUtils.CommandLineApplication.Execute(String[] args) [/Users/travis/build/martincostello/api/src/API/API.csproj]
/Users/travis/.nuget/packages/microsoft.extensions.apidescription.server/3.0.0-rc1.19457.4/build/Microsoft.Extensions.ApiDescription.Server.targets(62,5): error :    at Microsoft.Extensions.ApiDescription.Tool.ProgramBase.Run(String[] args, CommandBase command, Boolean throwOnUnexpectedArg) [/Users/travis/build/martincostello/api/src/API/API.csproj]
/Users/travis/.nuget/packages/microsoft.extensions.apidescription.server/3.0.0-rc1.19457.4/build/Microsoft.Extensions.ApiDescription.Server.targets(62,5): error MSB3073: The command "dotnet "/Users/travis/.nuget/packages/microsoft.extensions.apidescription.server/3.0.0-rc1.19457.4/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]

The issue can be worked around by setting the following MSBuild property:

<OpenApiGenerateDocuments>false</OpenApiGenerateDocuments>

To Reproduce

Add the following NuGet package reference to an ASP.NET Core 3.0 application which has an API controller and build the application on macOS:

<PackageReference Include="Microsoft.Extensions.ApiDescription.Server" Version="3.0.0-rc1.19457.4" />

Expected behavior

The application builds successfully.

Additional context

This issue appears to only affect macOS, and not Windows or Linux. See this PR for different build behaviours: https://github.com/martincostello/api/pull/212

External area-mvc feature-code-generation investigate

Most helpful comment

For those interested, the root cause is https://github.com/dotnet/corefx/issues/41740, and it is in fact a mac-only issue (at least in this specific instance).

All 24 comments

Thanks for contacting us, @martincostello.
@ryanbrandenburg can you please look into this? Thanks!

This didn't replicate for me, the .json file generated successfully on macOS. There were also more steps than what's listed above to get things set up. What I did:

  1. dotnet new webapi
  2. Add the reference to Microsoft.Extensions.ApiDescription.Server.
  3. Add a reference to Swashbuckle.AspNetCore, Version 5.0.0-rc3.
  4. In ConfigureServices add:
    ```c#
    services.AddSwaggerGen(c => { c.SwaggerDoc("v1", new OpenApiInfo{ Title="My API", Version = "v1" } ) });
5. In Configure add:
```c#
app.UseSwagger();
app.UseSwaggerUI(c => { c.SwaggerEndpoint("/swagger/v1/swagger.json", "My API V1"); });

In order to investigate further I'll need you to create (as a GitHub repo) a simplified repro project which demonstrates the failure so that I can use it to investigate.

If you use the repo for the PR linked to in the description, you can see the issue being replicated if you revert the workaround in the final commit of the PR. It鈥檚 a very simple project that鈥檚 just got some simple resources (like getting the current time).

I was able to reproduce this. My current best guess is that it's actually a CoreFX problem, so we're going to have them take a look at a dump I made of the problem. The gist of it seems to be that the process we launch from within the CLI tool to do the actual document creation "hangs" because the Program.Main function is exited but the process is still open.

The title of this issue is for MacOS, but I can confirm it exists on Windows too:

Severity Code Description Project File Line Suppression State Suppression State
Error MSB3073 The command "dotnet "C:\Usersxxxxx.nuget\packages\microsoft.extensions.apidescription.server\0.3.0-preview7.19365.7\build\/../tools/dotnet-getdocument.dll" --assembly "C:\GitHub\Web-content.api.works24.com\content.api.works24.com\bin\Debugnetcoreapp3.0\content.api.works24.com.dll" --file-list "obj\content.api.works24.com.OpenApiFiles.cache" --framework ".NETCoreApp,Version=v3.0" --output "obj" --project "content.api.works24.com" --assets-file "C:\GitHub\Web-content.api.works24.com\content.api.works24.com\obj\project.assets.json" --platform "AnyCPU" " exited with code 7. content.api.xxxxx.com C:\Usersxxxxx.nuget\packages\microsoft.extensions.apidescription.server\0.3.0-preview7.19365.7\buildMicrosoft.Extensions.ApiDescription.Server.targets 41

I tried to replicate this on Windows earlier and re-tried yesterday without any dice. Perhaps it's a less reliable repro on Windows, or maybe my windows repro isn't as close to the Mac one as I think.

Let me know if you need more info, I can reproduce reliably. Happy to help.

If you have step-by-step instructions to get into that state on Windows that would be huge ("install this exact sdk, clone this exact commit, change these 2 lines" kind of a thing). I'm told we have some Windows-only tools which would make diagnosing this easier, so it would probably help the turn-around time significantly. I'll spin up a clean VM to try those steps against in the mean time in case my messy dev machine was part of the problem.

I wish I had a step by step list for you... It was fine one day, pushed to Github, automated build worked, etc. The next day I opened up the project fresh and bang, I got the error above. This is a new project created with VS2019, with controllers and a lot of Startup.cs code brought over from a project that had targeted .Net Core 2.0.

A little more detail on the error from our automated Docker build:

GenerateOpenApiDocuments:
dotnet "/root/.nuget/packages/microsoft.extensions.apidescription.server/0.3.0-preview7.19365.7/build//../tools/dotnet-getdocument.dll" --assembly "/app/bin/content.api.works24.com.dll" --file-list "obj/content.api.works24.com.OpenApiFiles.cache" --framework ".NETCoreApp,Version=v3.0" --output "obj" --project "content.api.works24.com" --assets-file "/app/content.api.works24.com/obj/project.assets.json" --platform "AnyCPU"
Generating document named 'v1'.
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation.
---> System.NotSupportedException: Ambiguous HTTP method for action - content.api.works24.com.Controllers.ErrorController.Error (content.api.works24.com). Actions require an explicit HttpMethod binding for Swagger 2.0
at Swashbuckle.AspNetCore.SwaggerGen.SwaggerGenerator.GenerateOperations(IEnumerable1 apiDescriptions, SchemaRepository schemaRepository) at Swashbuckle.AspNetCore.SwaggerGen.SwaggerGenerator.GeneratePaths(IEnumerable1 apiDescriptions, SchemaRepository schemaRepository)
at Swashbuckle.AspNetCore.SwaggerGen.SwaggerGenerator.GetSwagger(String documentName, String host, String basePath)
at Microsoft.Extensions.ApiDescriptions.DocumentProvider.GenerateAsync(String documentName, TextWriter writer)
--- End of inner exception stack trace ---
at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor, Boolean wrapExceptions)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters)
at Microsoft.Extensions.ApiDescription.Tool.Commands.GetDocumentCommandWorker.InvokeMethod(MethodInfo method, Object instance, Object[] arguments)
at Microsoft.Extensions.ApiDescription.Tool.Commands.GetDocumentCommandWorker.GetDocument(String documentName, String projectName, String outputDirectory, MethodInfo generateMethod, Object service)
at Microsoft.Extensions.ApiDescription.Tool.Commands.GetDocumentCommandWorker.GetDocuments(GetDocumentCommandContext context, IServiceProvider services)
at Microsoft.Extensions.ApiDescription.Tool.Commands.GetDocumentCommandWorker.Process(GetDocumentCommandContext context)
/root/.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 "/root/.nuget/packages/microsoft.extensions.apidescription.server/0.3.0-preview7.19365.7/build//../tools/dotnet-getdocument.dll" --assembly "/app/bin/content.api.works24.com.dll" --file-list "obj/content.api.works24.com.OpenApiFiles.cache" --framework ".NETCoreApp,Version=v3.0" --output "obj" --project "content.api.works24.com" --assets-file "/app/content.api.works24.com/obj/project.assets.json" --platform "AnyCPU" " exited with code 7. [/app/content.api.works24.com/content.api.works24.com.csproj]
Build FAILED.

PEBKAC. Added [HttpGet] attribute to the ErrorController and it's fixed now. Sorry for the trouble.

Glad you've found your issue. The error message is a bit verbose, but is helpful:

System.NotSupportedException: Ambiguous HTTP method for action - content.api.works24.com.Controllers.ErrorController.Error (content.api.works24.com). Actions require an explicit HttpMethod binding for Swagger 2.0

I'm not so sure that this particular issue related to #13245 I see exact this issue on Mac only. Without Windows. I never experience issues with Windows the @johnvcoleman-w24 have completely unrelated issue to original one, so please re-open. @ryanbrandenburg was able to reproduce original issue as well.

Yes, that鈥檚 not the fix to this issue. That鈥檚 just a comment that they鈥檝e resolved their own similar issue.

Confirming originally reported issue affects Mac OS. I still have failure without MSBuild workaround from first post.

Happy to provide any further details.

If it helps, this was happening to me on Windows only if I had any code (functions specifically) in my controller without HTTP attributes (like [HttpGet] , [HttpPost]). Moving those helper functions out to their own class solved it for me.

I had the same problem. At my side it was resolved by putting the Route Attribute at the controller level. [Route("[Controller]")]

So, by paring down the "broken" app continuously until it match dotnet new mvc I figured out what the proximal problem is here. In Program.cs.CreateHostBuilder if the call to UseApplicationInsights is removed then everything starts to pass. We'll be looking more into why that's the case, but for now hopefully that can get anyone who's trying to work with Swagger unblocked.

For those interested, the root cause is https://github.com/dotnet/corefx/issues/41740, and it is in fact a mac-only issue (at least in this specific instance).

That was unexpected to say the least 馃槃

More generally, anyone who creates a Thread without Joining it or making it as background could run into basically this problem. We encourage people not to do things like that, so it's unclear if the openapi tooling will attempt to work around this kind of behavior, so make some noise if that's a scenario that's important to you.

I'm going to close this out in favor of dotnet/corefx#41740. If people run into similar behavior caused by other packages start a new issue and we can consider if this needs mitigation.

FYI the dotnet/corefx#41740 fix was included in 3.1-preview2.

Was this page helpful?
0 / 5 - 0 ratings