-
Notifications
You must be signed in to change notification settings - Fork 258
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
Improve DOTNET_HOST_PATH environment variable handling #7438
Comments
I don't think the work around is a good idea. I'm curious why DOTNET_HOST_PATH is not set however. |
Hi,
To reproduce, launching a build on AppVeyor is enough (it’s where I hit the issue).
After having seen the code, I imagined this “work around” (that is more a safety belt up to me 😊) .
This morning I took the time to google it and bingo:
http://source.roslyn.io/#Microsoft.Build.Tasks.CodeAnalysis/BuildServerConnection.cs,384
It’s here also…
|
I get that the workaround might have been used in other place, but for this scenario, it's super important that the CLI is exactly the same. This variable should normally always be set. /cc @nguerrera @livarcocc Is there a CLI version in which the DOTNET_HOST_PATH is not set? |
Any .NET Core SDK 2.0.* or lower would not set it. We started setting it in 2.1.*. That doesn't appear to be the issue here, because the issues says netcoreapp2.1 and no SDK that would support that would not set it. Rather, I think it is this: "(no client, direct code from a console app)," DOTNET_HOST_PATH is currently set by the CLI when shelling out to msbuild, it is not set for all child processes of the dotnet.exe host. Furthermore, even if the dotnet.exe host did that, there is no guarantee that code running on .NET Core is running in a dotnet.exe host. It could be an apphost or some custom host. |
I can confirm. By using the NuGet.Protocol packages directly from a console app runned by a "dotnet run" in NetCoreApp2.1, the "safety belt" is kind of required... |
OK... But... can anyone explain to me how NuGet.Protocol can be used from a .Net console App? It seems to me that there is a critical architectural issue here.... or am I missing something? [Edit] |
Sorry for reviving this a bit; But i came across the exact same issue. I'm trying to use NuGet.Protocol (or rather, Using the github.com/NuKeeperDotNet/NuKeeper library) directly with an Azure DevOps feed (and the Azure Artifacts Credential Provider) and getting the exact same issue. I have dotnet SDKs installed ranging from 2.1 to latest 3.0 preview - Yet i do NOT have Not sure where to take this forward from here. |
.NET Core SDK 3.1.100 on MacOS also doesn't set At the very least, a check in that block of code so it's not the process throwing an InvalidOperationException would be nice. var hostPath = Environment.GetEnvironmentVariable("DOTNET_HOST_PATH");
if (String.IsNullOrEmpty(hostPath))
{
throw new InvalidOperationException("Missing DOTNET_HOST_PATH environment variable. Unable to start plugin.");
}
var startInfo = new ProcessStartInfo
{
FileName = hostPath,
Arguments = $"\"{filePath}\" " + args,
...
}; Would folks be open to a PR for that? |
I think based on @nguerrera's response
we should consider just calling If we want to be smarter we can expose a component that allows the caller to control exactly what's being used, but that might be overkill. @dtivel thoughts? |
Hey folks, I think it's ok to fall back to At this point I'm not sure when we'd be able to get to this, but we'd be happy to take a PR. |
Should I sign a CLA or something? |
Details about Problem
While using NuGet.Core v.4.8.0.6, with the Microsoft/artifacts-credprovider (no client, direct code from a console app), in netcoreapp2.1, runned in AppVeyor. Got:
This is fixed with this environment variable (and the explanation is in the comment):
HTH
The text was updated successfully, but these errors were encountered: