From @jeffhollan on June 13, 2018 21:23

<creating here as placeholder while move to feed repo - delete whenever>

The change feed should expose the current version of node so tools like VS Code can utilize when creating / publishing apps

Copied from original issue: Azure/azure-functions-core-tools#530

Ex: Microsoft.NET.Sdk.Functions can change, but right now the generating tool takes whatever was previous

cc: @soninaren

We should have schema defined and applied to the tooling feed, with a test to ensure any changes to that file match the schema.

Seems the feed for v3-preview was removed. Why?

Visual studio is now complaining that there is no functions runtime available.

We would need to add new entries to the feed for net-7 isolated and net Framework isolated project templates once they are created.

Set .NET5 for v3 and v4 - set both false

NET 5.0 -isolated is showing up because its not hidden in the feed, both the v3 tag and the net5-isolated entry in that release have hidden = false. By design for VS, probably a bug in the feed.

note net5-isolated IS disabled for v4, but we still are pulling in the v3 version of it. It needs to be hidden = true in both places.

The feed.json file is no longer getting v3-preview even though the tags and releases folders contain the appropriate content. I believe this is tied to my issue listed here Azure/azure-functions-host#5145 where I cannot start my v3-preview project that was working yesterday.
C:\Users[user]\AppData\Local\AzureFunctionsTools\feed.json

Help?

Java templates are part for azure-functions-maven-plugin. This makes it difficult for version controlling Java templates for VS code.

The tooling feed will need to expose a new isolated worker which is built against .NET Standard 2.0. This should not initially be a public feed entry - validation will be needed against it.

New templates to be created which would be a part of that: Azure/azure-functions-templates#1186

Per tooling partner discussion, v4 runtime variant needs to call this out with a new required capability. A proposal might be "netfx-isolated" or similar (v1 used the string "netframework" it looks like). As long as it's a new key, that should be fine. To keep things reasonably consisting, it is probably worth keeping the "-isolated" suffix on it. Overall, we need some discussion for the specific entry's title.

Currently it's v6.0, which creates problems when VS goes to create the resource or update it before publishing.

Example:

We need to update the tooling feed to include the .NET 8 in-proc Core Tools package, using the appropriate tooling suffix (tag).

Ensure the tooling feed generator is updated.

There are important files that Microsoft projects should all have that are not present in this repository. A pull request has been opened to add the missing file(s). When the pr is merged this issue will be closed automatically.

Microsoft teams can learn more about this effort and share feedback within the open source guidance available internally.

Merge this pull request

The latest commit, 07881cbcd2df83, uses a period instead of a comma on line 718 of cli-feed-v3.json

Related to #234

How should we be sorting the .NET runtimes - I assume we should just go with the order in this feed? If so, do we want .NET 5 above .NET 3.1 (essentially making .NET 5 the default) even when it's not LTS?

cc @ankitkumarr @anthonychu @fiveisprime @phil-allen-msft

Make net8.0 default in latest release.

A diff shows that #500 was incorrect and should not have been merged.

4.67.0 had differing item templates for some stacks. This needs to be preserved. The source of the version used in 4.68.0 seems to be

We should update this to instead split things up. I'd suggest replacing the format strings here with a pair of dictionaries containing the full IDs, one for the item templates, and one for the project templates.

In an ideal world, the feed bases itself off of a previous (probably GA) entry. Then, none of this would need to be hardcoded in this way at all.

The feed should be modified to expose (unhide) the .NET 6.0 isolated to enable the tooling experience.

• Create a PR for the feed to unhide .NET 6 isolated
• Have Phil and Nathan to test this in VS and VS Code
• Merge PR and publish feed changes

After talking briefly with Naren, it seems like the tests that can add value are something like these.

1. Make sure the package links that are part of the updated cli-tool-feed are valid (i.e. they are available and downloadable) >> This is to ensure there is no human error while updating existing item-templates/project-templates
2. Make sure the cli-tool-feed structure follows a knowledge base model which means a new property can be added but we cannot delete a property from existing elements.
   @soninaren

cc @soninaren
Temporary location for stacks: https://github.com/pragnagopa/azure-functions-supported-runtime-stacks

This info will be available on public endpoint soon. We should figure out what is the best way to include in tooling feed.

These refs should be GUIDs not valid versions

It's very confusing to have them as versions because VS uses that for folder names and then people start reporting that as the version.

We need to update the tooling feed to include the .NET 8 in-proc Core Tools package, using the appropriate tooling suffix (tag).

