Docs: Can global.json be used for something else?

[hrumhurum]

For example, can a product license key be stored in global.json for a commercial product distributed via NuGet?

Like so:

{
  "ContosoCRM": {
    "LicenseKey": "AAAAA-BBBBB-CCCCC-DDDDD-EEEEE"
  }
}

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: a94c335b-0b65-96cc-1c25-65777fbe4bb5
• Version Independent ID: 6d80613f-42dc-35d7-aeff-3187a36dbbca
• Content: global.json reference
• Content Source: docs/core/tools/global-json.md
• Service: unspecified
• Product: dotnet-core
• GitHub Login: @blackdwarf
• Microsoft Alias: mairaw

[mairaw]

@livarcocc @KathleenDollard to comment on this. My understanding is that you could have any information on that file but CLI would only understand sdk/version.

[livarcocc]

You can use to specify NuGet SDK versions for the whole repo.

@jeffkl for more information on this.

Other than that, @mairaw is right, it is only used on the CLI for the sdk version.

[jeffkl]

I've documented how to use global.json to control MSBuild project SDKs here: https://docs.microsoft.com/en-us/visualstudio/msbuild/how-to-use-project-sdk#how-project-sdks-are-resolved

[hrumhurum]

Thank you for insightful hints. According to provided information, it looks like it can be safely assumed that global.json has a loose format definition (which is a good thing).

The only thing to be aware of is a possible clash between Microsoft and 3rd party tools' properties. We have namespaces in XML to sort that out but JSON lacks them.

So here comes the proposal: officially define and document a special property as the root object for all the extra stuff people may want to put in global.json. For example:

{
  "sdk": {
    "version": "1.0.0-preview2-003121"
  },
  "extensions": {
    "ContosoCRM": {
      "LicenseKey": "AAAAA-BBBBB-CCCCC-DDDDD-EEEEE"
    }
  }
}

A proposed name for that special container property is extensions.

_Use case:_ this would solve a long-standing challenge for commercial NuGet packages. Currently they stick to two mechanisms: environment variables (convenient for build agents) and license files. The problem with license files is that there is no convention on where to store them. End-customers are also reluctant to see yet another file for yet another tool. In contrast, global.json perfectly covers that scenario as it has a well-defined lookup and storage semantics.

Edit: added a use-case

[KathleenDollard]

@hrumhurum We're looking at global.json, so it is good to have this suggestion. But at the present there is a more serious problem. The SDK stops looking when it finds the first global.json. If different global.json's are inserted for different things, havoc could ensue if they are not all read.

[JRAlexander]

@KathleenDollard, This is really a product related topic now, correct? If so, I can close this and an issue can be created in the product repo

[JRAlexander]

@KathleenDollard as this is really a product related topic now, I'm going to
close this. @hrumhurum would you like create an issue for this in the product repo, or would you like me to?