Skip to content

Commit

Permalink
proposal
Browse files Browse the repository at this point in the history
  • Loading branch information
@chcosta
chcosta committed Apr 11, 2019
1 parent 055c65d commit 737e293
Showing 1 changed file with 87 additions and 0 deletions.
87 changes: 87 additions & 0 deletions Documentation/SharedFrameworks.md
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,87 @@
# Multiple Shared Framework Installations in Arcade

## Proposal

- define frameworks in global.json
- no generated props file or use of a `DotNetCoreRuntimeVersions` item group
- if runtimes section is present, assume we can't fulfill the specs globally and force use of `.dotnet` folder

Notes: This will require updating darc to support the format change - https://github.com/dotnet/arcade-services/commit/9a486718cdb33c82f9bb24cf25d1207e364f71c7

## Scenario 1 - Fixed set of shared frameworks for testing

global.json

```json
{
"tools": {
"dotnet": {
"sdk": "2.2.202",
"runtimes": {
"dotnet": [ "2.1.1" ],
"aspnetcore": [ "2.2.3" ]
}
}
},

This comment has been minimized.

Sign in to view

Copy link
@chcosta

chcosta Apr 12, 2019 •
edited
Loading

Author Owner

@natemcmaster

I think the parsing here may get a little tricky. The reason, today, that we have "dotnet": "[version]" is because we have to be able to reasonably parse this in eng/common/tools.sh

If we change the format and have a "typical" Arcade repo global.json...

{
  "tools": {
    "dotnet": {
      "sdk": "2.2.202"

... then we can reasonably parse sdk and get the version.

If there's a repo that defines both a standard "sdk.version" and / or a "dotnet sdk" version, then I can imagine that our parsing logic could be easily tripped up.

{
  "sdk": {
    "version": "3.0.0"
  },
 "dotnet": {
    "sdk": "2.2.2"

Perhaps, in some ways that scenario is busted and we should let things fall apart or maybe we can catch the bad condition and ignore it so that we continue parsing. That may get overly complicated.

Practically speaking, we can either try to get cuter with the sdk version parsing, or change the format to something like

{
  "tools": {
    "dotnet": "2.2.202",
    "runtimes": {
      "dotnet/x64": "2.1.503"

... which is basically what we have today but with "runtimes" added. It's not as ideal, but simplifies a bit (less changes here and no changes to darc are required).

This comment has been minimized.

Sign in to view

Copy link
@chcosta

chcosta Apr 12, 2019

Author Owner

Playing around with this, I think we can reasonably make this work by tweaking https://github.com/dotnet/arcade/blob/master/eng/common/tools.sh#L61 to pattern match each line like

function ReadGlobalVersion {
  local key=$1

  local pattern="\"$key\" *: *\"(.*)\""
  local value=""
  while IFS= read -r result
  do
    if [[ $result =~ $pattern ]]; then
      value=${BASH_REMATCH[1]}
      break
    fi
  done < <(grep "$key" "$global_json_file")
  if [[ -z $value ]]; then
    echo "Error: Cannot find \"$key\" in $global_json_file" >&2
    ExitWithExitCode 1
  fi

  # return value
  _ReadGlobalVersion=$value
}

That will return the value only for "sdk": "[value]"

This comment has been minimized.

Sign in to view

Copy link
@natemcmaster

natemcmaster Apr 12, 2019

I think it's worth taking a dependency on jq. Check it out, if you haven't already. https://stedolan.github.io/jq/

image

This comment has been minimized.

Sign in to view

Copy link
@chcosta

chcosta Apr 12, 2019

Author Owner

The parsing story today is a bit fragile; as you propose, we should consder alternatives.

Filed dotnet#2510
"msbuild-sdks": {
"Microsoft.DotNet.Arcade.Sdk": "1.0.0-beta.19207.1",
"Microsoft.DotNet.Helix.Sdk": "2.0.0-beta.19207.1"
}
}
```

Define frameworks (runtimes) in global.json.

Applies to:

- repos with a fixed set of shared frameworks used for testing

Behavior:

- SDK is installed locally (into `.dotnet` folder)

