Remove NeoExpress from DevTracker extension package

[devhawk]

Today, devtracker includes its own copy of Neo Express in the extension package. This is problematic for a few reasons

• Increases the size of the VSIX package significantly. Today, the package is 29.2MB. Express is approximately 28.5MB of that.
• Users typically have their own copy of Express installed as either a global or local tool.
  • The C# contract template in devtracker includes a dotnet-tools.json file that installs Express as a local tool
• DevTracker is updated automatically when a new version is released, but command line tools like Express and the Neo C# compiler are not updated automatically
• The version of Express included in DevTracker has to be manually updated

Instead of including neoxp inside the extension package, DevTracker should help the developer keep their global or local installation of Express up to date.

On activation in a workspace that contains one or more .neo-express files, check to see if Express is installed locally (dotnet tool list --local) or globally (dotnet tool list --global).

If not installed, give the user the option to install either globally or locally. Also, provide a mechanism to "learn more" that will open a documentation page that explains the difference. Note, if the user chooses local install, devtracker may also need to create a tool manifest (dotnet new tool-manifest)

If installed, check to see if there is an updated version of Neo.Express available from nuget.org and offer to update if available. Note, DevTracker and Express both track the Neo platform's major & minor version numbers, but will have different patch version. DevTracker should not install a version of Express that doesn't match its own major/minor version. For example. DevTracker v3.6.12 and Express 3.6.21 are both installed. DevTracker should offer to update to Express v3.6.28 but not Express v3.7.13. DevTracker v3.7 would offer to update Express 3.6.21 -> 3.7.13

Note, if possible, devtracker should have a setting to allow it to pull express builds from the build server package feed in addition to the main nuget.org package feed

[ngdentdev]

In the case of local installation, where should we place "neo.express"? In the extensions folder like the current implementation or the workspace folder?

[ngdentdev]

The dotnet-tools.json file is included in the extension package under the new-contract -> csharp folder. Is it ok to assume it will always be there for us to get the target neo.express version?

[devhawk]

In the case of local installation, where should we place "neo.express"? In the extensions folder like the current implementation or the workspace folder?

We should trigger installation and updates via the dotnet tool command line utility. So for install, if the user chooses local we should execute dotnet install neo.express --local (local is the default, but for automation like this I prefer to be explicit). Note, local tool installation requires a tool manifest, which may not already be present. dotnet new tool-manifest will create a new tool manifest in the right location.

The dotnet-tools.json file is included in the extension package under the new-contract -> csharp folder. Is it ok to assume it will always be there for us to get the target neo.express version?

I don't think the new contract template is a good source for this information. We can add baseline version information to the package.json file (which is available to the extension via the Extension.packageJSON property). But ideally we would get this information from the nuget.org API. The Package Content versions API is trivial to parse.

Current content of https://api.nuget.org/v3-flatcontainer/neo.express/index.json:

{
    "versions": [
        "0.8.11",
        "0.9.80",
        "0.9.82",
        "0.9.95",
        "1.0.7",
        "1.0.8",
        "1.1.28",
        "2.0.17-preview",
        "2.0.18-preview",
        "2.0.21-preview",
        "2.0.23-preview",
        "2.0.24-preview",
        "2.0.32-preview",
        "2.0.35-preview",
        "2.0.37-preview",
        "2.0.39-preview",
        "2.0.50-preview",
        "3.0.2",
        "3.0.5",
        "3.0.13",
        "3.0.21",
        "3.1.38",
        "3.1.46",
        "3.3.21",
        "3.3.27",
        "3.4.18",
        "3.5.20"
    ]
}

[ngdentdev]

dotnet new tool-manifest will create a new tool manifest in the right location.

dotnet new tool-manifest places a file in the current ./.config folder, so in this case, should the folder be the root of the workspace or the extensions' root folder?

[devhawk]

dotnet new tool-manifest places a file in the current ./.config folder, so in this case, should the folder be the root of the workspace or the extensions' root folder?

The tool config file is local to the workspace folder, not the extension folder. You can see an example in the Registrar Sample repo

Note, I think we need to fix the C# new contract template. It's putting the tool manifest in the project workspace root, not under .config folder as dotnet new tool-manifest does. I'll open a separate issue for that