Package NEON as .net global tool #166
Conversation
| <PropertyGroup Condition="'$(GlobalTool)' == true"> | ||
| <PackAsTool>true</PackAsTool> | ||
| <TargetFramework>netcoreapp3.1</TargetFramework> | ||
| <PackageId>Neo.Neon</PackageId> |
There was a problem hiding this comment.
I think it makes sense as the name of . netcoreapp since it's always neon.exe.
There was a problem hiding this comment.
Not sure what you're asking @erikzhang. The exe is named neon, but the package is named neo.neon. All neo packages need to have the "neo" prefix in order to get associated with the neo-project nuget org
There was a problem hiding this comment.
If the PackageId doesn't match the exe name, we have to install it by a name and use it by another name. It is too confusing.
There was a problem hiding this comment.
Neo express already works this way. Exe name is neo-express while package name is neo.express. Besides, developers aren't typically going to execute neon.exe manually, it is automatically invoked by the contract build script created by the template.
Additionally, there are already a bunch of neon packages on nuget.org that we don't want to get confused with
There was a problem hiding this comment.
What is the benefit of a PackageId and exe name mismatch?
There was a problem hiding this comment.
I think it's used to avoid conflict of the same name for packages on nuget.
There was a problem hiding this comment.
I searched on nuget, there is no conflict name.
There was a problem hiding this comment.
I prefer neon with version 2.x.
|
@devhawk Nice feature! Harry, you missed |
|
Thanks for testing this @superboyiii! I'm not sure what you mean by
that file was added in commit e7d56b8. I added it at the root so it could be accessed for packages built out of ./Neo.Compiler.MSIL and ./Neo.SmartContract.Framework |
|
@superboyiii I'm sorry, I provided instructions for building the neo.neon package but I forgot to include instructions for installing it! I see you've successfully built the tool package using /p:GlobalTool=true. In order to install the tool, you need to provide the package location via --add-source. Otherwise, dotnet tool install looks in nuget.org for the tool package. Eventually that will work, but the package has not yet been published on nuget.org yet. You should be able to install the package with this command: > dotnet tool install neo.neon -g --add-source .\bin\Debug\ |
|
That's cool! Thanks for your clear instruction. |
|
I will test it tomorrow! |
|
@devhawk I was not able to uninstall it, what i am doing wrong? |
|
@shargon you misspelled uninstall |
I think there should be one version of NEON that works with both neo 2 & 3. I filed #83 to this effect a while ago. |
Fixes #164, #159, #82 , #163
NEON was updated to .NET core 3.1 as part of #154. This PR adds additional changes in csproj files to enable building NEON as a .NET Core Global Tool. This will allow developers to install NEON from the command line instead of having to clone this repo and build manually
Currently, the Neo.Compiler.MSIL builds as both .NET Standard 2.0 and .NET Core 3.1 to support scenarios where someone wants to use the compiler as a library. Unfortunately, you can't build as a global tool when targeting .net standard. So I refactored the build script to allow building as .net standard and .net core global tool separately.
dotnet packwill build Neo.Compiler.MSIL as a .NET Standard 2.0 library package whiledotnet pack /p:GlobalTool=truebuilds Neo.Compiler.MSIL as a .NET Core 3.1 global tool. To differentiate the packages, I gave the global tool package the nameNeo.Neoninstead ofNeo.Compiler.MSIL.Additionally, this PR bumps the version numbers.