RicoSuter / NSwag

The Swagger/OpenAPI toolchain for .NET, ASP.NET Core and TypeScript.
http://NSwag.org
MIT License
6.67k stars 1.23k forks source link

Missing CLI arguments for nswag 14.0.2 #4720

Closed KirkMunroSagent closed 4 months ago

KirkMunroSagent commented 7 months ago

I just tried upgrading from nswag 13.20.0 to 14.0.2, changing only the /runtime argument from /runtime:net70 to /runtime:net80, and ran into similar issues as reported in #4678.

It seems that the following arguments have been removed from nswag openapi2csclient:

/runtime /timeOnly

Is that intentional or accidental? Since nswag 14 supports .NET 7 and .NET 8, it seems like the removal of /runtime must be accidental. I can't come up with a logical reason for the removal of /timeOnly though.

Would someone please comment on whether or not the removal of these arguments from the latest version was intentional or not?

krzyhan commented 7 months ago

Maybe I'm wrong, but I think runtime is not needed anymore as you are providing an input, so file is already generated (in a specific runtime)

OlegUfaev commented 6 months ago

We too had problems with the NSwag CLI when upgrading from NSwag v13.20.0 to NSwag v14.0.2 We are running the NSwag CLI in Windows operating system, and our project is targeting .NET 6

In v13.20.0, we used the nswag run nswag.json /runtime:Net60 command to regenerate C# and TypeScript clients.

After upgrading to v14.0.2, when running the same nswag run nswag.json /runtime:Net60 command, we get an error

NSwag command line tool for .NET Core Net60, toolchain v14.0.1.0 (NJsonSchema v11.0.0.0 (Newtonsoft.Json v13.0.0.0))
Visit http://NSwag.org for more information.
NSwag bin directory: C:\Program Files (x86)\Rico Suter\NSwagStudio\Net60
NConsole.UnusedArgumentException: Unrecognised arguments are present: [/runtime:Net60]
   at NConsole.CommandLineProcessor.ProcessSingleAsync(String[] args, Object input)
   at NConsole.CommandLineProcessor.ProcessAsync(String[] args, Object input)
   at NSwag.Commands.NSwagCommandProcessor.ProcessAsync(String[] args) in /_/src/NSwag.Commands/NSwagCommandProcessor.cs:line 62

If we try to remove the runtime parameter and execute the nswag run nswag.json command, we get the following error

NSwag command line tool for .NET 4.6.2+ WinX64, toolchain v14.0.1.0 (NJsonSchema v11.0.0.0 (Newtonsoft.Json v13.0.0.0))
Visit http://NSwag.org for more information.
NSwag bin directory: C:\Program Files (x86)\Rico Suter\NSwagStudio\Win

Executing file 'nswag.json' with variables ''...
System.InvalidOperationException: The specified runtime in the document (Net60) differs from the current process runtime (WinX64). Change the runtime with the '/runtime:Net60' parameter or run the file with the correct command line binary.

Having studied the problem a bit, we saw that the C:\Program Files (x86)\Rico Suter\NSwagStudio\NSwagStudio\nswag.cmd file contains conditional logic related to the runtime parameter.

@ECHO OFF
set args=%*

IF NOT "%args:/runtime:winx86=%" == "%args%" (
    "%~dp0/Win/nswag.x86.exe" %*
    GOTO end
)

IF NOT "%args:/runtime:net60=%" == "%args%" (
    dotnet "%~dp0/Net60/dotnet-nswag.dll" %*
    GOTO end
)

IF NOT "%args:/runtime:net70=%" == "%args%" (
    dotnet "%~dp0/Net70/dotnet-nswag.dll" %*
    GOTO end
)

IF NOT "%args:/runtime:net80=%" == "%args%" (
    dotnet "%~dp0/Net80/dotnet-nswag.dll" %*
    GOTO end
)

"%~dp0/Win/nswag.exe" %*
:end

If we run the command dotnet "C:\Program Files (x86)\Rico Suter\NSwagStudio\Net60\dotnet-nswag.dll" run nswag.json, everything works successfully. And we're using that as a workaround right now.

But if we run the command dotnet "C:\Program Files (x86)\Rico Suter\NSwagStudio\Net60\dotnet-nswag.dll" run nswag.json /runtime:Net60, with runtime paremeter, we'll get the error again

