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

.NET Core global tools shim fails if .NET Core is not installed in default location #9114

Open
natemcmaster opened this Issue Apr 20, 2018 · 38 comments

Comments

Projects
None yet
@natemcmaster
Copy link
Member

natemcmaster commented Apr 20, 2018

Steps to reproduce

Download .NET Core CLI to $env:USERPROFILE/.dotnet/x64 and install a global tool

$env:PATH="$env:USERPROFILE/.dotnet/x64;$env:PATH"
dotnet-install.ps1 -Version 2.1.300-preview3-008646 -InstallDir $env:USERPROFILE/.dotnet/x64
dotnet-install.ps1 -Runtime aspnetcore -Version 2.1.0-preview2-final -InstallDir $env:USERPROFILE/.dotnet/x64
dotnet tool install -g dotnet-serve
dotnet-serve

Expected behavior

The generated shim dotnet-serve.exe should find and use the dotnet on PATH to launch the global tool.

Actual behavior

If no .NET Core is installed in C:\Program Files\dotnet

PS > dotnet-serve
A fatal error occurred, the required library hostfxr.dll could not be found.
If this is a self-contained application, that library should exist in [C:\Users\namc\.dotnet\tools\.store\dotnet-serve\0.3.0\dotnet-serve\0.3.0\tools\netcoreapp2.1\any\].
If this is a framework-dependent application, install the runtime in the default location [C:\Program Files\dotnet] or use the DOTNET_ROOT environment variable to specify the runtime location.

If .NET Core is installed in C:\Program Files\dotnet, but doesn't have the right shared framework version

PS> $env:COREHOST_TRACE=1
PS> dotnet-serve
Tracing enabled
--- Invoked apphost [version: 2.1.0-rc1-26419-02, commit hash: 515f580aa000600da03e81537396d2253b16fa12] main = {
C:\Users\namc\.dotnet\tools\dotnet-serve.exe
}
The managed DLL bound to this executable is: '.store\dotnet-serve\0.3.0\dotnet-serve\0.3.0\tools\netcoreapp2.1\any\dotnet-serve.dll'
Using default installation location [C:\Program Files\dotnet] as runtime location.
Reading fx resolver directory=[C:\Program Files\dotnet\host\fxr]
Considering fxr version=[2.0.5]...
Considering fxr version=[2.0.6]...
Considering fxr version=[2.0.7]...
Detected latest fxr version=[C:\Program Files\dotnet\host\fxr\2.0.7]...
Resolved fxr [C:\Program Files\dotnet\host\fxr\2.0.7\hostfxr.dll]...
Loaded library from C:\Program Files\dotnet\host\fxr\2.0.7\hostfxr.dll
Probed for and did not resolve library symbol ????????????
The required library C:\Program Files\dotnet\host\fxr\2.0.7\hostfxr.dll does not support relative app dll paths.

Environment data

dotnet --info output:

.NET Core SDK (reflecting any global.json):
 Version:   2.1.300-preview3-008646
 Commit:    8e01912b36

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.16299
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Users\namc\.dotnet\x64\sdk\2.1.300-preview3-008646\

Host (useful for support):
  Version: 2.1.0-rc1-26419-02
  Commit:  515f580aa0