This comment has been minimized.

Sign in to view

Copy link
@natemcmaster

natemcmaster Apr 12, 2019

Suggestion: could we make this .dotnet/win-x64/ or .dotnet/osx-x64/?

Scenarios I'm thinking about:

  • Converting aspnet/AspNetCore to Arcade SDK. We typically need both x86 and x64 SDKs available for some IIS testing
  • AspNetCore also has scripts which let you run the build in a container so that our devs can easily build Linux versions using Docker. Do facilitate this, we the RID as a part of subpath for .dotnet and obj/bin folders, e.g. obj/linux-x64, bin/win-x64, and .dotnet/win-x64/dotnet.exe

This comment has been minimized.

Sign in to view

Copy link
@chcosta

chcosta Apr 12, 2019

Author Owner

What about

dotnet/x64 == x64
dotnet/x86 == x86
dotnet == auto

It's a little weird to include the OS rid here.

This comment has been minimized.

Sign in to view

Copy link
@natemcmaster

natemcmaster Apr 12, 2019

That sounds reasonable to me.
- Frameworks are installed locally (into `.dotnet` folder)
- We print a message during install indicating that location of the installed sdk / frameworks

## Scenario 2 - Dependency flow defined versions of shared frameworks for testing

global.json

```json
{
"tools": {
"dotnet": {
"sdk": "2.2.202",
"runtimes": {
"dotnet": [ "2.1.1", "MicrosoftNetCoreAppVersion" ],

This comment has been minimized.

Sign in to view

Copy link
@natemcmaster

natemcmaster Apr 11, 2019

Love this idea. Maybe for the sake of consistency with MSBuild, we could wrap use the same substitution syntax:

"dotnet": [ "2.1.1", "$(MicrosoftNetCoreAppVersion)" ],

But either way is fine with me.

This comment has been minimized.

Sign in to view

Copy link
@chcosta

chcosta Apr 11, 2019 •
edited
Loading

Author Owner

I need to permit architecture as well. Currently thinking something like...

  "tools": {
    "dotnet": {
      "sdk": "2.2.202",
      "runtimes": {
        "dotnet": {
          "auto": [ "2.1.1" ]
        },
        "aspnetcore": {
          "x64": [ "2.2.3" ]
        }
      }
    }
  },

This comment has been minimized.

Sign in to view

Copy link
@natemcmaster

natemcmaster Apr 12, 2019

What about arch for SDKs? There is an x86 sdk, which is occassionally used in AspNetCore for some x86 IIS testing.

This comment has been minimized.

Sign in to view

Copy link
@chcosta

chcosta Apr 12, 2019 •
edited
Loading

Author Owner

I'll file an issue to follow up on this.

We need at least one sdk to use for toolset restore. The logic for how we would acquire an sdk that would let us use an MSBuil task to parse json and restore additional sdks, would need to be thought through.

This comment has been minimized.

Sign in to view

Copy link
@chcosta

chcosta Apr 12, 2019

Author Owner

Filed dotnet#2509
"aspnetcore": [ "2.2.3", "MicrosoftAspNetCoreAppVersion" ]
}
},
"msbuild-sdks": {
"Microsoft.DotNet.Arcade.Sdk": "1.0.0-beta.19207.1",
"Microsoft.DotNet.Helix.Sdk": "2.0.0-beta.19207.1"
}
}
```

eng/Versions.props

```XML
<Project>
<PropertyGroup>
<MicrosoftNetCoreAppVersion>3.0.0-preview4-19207.1</MicrosoftNetCoreAppVersion>
<MicrosoftAspNetCoreAppVersion>3.0.0-preview4-19207.1</MicrosoftAspNetCoreAppVersion>
...
</PropertyGroup>
</Project>
```

Applies to:

- repos which rely on dependency flow for defining framework versions

Behavior:

- SDK is installed locally (into `.dotnet` folder)
- Frameworks are installed locally (into `.dotnet` folder)
- For non-explicit framework versions, we read in eng/Version.props and translate identified property group values into versions
- We print a message during install indicating that location of the installed sdk / frameworks

0 comments on commit 737e293

Please sign in to comment.