Nswag: dotnet tool install fails to install Nswag.ConsoleCore nuget

Created on 17 Jun 2019 · 14Comments · Source: RicoSuter/NSwag

Short description of Nswag.ConsoleCore says "Command line tool for .NET Core (dotnet nswag)" yet when I run .net core command line tool install using this command

dotnet tool install  -g NSwag.ConsoleCore --version  13.0.1

I get the following error message:

error NU1212: Invalid project-package combination for NSwag.ConsoleCore 13.0.1. 
DotnetToolReference project style can only contain references of the DotnetTool type                                                                                                                                                            
The tool package could not be restored.                                                                                                                       
Tool 'nswag.consolecore' failed to install. This failure may have been caused by:                                                                              

* You are attempting to install a preview release and did not use the --version option to specify the version.
* A package by this name was found, but it was not a .NET Core tool.
* The required NuGet feed cannot be accessed, perhaps because of an Internet connection problem.
* You mistyped the name of the tool.

Is this is a bug or am I just using Nswag wrong?

Source

PaulDotNet

Most helpful comment

@RicoSuter dotnet now supports local tools: https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotnet-core-3-0#local-tools

I think the advantage of this over

sgryphon on 10 Dec 2019

👍3

All 14 comments

Nswag.ConsoleCore is not a global tool - just a tool.

RicoSuter on 17 Jun 2019

Any Idea, what would be needed to allow it to be run as global tool?
Would be a nice option I think.

glatzert on 12 Sep 2019

Technically global tool requires just a couple of lines in the project file. Extremely easy to do.

PaulDotNet on 12 Sep 2019

I'm against a global tool because it is global - ie. all projects on your PC use the same version and you are not "forced" to use a version per project which avoids that a project breaks other projects.

RicoSuter on 12 Sep 2019

👎1

Using different versions of the tool for different projects is quite unusual.

PaulDotNet on 13 Sep 2019

Well, that's probably very dependent on the use case for NSwag.

To us NSwag is a tool to generate HttpClients in TypeScript and C# primarily. In that case a CLI tool is all we need, since we update the clients ad-hoc (there's no sensible time during a build to do that, since it might just break the build). We stumble over NSwag not beeing installable as a tool.

slightly OT: Also we often see messages like "runtime in document does not match current runtime", which is also irrelevant for creating clients in the first place.

glatzert on 13 Sep 2019

FWIW @RicoSuter concern about having a global version is valid.

During the languages and runtimes community standup Kathleen Dollard mentioned that they want to rebrand it to ".NET Tools", as it's just as valid to install them locally as it is globally, so it might still make sense to make this a tool.

@KathleenDollard Is this fair, or am I mis-representing what you said?

slang25 on 13 Sep 2019

Aaand I just read, NSwag is now usable from Visual Studio Service References.
So the tool is obsolete (at least for me - unix users still could profit from a global codegen tool).

glatzert on 13 Sep 2019

You can install NSwag globally via the NPM package :-)

npm i -g nswag

Another reason it is not a global tool is because global tools do not support full .NET Framework (netfx) and I personally integrate NSwag as a project build step with NSwag.MSBuild or maybe soon with Service References.

RicoSuter on 13 Sep 2019

👍1

Personally I don't like the concept of building a project to generate code, I need to write the code of my project - that's kind of a hen and egg problem.

Having no tool support on netfx is irrelevant for code gen.
I see why it might be relevant for swagger gen, tho.

glatzert on 13 Sep 2019

@RicoSuter dotnet now supports local tools: https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotnet-core-3-0#local-tools

I think the advantage of this over

sgryphon on 10 Dec 2019

👍3

Ah cool, can we change the project so thst it supports both types?

RicoSuter on 14 Dec 2019

I'm against a global tool because it is global - ie. all projects on your PC use the same version and you are not "forced" to use a version per project which avoids that a project breaks other projects.

What's the difference between a global tool and using NSwag Studio (or the version of the CLI that it installs into your path...)?

morquan on 27 Feb 2020

It appears that there's just one process to create a dotnet tool for 3.0/3.1, and the user chooses whether to install it locally or globally: https://docs.microsoft.com/en-us/dotnet/core/tools/global-tools-how-to-create