Add DOTNET_ROOT

[damccorm]

Fixes #11

[clairernovotny]

Does this work with SxS? It would need to point to the directory above the versioned directory, I believe. I'm not completely sure.

[damccorm]

I think you're right. Updating

[clairernovotny]

Notice here, https://github.com/microsoft/azure-pipelines-tasks/blob/master/Tasks/DotNetCoreInstallerV1/dotnetcoreinstaller.ts#L15, it points to the a location on the agent's dotnet directory, not any version underneath.

Same thing for the toolPath here: https://github.com/actions/setup-dotnet/blob/master/src/installer.ts#L62. It looks like it's adding the versioned directory to the path, not the dotnet directory above it?

[damccorm]

Yep. Also needs to happen even if we're pulling from the cache, so updating to do that as well

[damccorm]

Should be right now

[clairernovotny]

toolPath is the non-versioned path? I couldn't tell from a quick skim

[damccorm]

Ah no, didn't quite understand the ask. Sorry, bouncing between too many things right now, will drill into this now.

Right now, toolPath points to the directory that contains a specific version of dotnet (aka $RUNNER_TOOL_CACHE/dncs/<version>/<arch>)

I'll update to point to RUNNER_TOOL_CACHE/dncs instead, definitely is the right thing as you've suggested. Updating what we're adding to the path doesn't seem right to me though. I think we should keep that pointing to the versioned path so that dotnet <command> resolves to the correct version, and I don't quite understand why we would point that to the unversioned folder. Thoughts?

[clairernovotny]

I'm not an expert in this, but I thought there's supposed to be a muxer in the root that knows how to find the versioned dotnet underneath.

@richlander can you help triage? What's the correct behavior for SxS on a build agent?

[damccorm]

My understanding is that you can do it that way, but I don't think we need to. I don't see any advantages to changing to this behavior, I'm open to doing it if there are though.

My inclination is also probably to finish this PR and address that in a separate follow up issue - does that seem fair?

[sburns]

Hey y'all, I'm by no means a .Net developer, however I'm trying to get a C# lambda deployed via Actions. After setting up dotnet w/ this wonderful action and installing the lambda tools with dotnet tool install -g Amazon.Lambda.Tools, this log is emitted:

Since you just installed the .NET Core SDK, you will need to logout or restart your session before running the tool you installed.

Subsequent steps die because they can't find dotnet-lambda. Is this related? If not, sorry for crashing your PR.

[damccorm]

@sburns I think that's unrelated - see this issue https://github.com/dotnet/cli/issues/8368

It looks like Dotnet requires a new process to be started in order for installations to fully succeed (which is weird and seems like a bug on their end to me). We can't completely exit the process from the runner so I'm not sure there's much we can do about this.

With that said, I'm guessing that this workaround used in a different CI environment will probably work here as well?

[sburns]

@damccorm thanks for the heads up! I worked around it by writing a local action that installs the lambda tools during the image build, was the easiest way I could find to get that new process.