NSwag command line tool for .NET Core Net60, toolchain v14.0.1.0 (NJsonSchema v11.0.0.0 (Newtonsoft.Json v13.0.0.0))
Visit http://NSwag.org for more information.
NSwag bin directory: C:\Program Files (x86)\Rico Suter\NSwagStudio\Net60
NConsole.UnusedArgumentException: Unrecognised arguments are present: [/runtime:Net60]
   at NConsole.CommandLineProcessor.ProcessSingleAsync(String[] args, Object input)
   at NConsole.CommandLineProcessor.ProcessAsync(String[] args, Object input)
   at NSwag.Commands.NSwagCommandProcessor.ProcessAsync(String[] args) in /_/src/NSwag.Commands/NSwagCommandProcessor.cs:line 62

In summary, we see that nswag.cmd handles the runtime parameter correctly and starts execution through dotnet-nswag.dll designed for a particular Runtime (in our case it is .NET 6 Runtime), but it passes all arguments including 'runtime' to dotnet-nswag.dll which no longer supports it and an error occurs.

Apparently, either nswag.cmd should exclude runtime from parameters passed to dotnet-nswag.dll or dotnet-nswag.dll itself should ignore its presence.

KirkMunroSagent commented 6 months ago

We too had problems with the NSwag CLI when upgrading from NSwag v13.20.0 to NSwag v14.0.2 We are running the NSwag CLI in Windows operating system, and our project is targeting .NET 6

According to the docs, .NET 6 isn't supported in NSwag 14. I've been limiting use of NSwag 14 to projects that support .NET 7 or later because of this.

OlegUfaev commented 6 months ago

According to https://github.com/RicoSuter/NSwag/issues/4524#issue-1914136979, .NET 6 isn't supported in NSwag 14. I've been limiting use of NSwag 14 to projects that support .NET 7 or later because of this.

@KirkMunroSagent, NSwag still targets .NET 6 as well and works fine if you directly use the .NET 6 assembly C:\Program Files (x86)\Rico Suter\NSwagStudio\Net60\dotnet-nswag.dll.

https://github.com/RicoSuter/NSwag/blob/master/src/NSwag.ConsoleCore/NSwag.ConsoleCore.csproj

<TargetFrameworks>net6.0;net7.0;net8.0</TargetFrameworks>
OlegUfaev commented 6 months ago

@RicoSuter, please, could you pay attention to this issue?

Currently our workflow for regenerating clients via the NSwag CLI is completely broken on Windows. There is a workaround that I described above, but it would be great if there was a fix for working through the NSwag CLI.

Ganesh-Ponipireddy commented 6 months ago

Same here, I'm using 14.0.3 version with dotnet 8. for me, in the exception it is showing no arguments.

NConsole.UnusedArgumentException: Unrecognised arguments are present: []
   at NConsole.CommandLineProcessor.ProcessSingleAsync(String[] args, Object input)
   at NConsole.CommandLineProcessor.ProcessAsync(String[] args, Object input)
KirkMunroSagent commented 5 months ago

It seems that the following arguments have been removed from nswag openapi2csclient:

/runtime /timeOnly

Is that intentional or accidental? Since nswag 14 supports .NET 7 and .NET 8, it seems like the removal of /runtime must be accidental. I can't come up with a logical reason for the removal of /timeOnly though.

@RicoSuter Can you please comment on this change?

KirkMunroSagent commented 4 months ago

Nevermind...I inherited some code that was using /timeOnly when it should have been using /timeType. That explains why I couldn't find /timeOnly in version 14.x. It seems that 13.x didn't report an error on an invalid argument, but 14.x does. Closing this issue because the OP is a non-issue. Maybe others on this thread can create a separate issue specific to their problem, but the original issue posted here is not an issue.

volkastersmall commented 4 months ago

Same here, I'm using 14.0.3 version with dotnet 8. for me, in the exception it is showing no arguments.

NConsole.UnusedArgumentException: Unrecognised arguments are present: []
   at NConsole.CommandLineProcessor.ProcessSingleAsync(String[] args, Object input)
   at NConsole.CommandLineProcessor.ProcessAsync(String[] args, Object input)

I have the same problem. How you resolved it?

KYegres commented 2 months ago

@volkastersmall @Ganesh-Ponipireddy I have same error then pass same parameter twice. In my case it was parameter /GenerateExceptionClasses:false. I have two OpenApiReference tag in my csproj file and each has /GenerateExceptionClasses:false (I have common ApiException class in separate file). Looks like NSwag adds second /GenerateExceptionClasses:false by itself, so I removed my /GenerateExceptionClasses:false and now it works fine.