Ensure the tooling feed generator is updated.

The cli-feed-v4.json file is not valid json. There's an errant comma at the end of the file.

        }
      ]
    },
  }
}

https://github.com/Azure/azure-functions-tooling-feed/blob/main/cli-feed-v4.json#L4878

Due to this, the https://functionscdn.azureedge.net/public/cli-feed-v4.json endpoint is currently returning an invalid JSON response that is throwing JSON parsing errors.

Currently causing some issues for the Azure Functions VS Code extension. microsoft/vscode-azurefunctions#2999

To make string update for these strings:

• LTS -> Long term support. Add it to 6.0

• 3 -> 3.1

• 5 -> 5.0

• 6 -> 6.0

Tooling feed build needs to update TemplateApiZip url as well in addition to itemTemplates and projectTemplates.
cc: @soninaren @pragnagopa

Per title, I noticed I was getting a really old Core Tools version (3.0.3442) in VS 16.11.5

Interestingly, @cachai2 is on 16.9.11 but is getting Core Tools 3.0.3785. These seem to be pulling from different feed versions. In both cases, they are looking for the GA V3 entry. But with different feed, wildly different results.

V4 feed

V3 feed

Tracking item for when we're ready to add this. Support is not yet available at the time of this issue being opened.
 
This is effectively a re-introduction of the components removed with #539, although there are some slight changes to make to the image tag, etc.

The following added setting in the feed since 4.61.0 is causing an issue with Publish from Visual Studio

          "WEBSITE_USE_PLACEHOLDER_DOTNETISOLATED ": "1"

REPRO STEPS

1. File > New project > Azure Functions > .NET 8.0 Isolated, leave other options as default (Http trigger)
2. Publish to Azure Function App (Linux)
   Plan Type: App service plan

internal bug:
https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1917518

VS shows following dialog when downloading Azure Function Core Tools

Message is confusing as it displays the CLI feed version and not the Azure Functions Core tools version.
Update message to: Downloading Azure Functions CLI tools

That was only available in Functions v2 and should probably be marked as hidden/deprecated. We want folks to use 3.1+ instead.

This repository holds feed for several packages and tools, which some of our other tools (VS, VS Code Extension) rely on.

Even though the feed is updated via automation (not yet for v4 feed), we don't have tests to validate the feed. We need to add some tests that validate basic scenarios for our feed such as -- making sure the AppSettings values are correct, capabilities are accurate and never remove unintentionally, and several other scenarios that typically shouldn't change.

This issue tracks the work to create an initial setup with very basic tests. We can then follow-up by adding more robust tests for better coverage.

cc: @phil-allen-msft (thanks for suggesting this)

The NET 7 Isolated variant's description feed should be updated to one of:

Isolated STS
Isolated Standard Support
Isolated Standard Term Support

any of the following would cause the desired behavior to be in the VS drop down:

Related to:
https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1689984/

In standaloneCli entries, for x64 Windows, the generator includes the link for the min version of the CLI. This is inconsistent with other platforms. In the past we always included the full CLI links. I think this may have been a bug.

standaloneCli": [
        {
          "OS": "Linux",
          "Architecture": "x64",
          "downloadLink": "https://functionscdn.azureedge.net/public/3.0.3233/Azure.Functions.Cli.linux-x64.3.0.3233.zip",
          "sha2": "4e34f8495c701b481292be70ca3abfc77a7449dccab58211298890657a743e19"
        },
        {
          "OS": "Windows",
          "Architecture": "x64",
          "downloadLink": "https://functionscdn.azureedge.net/public/3.0.3233/Azure.Functions.Cli.min.win-x64.3.0.3233.zip",
          "sha2": "be79e10b575a7111a33f2450a287b3ed9d6b2bd9d0702ee9297200fc569ac29d"
        },
        {
          "OS": "Windows",
          "Architecture": "x86",
          "downloadLink": "https://functionscdn.azureedge.net/public/3.0.3233/Azure.Functions.Cli.win-x86.3.0.3233.zip",
          "sha2": "9db43d54b20c918a9004bfaa3984f96613cfd7d61db4069126308bcacf26a9cf"
        }
      ]

Here, the link for Windows x64 is "..Azure.Functions.Cli.min.win-x64.3.0.3233.zip"

Add .NET 8.0 Isolated (Preview) entry for dotnet-isolated in the v4 feed.

Validate that Visual Studio performs the correct Core Tools selection from the tooling feed and debugging works as expected.