Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support installing multiple versions of .NET Core SxS #25

Open
natemcmaster opened this issue Aug 22, 2019 · 11 comments
Open

Support installing multiple versions of .NET Core SxS #25

natemcmaster opened this issue Aug 22, 2019 · 11 comments
Labels

Comments

@natemcmaster
Copy link

@natemcmaster natemcmaster commented Aug 22, 2019

I would like to use this action to setup .NET Core for some class libraries I support. I like to run tests on multiple versions of .NET Core, but it appears I cannot use this task to install multiple versions of .NET Core.

Repro

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/setup-dotnet@v1
      with:
        version: '2.1.801'        
    - run: dotnet --info
    - uses: actions/setup-dotnet@v1
      with:
        version: '3.0.100-preview8-013656'
    - run: dotnet --info

Expected

Both .NET Core 2.1 and 3.0 are installed and available when running dotnet commands.

Actual

Usages of actions/setup-dotnet are not additive; the last one wins, so only 3.0.100-preview8-013656 is available.

logs.zip

@damccorm

This comment has been minimized.

Copy link
Contributor

@damccorm damccorm commented Aug 22, 2019

This seems like reasonable behavior to me, but I may be missing something - in general, I think I would want the most recent version to win. Also note that after you've installed a version once, setting it back to that version is essentially free since its cached, you just need to run setup-dotnet again with that version.

Am I missing a use case here?

@natemcmaster

This comment has been minimized.

Copy link
Author

@natemcmaster natemcmaster commented Aug 23, 2019

Here is one use case (there are more, but this is the most common). Consider, for instance, a test project file like this:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
     <TargetFrameworks>netcoreapp3.0;netcoreapp2.2;netcoreapp2.1</TargetFrameworks>
  </PropertyGroup>
  <ItemGroup>
     <PackageReference Include="xunit" Version="2.4.1" />
     <PackageReference Include="Microsoft.NET.Test.Sdk" Version="16.0.0" />
  </ItemGroup>
</Project>

When you run dotnet test for this project, the test runner will launch tests for the three versions of .NET Core listed, 2.1, 2.2, and 3.0. If only 3.0 is installed, the 2.1 and 2.2 test runs would fail.

The way to make this work is to install all versions of .NET Core into the same root folder.

@natemcmaster

This comment has been minimized.

Copy link
Author

@natemcmaster natemcmaster commented Aug 23, 2019

Elaborating more on on this:

The way to make this work is to install all versions of .NET Core into the same root folder.

.NET Core can have multiple versions installed side by side. Invoking the dotnet executable dispatches to the right version based on the app's configuration. So, with the repro above, I was expecting to see the installation of .NET Core look something like this on disk:

- /opt/tools/dotnet/x64/
    + dotnet                             <--- the main dotnet executable on PATH
    - shared/
        - Microsoft.NETCore.App/
            + 2.1.12/
            + 3.0.0-preview8-28405-07/
        - Microsoft.AspNetCore.App/
            + 2.1.12/
            + 3.0.0-preview8.19405.7/
    - sdk/
        + 2.1.801/
        + 3.0.100-preview8-013656/

The actual layout created by the setup-dotnet action was to install .NET Core into two different locations:

- /opt/hostedtoolcache/dncs/2.1.801/x64/
    + dotnet
    - shared/
        - Microsoft.NETCore.App/
            + 2.1.12/
        - Microsoft.AspNetCore.App/
            + 2.1.12/
    - sdk/
        + 2.1.801/
- /opt/hostedtoolcache/dncs/3.0.100-preview8-013656/x64/
    + dotnet
    - shared/
        - Microsoft.NETCore.App/
            + 3.0.0-preview8-28405-07/
        - Microsoft.AspNetCore.App/
            + 3.0.0-preview8.19405.7/
    - sdk/
        + 3.0.100-preview8-013656/

Both /opt/hostedtoolcache/dncs/3.0.100-preview8-013656/x64/dotnet and /opt/hostedtoolcache/dncs/2.1.801/x64/dotnet are in PATH, but the 3.0 version is listed first so it wins.

@NickCraver

This comment has been minimized.

Copy link

@NickCraver NickCraver commented Sep 2, 2019

I just hit this as well. Context: we need to test libs against 2.x and 3.x (same as @natemcmaster) but the install for both doesn't work. Still getting the CI/CD working, but I'm currently jammed up on this issue. If it helps, my log is at: https://github.com/MiniProfiler/dotnet/pull/416/checks?check_run_id=210166603

@daveaglick

This comment has been minimized.

Copy link

@daveaglick daveaglick commented Sep 5, 2019

Multiple SDK version support is also important for things like build tooling. For example, Cake requires one version of the SDK but the app being built may require a different version.

@blane-nelson

This comment has been minimized.

Copy link

@blane-nelson blane-nelson commented Sep 12, 2019

I hit this as well. I was able to get around by using the --framework parameter for dotnet, but it makes the yml file more complex, because of having the extra steps to switch the framework back and forth. If this can be changed so that it adds each sdk side by side I think it would be helpful.

@bryanmacfarlane bryanmacfarlane changed the title Support installing multiple versions of .NET Core Support installing multiple versions of .NET Core SxS Sep 15, 2019
@alaatm

This comment has been minimized.

Copy link

@alaatm alaatm commented Nov 21, 2019

This is also required when a referenced library is explicitly using a different runtime. Having the latest 3.0 and attempting to build the project will cause an error, for example: The specified framework 'Microsoft.NETCore.App', version '2.0.0' was not found. Just got stuck with this issue!

@msmolka

This comment has been minimized.

Copy link

@msmolka msmolka commented Nov 22, 2019

I have other issue. I have app multitarget: net461, netstandard2, netcoreap3. To build it I need SDK 3. To test netstandard I need SDK 2 for netcoreapp. So for now I'm not able to test it properly for multitarget.

@alaatm

This comment has been minimized.

Copy link

@alaatm alaatm commented Nov 22, 2019

The following can be used as a workaround until this gets implemented:

  - name: Setup .net core 2.2
    uses: actions/setup-dotnet@v1
    with:
      dotnet-version: 2.2.402

  - name: Setup .net core 3.0
    uses: actions/setup-dotnet@v1
    with:
      dotnet-version: 3.0.100

  - name: .net SxS
    run: |
      rsync -a ${DOTNET_ROOT/3.0.100/2.2.402}/* $DOTNET_ROOT/

@actions actions deleted a comment Nov 27, 2019
casz added a commit to casz/GitLabApiClient that referenced this issue Dec 22, 2019
@casz

This comment has been minimized.

Copy link

@casz casz commented Dec 22, 2019

@alaatm thanks for the workaround 🙏

@airbreather

This comment has been minimized.

Copy link

@airbreather airbreather commented Jan 14, 2020

Our use case: our automated tests run on netcoreapp2.2 so that the solution should continue to build and run on Visual Studio 2017, but our published NuGet packages use package license expressions. Support for package license expressions was only added in SDK version 3.0.

So we need SDK version 3.0+, and I would prefer to have version 2.2 of the runtime available in order to run the actual tests (as opposed to artificially changing the tests to target whatever version of the runtime happens to come with whatever version of the SDK happens to be used to build the project).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
10 participants
You can’t perform that action at this time.