.NET Core SDKs installed:
  2.1.4 [C:\Users\namc\.dotnet\x64\sdk]
  2.1.100 [C:\Program Files\dotnet\sdk]
  2.1.105 [C:\Users\namc\.dotnet\x64\sdk]
  2.1.300-preview2-008530 [C:\Users\namc\.dotnet\x64\sdk]
  2.1.300-preview3-008646 [C:\Users\namc\.dotnet\x64\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.0-preview2-30478 [C:\Users\namc\.dotnet\x64\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.0-preview2-final [C:\Users\namc\.dotnet\x64\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.0-rc1-30613 [C:\Users\namc\.dotnet\x64\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.0-preview2-final [C:\Users\namc\.dotnet\x64\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.0-rc1-30613 [C:\Users\namc\.dotnet\x64\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 1.1.5 [C:\Users\namc\.dotnet\x64\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.7 [C:\Users\namc\.dotnet\x64\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.0-preview2-26406-04 [C:\Users\namc\.dotnet\x64\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.0-rc1-26419-02 [C:\Users\namc\.dotnet\x64\shared\Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

@natemcmaster

This comment has been minimized.

Copy link
Member

natemcmaster commented Apr 20, 2018

Possible solution: the apphost should automatically default DOTNET_ROOT to the first dotnet.exe on PATH.

@livarcocc

This comment has been minimized.

Copy link
Member

livarcocc commented Apr 20, 2018

This is by design and the decision we made on the host taking many different things in consideration. I believe the dotnet install message will guide you to setting DOTNET_ROOT if your dotnet is not installed in the default location.

@livarcocc livarcocc added this to the Discussion milestone Apr 20, 2018

@natemcmaster

This comment has been minimized.

Copy link
Member

natemcmaster commented Apr 20, 2018

My concern about this design is that the error message is not clear when there are some .NET Core runtime installations in C:\Program Files\dotnet, but not the right ones for the global tool. How would a user ever figure this out from this?

PS> dotnet-serve
The required library C:\Program Files\dotnet\host\fxr\2.0.7\hostfxr.dll does not support relative app dll paths.
@livarcocc

This comment has been minimized.

Copy link
Member

livarcocc commented Apr 20, 2018

@steveharter is this something that we could improve in the host?

@steveharter

This comment has been minimized.

Copy link
Member

steveharter commented Apr 20, 2018

The error message could be extended to provide more information, but is really a short-term problem since once the hostfxr should be updated (once) it should be good forever for this particular error message.

Possible solution: the apphost should automatically default DOTNET_ROOT to the first dotnet.exe on PATH.

I'd prefer not to start probing %PATH%

@natemcmaster

This comment has been minimized.

Copy link
Member

natemcmaster commented Apr 20, 2018

I'd prefer not to start probing %PATH%

Can you elaborate? It seems like it would be a better user experience, but want to know why you would rather not.

I was expecting this PATH lookup behavior because it's one we depend on to make Visual Studio work SDKs installed into user-locations. It's also one less variable that we have to set to make CI builds work well. We already have a handful, and the list seems to be ever growing.

@steveharter

This comment has been minimized.

Copy link
Member

steveharter commented Apr 26, 2018

@richlander

Probing %PATH% for dotnet.exe is not intuitive and somewhat error-prone as we can't exactly duplicate what the OS does. That's why we added %DOTNET_ROOT%

@tmds

This comment has been minimized.

Copy link
Member

tmds commented Apr 27, 2018

I filed the same issue for Linux: dotnet/core-setup#4078. I have the same expectation as @natemcmaster: dotnet should be searched on PATH.
For source-build Red Hat, Fedora and CentOS, dotnet is not installed at the 'default' location. So tools fail out-of-the-box 😕

CC @eerhardt @dleeapho @omajid

An alternative solution (dotnet/core-setup#4078 (comment)) is to allow source-build to specify the 'default' location. That would fix the source-build case, but not @natemcmaster's case. This would still require setting DOTNET_ROOT. Perhaps we can use this fallback order: DOTNET_ROOT, PATH probing, hard-coded path.

A pseudo Unix implementation for finding the root via PATH:

segments = split PATH by ':'
foreach segment
  dotnet_path = concat(segment, "/dotnet")
  if (stat(dotnet_path, out dotnet_stat) == SUCCESS && dotnet_stat.isExecutable)
     if (realpath(dotnet_path, out dotnet_real) == SUCCESS)
        return dirname(dotnet_real)
return null
@dasMulli

This comment has been minimized.

Copy link
Contributor

dasMulli commented Apr 27, 2018

Aren't there other things already looking for dotnet.exe on the %PATH%?
MSBuildSdkResolver AFAIK

This could lead to situations where dotnet-mytool and dotnet mytool may end up choosing a different runtime. The question here is what a user would expect..

@tmds

This comment has been minimized.

Copy link
Member

tmds commented Apr 27, 2018

Independent of implementation, a user expects this to work:

$ dotnet tool install -g dotnet-serve
$ dotnet-serve
@eerhardt

This comment has been minimized.

Copy link
Member

eerhardt commented Apr 27, 2018

The issue I have with probing the %PATH% env var is that the %PATH% variable is used to locate executables to run. In this case, we've already found the executable to run. The dotnet-serve executable was located and loaded and started executing. The %PATH% environment variable served its purpose.

Now, the dotnet-serve executable needs to load some more libraries (ex. coreclr, System.Private.CoreLib, etc). Why should the PATH variable be involved with how to locate more libraries? It's main purpose is for locating executables to be executed.

In my opinion it conflates the job/purpose of the PATH environment variable. It can also lead to other side effects, such as having 2 "dotnet hives" installed on your machine. One on the PATH, and one not. Now if you invoke /path/to/dotnet tool install -g dotnet-serve and then run dotnet-serve it won't necessarily use the same "dotnet hive" you used to install it.

That's why we introduced a new environment variable that serves a single purpose - locating the "dotnet hive".

@tmds

This comment has been minimized.

Copy link
Member

tmds commented Apr 27, 2018

@eerhardt what do you think about this order then: DOTNET_ROOT, hard-coded path, PATH probing.

  • where host currently fails with an error message, it will try to probe the PATH.
  • and for use-cases where there is a system install, but you want to use another dotnet hive you need to set DOTNET_ROOT.
@livarcocc

This comment has been minimized.

Copy link
Member

livarcocc commented Apr 27, 2018

@natemcmaster

This comment has been minimized.

Copy link
Member

natemcmaster commented Apr 27, 2018

A agree with what @tmds said. It was my expectation that after dotnet tool install, dotnet serve would use the same dotnet used to install the tool. I think many users will expect this.

To @eerhardt's points:

Why should the PATH variable be involved with how to locate more libraries? It's main purpose is for locating executables to be executed.

I understand the engineering purity of this argument, but think there is another compelling point to consider. PATH probing is consistent with how the rest of the product behaves. Over the last few years, we have been teaching people that you can install .NET Core into a custom location. If you put it on PATH first, Visual Studio, VS Code, MSBuild.exe, and the command line will use that custom install location. The current behavior of global tools breaks from this pattern. And from what I'm hearing, the reasons for breaking from that pattern seem to be narrowly focused on what the apphost should do, not on the behavior of the .NET Core product as a whole.

Now if you invoke /path/to/dotnet tool install -g dotnet-serve and then run dotnet-serve it won't necessarily use the same "dotnet hive" you used to install it.

I agree with you here. I would not expect dotnet-serve to find /path/to/dotnet. That said, I'm not asking this. I'm asking for PATH probing.

Let me be completely clear why this is so maddening to me. The majority of .NET Core tools today are written so they can be invoked as dotnet <command> (that's a subject for another conversation, but it's the reality of the current world.) If I have C:\custom\dotnet.exe first on PATH, when invoking dotnet <command>, the "dotnet" used is C:\custom\dotnet.exe, but the CLI will launch <command> part in a new context that ignores C:\custom\. If nothing else, please set DOTNET_ROOT from the CLI to the current location so any subprocesses launched by the CLI will resolve to the same dotnet.exe.

@steveharter

This comment has been minimized.

Copy link
Member

steveharter commented Apr 28, 2018

Concerns

  1. The OS does all of the %PATH% probing today, so this would be a new area for us to consider. We can't guarentee we follow the same rules as how the OS uses %PATH%
  2. Performance: if there are 20 folders in %PATH% before we find a hit (or miss) we would be probing\reading 20 folders and possibly doing a stat to ensure executable...
  3. We would need to ensure this is not a security\hijack concern

That said, I agree that the scenario is real and proposed solution has merit. We did consider this during the design phase, I can PM you that link. However, that discussion for %PATH% was not considered as a last-resort fallback at the time; instead it was competing with %DOTNET_ROOT% as the primary mechanism.

@tmds

This comment has been minimized.

Copy link
Member

tmds commented Apr 28, 2018

The OS does all of the %PATH% probing today

On Linux this is implemented in user-space. For example, corefx implementation is here: https://github.com/dotnet/corefx/blob/9bfa3bd511a6a2152de8192332b0e439917e65e0/src/System.Diagnostics.Process/src/System/Diagnostics/Process.Unix.cs#L480-L498

Performance: if there are 20 folders in %PATH% before we find a hit (or miss) we would be probing\reading 20 folders and possibly doing a stat to ensure executable...

A lot of things get probed (executable on PATH, libraries on LD_LIBRARY_PATH, ...) and we don't perceive slowness. The earlier on PATH, the sooner the match.

We would need to ensure this is not a security\hijack concern

Using data from PATH is as secure as using data from DOTNET_ROOT.

that discussion for %PATH% was not considered as a last-resort fallback at the time

For the reasons explained by @natemcmaster my preferred order is DOTNET_ROOT, PATH probing, hard-coded path

For source-build, we want to be able to set the hard-coded path. If path probing is implemented, we can rely on that for now. If there is no path probing, we need to make the hard-coded path a setting that can be specified from source-build.

@enricosada

This comment has been minimized.

Copy link
Collaborator

enricosada commented May 2, 2018

same issue with 2.1.300-preview2-008530 on win-10
i installed that from zip and added to PATH (that's what we do in build servers, no global installs)

if i do:

dotnet install dotnet-mytool --tool-path my\tools\dir

the install is ok

but doesnt works running it directly with my\tools\dir\dotnet-mytool.exe giving error:

The required library C:\Program Files\dotnet\host\fxr\2.0.6\hostfxr.dll does not support startupconfig.json functionality.

As a note, that installed is higher priority in PATH (where dotnet and dotnet --info use that) than the .net sdk installed globally, but seems to resolve the globally installed dotnet sdk. global.json doesnt help.

setting DOTNET_ROOT env var to the unzip path fix the issue but is a lot less nice.

@tmds

This comment has been minimized.

Copy link
Member

tmds commented May 3, 2018

@richlander @KathleenDollard can you chime in please?
It would be best to decide how this works for 2.1.

@richlander

This comment has been minimized.

Copy link
Member

richlander commented May 3, 2018

This is a real issue. We discussed it when we were designing global tools. We didn't discuss the point that @natemcmaster raised on installation and execution of a tool not agreeing on .NET Core location. That's a real challenge.

I'm not going to propose anything just yet, but need to information collect a bit more.

Aren't there other things already looking for dotnet.exe on the %PATH%?
MSBuildSdkResolver AFAIK

Can someone point me to the code that does this?

@natemcmaster

This comment has been minimized.

Copy link
Member

natemcmaster commented May 3, 2018

var dotnetExe = environmentProvider.GetCommandPath("dotnet");

@enricosada

This comment has been minimized.

Copy link
Collaborator

enricosada commented May 3, 2018

as a note.

  • install .net core sdk 2.1.300-preview2 from unzipping
  • add to PATH in front (=> priority), like set PATH=%CD%;%PATH%
  • dotnet tool install dotnet-serve --tool-path mybin (install to specific dir)
You can invoke the tool using the following command: dotnet-serve
Tool 'dotnet-serve' (version '0.3.0') was successfully installed.

But both are broken, also direct run of the .exe:

E:\>dotnet serve
The required library C:\Program Files\dotnet\host\fxr\2.0.6\hostfxr.dll does not support startupconfig.json functionality.

E:\>mybin\dotnet-serve.exe
The required library C:\Program Files\dotnet\host\fxr\2.0.6\hostfxr.dll does not support startupconfig.json functionality.

at least the second should work. seetting DOTNET_ROOT fix that.

the dotnet is found on PATH correctly

E:\>where dotnet
c:\dotnetcli\dotnet-sdk-2.1.300-preview2-008530-win-x64\dotnet.exe
C:\Program Files\dotnet\dotnet.exe

but the host\fxr\2.1.0-preview2-26406-04\hostfxr.dll is not probed, so falling back to previous globally installed C:\Program Files\dotnet\host\fxr\2.0.6

@tmds

This comment has been minimized.

Copy link
Member

tmds commented May 15, 2018

@richlander do you have an update?

@dasMulli

This comment has been minimized.

Copy link
Contributor

dasMulli commented May 15, 2018

One of the key side-by-side promises of .NET Core was that you could just run an executable from a folder and add things to the PATH, it would be very nice if global tools would follow this approach.

If the PATH was probed as a last resort fallback then it may not be a breaking change after 2.1.300 and could maybe be done for 2.1.400? It would only enable things that would not have worked before anyway and wouldn't break things that used to work before.

@livarcocc

This comment has been minimized.

Copy link
Member

livarcocc commented May 15, 2018

We are working on trying to find alternatives to improve this scenario. I will post back once we know more.

@tmds

This comment has been minimized.

Copy link
Member

tmds commented May 31, 2018

I'm comparing the gobal tools with npm tools.
observations:

  • -g for npm is independent of users, while -g for dotnet installs into a user folder.
  • tools for npm use node that is on PATH

@livarcocc @richlander if you are changing the design of this, please consider doing a https://github.com/dotnet/designs.

@welkie

This comment has been minimized.

Copy link

welkie commented Jul 1, 2018

I seem to be running into this after upgrading to 2.1 on Arch Linux and attempting to use EF Core migrations. Because migrations are now implemented as a global tool, I receive a message instructing me to install it:

$ dotnet ef migrations add Init
Cannot find command 'dotnet ef', please run the following command to install

dotnet tool install --global dotnet-ef

But when trying to install it, I get this message. I tried to set DOTNET_ROOT to the executable my system's package manager set up, but it still doesn't work. I also tried setting DOTNET_ROOT as the directory where that executable lies. It still didn't help. What should DOTNET_ROOT be set as?

$ echo $DOTNET_ROOT
/usr/bin/dotnet
$ which dotnet
/usr/bin/dotnet
$ dotnet ef migrations add Init
A fatal error occurred, the required library libhostfxr.so could not be found.
If this is a self-contained application, that library should exist in [/home/mwelke/.dotnet/tools/.store/dotnet-ef/2.1.1/dotnet-ef/2.1.1/tools/netcoreapp2.1/any/].
If this is a framework-dependent application, install the runtime in the default location [/usr/share/dotnet] or use the DOTNET_ROOT environment variable to specify the runtime location.
$ export DOTNET_ROOT=/usr/bin
$ dotnet ef migrations add Init
A fatal error occurred, the required library libhostfxr.so could not be found.
If this is a self-contained application, that library should exist in [/home/mwelke/.dotnet/tools/.store/dotnet-ef/2.1.1/dotnet-ef/2.1.1/tools/netcoreapp2.1/any/].
If this is a framework-dependent application, install the runtime in the default location [/usr/share/dotnet] or use the DOTNET_ROOT environment variable to specify the runtime location.
$ echo $DOTNET_ROOT
/usr/bin
@wli3

This comment has been minimized.

Copy link
Collaborator

wli3 commented Jul 1, 2018

@welkie the layout under DOTNET_ROOT should be like this. The directory that has the dotnet executable but not the symbol link

.
├── dotnet
├── host
│   └── fxr
├── LICENSE.txt
├── sdk
│   ├── 2.1.300-rc1-008673
│   └── NuGetFallbackFolder
├── shared
│   ├── Microsoft.AspNetCore.All
│   ├── Microsoft.AspNetCore.App
│   └── Microsoft.NETCore.App
└── ThirdPartyNotices.txt

@tmds

This comment has been minimized.

Copy link
Member

tmds commented Jul 2, 2018

This finds dotnet on PATH and determines DOTNET_ROOT based on that:

export DOTNET_ROOT=$(dirname $(realpath $(which dotnet)))
@welkie

This comment has been minimized.

Copy link

welkie commented Jul 2, 2018

@wli3 @tmds Thank you both for your help. I understand now where the env var is supposed to point and the shortcut command to locate it based on the path of the executable worked perfectly for me. I just added that to my .bashrc file.

@poke

This comment has been minimized.

Copy link

poke commented Jul 7, 2018

Python solves this problem by putting tool executables into a folder that is inside the Python installation directory. So every installation can have its own set or tools.

Wouldn't it possible to do this as well for custom Core installations? E.g. put the tools into folder inside the folder that has the dotnet executable. Tools would then look up and check if there's a dotnet that they can use and otherwise fall back to a global path.

@dasMulli

This comment has been minimized.

Copy link
Contributor

dasMulli commented Jul 7, 2018

The problem here is that on most systems, dotnet will be installed somewhere that would require administrative access (windows admin, superuser permission on *nix) to create directories in. It would also lead to users sharing their tools should they be installed in a global directory.

@poke

This comment has been minimized.

Copy link

poke commented Jul 7, 2018

But if I use a custom path, isn’t it that I would usually want to restrict the program to only that path?

When I think about my shared Linux days where I was trapped as a normal user to my own home directory, whenever I installed something, I would install it in my home directory, the only place I do have write access to. I think if I install .NET Core into e.g. /home/poke/dotnet-core/, then I would also expect global dotnet tools to be installed in there.

@tmds

This comment has been minimized.

Copy link
Member

tmds commented Jul 11, 2018

Python solves this problem by putting tool executables into a folder that is inside the Python installation directory. So every installation can have its own set or tools.

npm is similar. When installing with -g, that becomes part of the npm installation.

The problem here is that on most systems, dotnet will be installed somewhere that would require administrative access (windows admin, superuser permission on *nix) to create directories in.

npm global means the tool becomes available for everyone using that npm install. So if it is the system wide installation, it makes sense the install requires elevated permissions.

dotnet global means for this user. (I think this was named global because DotNetCliToolReference is per-project.)

@KathleenDollard

This comment has been minimized.

Copy link

KathleenDollard commented Jul 11, 2018

@tmds We struggled with using --global since it is user, not machine. But we felt that the majority of machines with the SDK installed would be single user machines, and thus we felt that the majority of people would never notice and the rest would think "oh, sort of global". We definitely wanted to avoid requiring admin to install global tools.

This problem, being able to find the runtime for the global tool is clearly one we should solve.

@dasMulli

This comment has been minimized.

Copy link
Contributor

dasMulli commented Jul 11, 2018

I like the "user-global" approach better since it also works great on shared machines like in educational facilities (the only bug hurting there is with global /tmp restrictions - https://stackoverflow.com/questions/45950644/prevent-net-core-2-0-from-leaving-files-in-tmp-on-rhel7 / Microsoft/msbuild#1479).

A fallback lookup for dotnet on the PATH is also similar to all the scripts starting with shebangs like

#!/usr/bin/env node
#!/usr/bin/env python3
@tmds

This comment has been minimized.

Copy link
Member

tmds commented Jul 11, 2018

I don't consider one better than the other. I think of them as different scopes for different use-cases. I wish --global was named --user (... naming is hard).

@tmds

This comment has been minimized.

Copy link
Member

tmds commented Dec 6, 2018

The framework dependent apphost (dotnet/sdk#2578) is also affected by this.

omajid added a commit to omajid/dotnet-regular-tests that referenced this issue Dec 7, 2018

Add a test for framework-dependent apphost
Starting in .NET Core 3.0, `dotnet publish` can produce
framework-dependent executibles instead of framework dependent dll
files. But these can fail to work out of the box unless .NET Core is
installed in a known location or DOTNET_ROOT is defined.

See dotnet/cli#9114

omajid added a commit to omajid/dotnet-regular-tests that referenced this issue Dec 7, 2018

Add a test for framework-dependent apphost
Starting in .NET Core 3.0, `dotnet publish` can produce
framework-dependent executibles instead of framework dependent dll
files. But these can fail to work out of the box unless .NET Core is
installed in a known location or DOTNET_ROOT is defined.

See dotnet/cli#9114

RheaAyase added a commit to redhat-developer/dotnet-regular-tests that referenced this issue Dec 8, 2018

Add a test for framework-dependent apphost
Starting in .NET Core 3.0, `dotnet publish` can produce
framework-dependent executibles instead of framework dependent dll
files. But these can fail to work out of the box unless .NET Core is
installed in a known location or DOTNET_ROOT is defined.

See dotnet/cli#9114
@AArnott

This comment has been minimized.

Copy link

AArnott commented Dec 9, 2018

Installing a local tool and running it passes on Linux-based microsoft/dotnet docker images but fails on Hosted OSX agents from Azure Pipelines.

enricosada added a commit to jet/falanx that referenced this issue Dec 13, 2018

disable osx CI
the azure agent doesnt set DOTNET_ROOT and global tools doesnt work

ref Microsoft/azure-pipelines-image-generation#531
ref dotnet/cli#9114

enricosada added a commit to jet/falanx that referenced this issue Dec 13, 2018

Set up CI with Azure Pipelines (#86)
Set up CI with Azure Pipelines, replace Travis and Appveyor

The OSX CI is not added because the azure agent for OSX doesnt set DOTNET_ROOT and global tools doesnt works, so a test fails

ref Microsoft/azure-pipelines-image-generation#531
ref dotnet/cli#9114

The scala tests are ignored too, because sbt is not installed in the azure agent

7sharp9 added a commit to jet/falanx that referenced this issue Dec 21, 2018

Set up CI with Azure Pipelines (#86)
Set up CI with Azure Pipelines, replace Travis and Appveyor

The OSX CI is not added because the azure agent for OSX doesnt set DOTNET_ROOT and global tools doesnt works, so a test fails

ref Microsoft/azure-pipelines-image-generation#531
ref dotnet/cli#9114

The scala tests are ignored too, because sbt is not installed in the azure agent
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment