dotnet tool install fails #11244

MarcoRossignoli · 2020-04-11T08:50:09Z

I get error when installing dotnet tool and seem related to long path(not sure if it's related to #10708)

C:\git\coverlet\test\coverlet.integration.tests\bin\Debug\netcoreapp3.1\d366c85b6c244c8b86cca264210c9e9c (fixnightly -> origin)
λ dotnet tool install coverlet.console --version 1.7.2-preview-0001-g96f4e91319 --tool-path C:\git\coverlet\test\coverlet.integration.tests\bin\Debug\netcoreapp3.1\d366c85b6c244c8b86cca264210c9e9c\coverletTool
Microsoft.NET.HostModel.HResultException: 80070002
   at Microsoft.NET.HostModel.ResourceUpdater.ThrowExceptionForLastWin32Error()
   at Microsoft.NET.HostModel.ResourceUpdater.AddResourcesFromPEImage(String peFile)
   at Microsoft.NET.HostModel.AppHost.HostWriter.<>c__DisplayClass2_0.<CreateAppHost>g__UpdateResources|1()
   at Microsoft.NET.HostModel.RetryUtil.RetryOnWin32Error(Action func)
   at Microsoft.NET.HostModel.AppHost.HostWriter.CreateAppHost(String appHostSourceFilePath, String appHostDestinationFilePath, String appBinaryFilePath, Boolean windowsGraphicalUserInterface, String assemblyToCopyResorcesFrom)
   at Microsoft.DotNet.ShellShim.AppHostShellShimMaker.CreateApphostShellShim(FilePath entryPoint, FilePath shimPath)
   at Microsoft.DotNet.ShellShim.ShellShimRepository.<>c__DisplayClass6_0.<CreateShim>b__0()
   at Microsoft.DotNet.Cli.TransactionalAction.<>c__DisplayClass2_0.<Run>b__0()
   at Microsoft.DotNet.Cli.TransactionalAction.Run[T](Func`1 action, Action commit, Action rollback)
   at Microsoft.DotNet.Cli.TransactionalAction.Run(Action action, Action commit, Action rollback)
   at Microsoft.DotNet.ShellShim.ShellShimRepository.CreateShim(FilePath targetExecutablePath, ToolCommandName commandName, IReadOnlyList`1 packagedShims)
   at Microsoft.DotNet.Tools.Tool.Install.ToolInstallGlobalOrToolPathCommand.Execute()
   at Microsoft.DotNet.Tools.Tool.Install.ToolInstallCommand.Execute()
   at Microsoft.DotNet.Cli.DotNetTopLevelCommandBase.RunCommand(String[] args)
   at Microsoft.DotNet.Tools.Tool.ToolCommand.Run(String[] args)
   at Microsoft.DotNet.Cli.Program.ProcessArgs(String[] args, ITelemetry telemetryClient)
   at Microsoft.DotNet.Cli.Program.Main(String[] args)

C:\git\coverlet\test\coverlet.integration.tests\bin\Debug\netcoreapp3.1\d366c85b6c244c8b86cca264210c9e9c (fixnightly -> origin)
λ dotnet tool install coverlet.console --version 1.7.2-preview-0001-g96f4e91319 --tool-path C:\git\coverlet\test\coverlet.integration.tests\bin\Debug\d366c85b6c244c8b86cca264210c9e9c\coverletTool
You can invoke the tool using the following command: coverlet
Tool 'coverlet.console' (version '1.7.2-preview-0001-g96f4e91319') was successfully installed.

As you can see if I make path shorter it works. I'm ok with that, but error is a bit hidden and if I search around I found that code related to windows update, so it's not clear the workaround.

λ dotnet --info
.NET Core SDK (reflecting any global.json):
 Version:   3.1.201
 Commit:    b1768b4ae7

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.18363
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\3.1.201\

Host (useful for support):
  Version: 5.0.0-preview.2.20160.6
  Commit:  d12f79a4d1

.NET Core SDKs installed:
  2.2.207 [C:\Program Files\dotnet\sdk]
  3.0.103 [C:\Program Files\dotnet\sdk]
  3.1.200-preview-015002 [C:\Program Files\dotnet\sdk]
  3.1.201 [C:\Program Files\dotnet\sdk]
  3.1.300-preview-015048 [C:\Program Files\dotnet\sdk]
  5.0.100-preview.2.20176.6 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.16 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.17 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.2.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.16 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.17 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.2.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.0.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.0-preview.2.20167.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.16 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.17 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.2.8 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.0.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.0-preview.2.20160.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.0.3 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 3.1.2 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 3.1.3 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 5.0.0-preview.2.20160.6 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

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

The text was updated successfully, but these errors were encountered:

brcaswell · 2020-04-13T17:04:08Z

I believe 80070002 AND FFFF results in 0x00000002, a file not found HResultException. Therefore the changes associated to the retry logic (as referenced by the linked issue) wouldn't be a change in behavior for this scenario, an attempt to a retry wouldn't occur.

brcaswell · 2020-04-13T17:29:58Z

Can you be a bit more explicit with your workaround steps.

This issue doesn't seem related to long path... It is a possible duplicate of #2599 in that could be failing to find a resource that is a design time built file.

UPDATE: but that isn't entirely clear as of yet either.

MarcoRossignoli · 2020-04-13T17:54:18Z

Take a look at sample above I removed the tfm fragment from --tool-path resulting in a shorter tool path and it works.

brcaswell · 2020-04-13T20:53:42Z

to me, changing the path to exclude the tfm just raises more questions on what your tool was doing. Your project is orchestrating quite a bit here - and you have only provided part of your output from your tool (in preview) in regards to a development environment scenario that you haven't provided steps on how to reproduce.

As it stands, even the concept of a successful response here is in regards to your project integration testing; It isn't clear at all how this pertains to the sdk other then it throwing a file not found exception when provided a path to a tool-path that was seemingly not generated as you expected by your own tooling.

I pulled down the master branch of your project and the DotnetTool integration test passed in both the VS Test Adapter and running dotnet test.

was there something else to consider on the above?

MarcoRossignoli · 2020-04-13T21:36:36Z

I pulled down the master branch of your project and the DotnetTool integration test passed in both the VS Test Adapter and running dotnet test.

Try with this branch(old one without shorter path and shorter package name) coverlet-coverage/coverlet@master...MarcoRossignoli:failtest

Run pack

C:\git\coverlet (failtest -> origin)
λ dotnet pack
Microsoft (R) Build Engine version 16.5.0+d4cbfca49 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  Restore completed in 310,11 ms for C:\git\coverlet\test\coverlet.tests.projectsample.empty\coverlet.tests.projectsample.empty.csproj.
  Restore completed in 310,05 ms for C:\git\coverlet\test\coverlet.testsubject\coverlet.testsubject.csproj.
  Restore completed in 310,07 ms for C:\git\coverlet\test\coverlet.tests.xunit.extensions\coverlet.tests.xunit.extensions.csproj.
  Restore completed in 310,05 ms for C:\git\coverlet\test\coverlet.core.tests.samples.netstandard\coverlet.core.tests.samples.netstandard.csproj.
  Restore completed in 310,07 ms for C:\git\coverlet\test\coverlet.tests.projectsample.excludedbyattribute\coverlet.tests.projectsample.excludedbyattribute.csproj.
  Restore completed in 410,07 ms for C:\git\coverlet\src\coverlet.core\coverlet.core.csproj.
  Restore completed in 422,5 ms for C:\git\coverlet\src\coverlet.collector\coverlet.collector.csproj.
  Restore completed in 423,16 ms for C:\git\coverlet\src\coverlet.console\coverlet.console.csproj.
  Restore completed in 437,89 ms for C:\git\coverlet\src\coverlet.msbuild.tasks\coverlet.msbuild.tasks.csproj.
  Restore completed in 613,89 ms for C:\git\coverlet\test\coverlet.collector.tests\coverlet.collector.tests.csproj.
  Restore completed in 611,9 ms for C:\git\coverlet\test\coverlet.integration.tests\coverlet.integration.tests.csproj.
  Restore completed in 619,28 ms for C:\git\coverlet\test\coverlet.integration.template\coverlet.integration.template.csproj.
  Restore completed in 617,63 ms for C:\git\coverlet\test\coverlet.core.performancetest\coverlet.core.performancetest.csproj.
  Restore completed in 661,57 ms for C:\git\coverlet\test\coverlet.core.tests\coverlet.core.tests.csproj.
  coverlet.core -> C:\git\coverlet\src\coverlet.core\bin\Debug\netstandard2.0\coverlet.core.dll
  coverlet.collector -> C:\git\coverlet\src\coverlet.collector\bin\Debug\netcoreapp2.0\coverlet.collector.dll
  coverlet.msbuild.tasks -> C:\git\coverlet\src\coverlet.msbuild.tasks\bin\Debug\netstandard2.0\coverlet.msbuild.tasks.dll
  coverlet.console -> C:\git\coverlet\src\coverlet.console\bin\Debug\netcoreapp2.2\coverlet.console.dll
  coverlet.console -> C:\git\coverlet\src\coverlet.console\bin\Debug\netcoreapp2.2\coverlet.console.dll
  Successfully created package 'C:\git\coverlet\bin\Debug\Packages\coverlet.msbuild.2.9.0-preview.6.g810f0aae1f.nupkg'.
  Successfully created package 'C:\git\coverlet\bin\Debug\Packages\coverlet.msbuild.2.9.0-preview.6.g810f0aae1f.snupkg'.
  Successfully created package 'C:\git\coverlet\bin\Debug\Packages\coverlet.console.1.7.2-preview-0006-g810f0aae1f.nupkg'.
  Successfully created package 'C:\git\coverlet\bin\Debug\Packages\coverlet.console.1.7.2-preview-0006-g810f0aae1f.snupkg'.
  Successfully created package 'C:\git\coverlet\bin\Debug\Packages\coverlet.collector.1.3.0-preview.6.g810f0aae1f.nupkg'.
  Successfully created package 'C:\git\coverlet\bin\Debug\Packages\coverlet.collector.1.3.0-preview.6.g810f0aae1f.snupkg'.

Run DotnetTool, I get test error.

It isn't clear at all how this pertains to the sdk other then it throwing a file not found exception when provided a path to a tool-path that was seemingly not generated as you expected by your own tooling.

I opened to sdk because dotnet tool install source seems here https://github.com/dotnet/sdk/blob/master/src/Cli/dotnet/commands/dotnet-tool/install/ToolInstallCommand.cs.
Test simply copy a project to a folder and install a tool on local folder, it's not our own tooling we run dotnet tool command process starting from a specific(project root) working directory.

I started to get error when we changed the nightly package naming adding -preview.height.commitid longer than before.

brcaswell · 2020-04-14T15:45:33Z

yeah, I see... was able to replicate this using that branch\commit you provided.. there certainly seems to be an issue here... which, as you indicated, the introduction of the optional suffix in the codebase raised this issue.

though still it isn't entirely clear whether the underline issue relates to length of arguments.

I can see from this build Job log that you are only failing the debug packing for window testing here, not the release. It didn't seem like the DotnetTool test was being excluded there, am I wrong?

Though I thought it may be possible that deterministic behavior based of the semver handling of the suffix as it relates to nuget packaging using the dotnet tool was a consideration here, the windows release job's pack and test indicates that isn't an issue either..

that is, Looking over semver 2.0. this Nerdbank.GitVersioning, produces a nuspec for 1.7.2-preview-0001-g96f4e91319 which is semver 1... but the release job is doing the same semver 1 suffix.

Another workaround and consideration here, is adding the "nugetPackageVersion" : { "semVer" : 2 } back into src/coverlet.console/version.json, committing it and doing public release pack, dotnet pack -c Debug /p:PublicRelease=true - results in 1.7.2-preview.1 without git commit hash

1.7.2-preview.1.g96f4e91319 doesn't seem like it's supported by either semver 1.0 or 2.0 (need to clarify on that) and It's unclear whether 1.7.2-preview.1+g96f4e91319 is supported.. the documentation doesn't reference to having both the pre-release label dot notation mixed with the build-metadata notation, but it does distinguish on them. So, the notations might just be either or.

Furthermore, It doesn't appear as though Nerdbank.GitVersioning can generate 1.7.2-preview.1+g96f4e91319 nor 1.7.2+g96f4e91319.. might be worth raising an issue in their project on that and get clarity on it...

but yea, there is something to observe on here.

MarcoRossignoli · 2020-04-17T16:59:04Z

I can see from this build Job log that you are only failing the debug packing for window testing here, not the release. It didn't seem like the DotnetTool test was being excluded there, am I wrong?

Interesting should run also in release, need to check if release build generates different/shorter package name in that case.

danielmarbach · 2020-09-23T15:01:48Z

We ran into this as well and the culprit seems to be that the standard global tool installation uses very long paths to store the tools

C:\Users\{user}\.dotnet\tools\.store\{PackageId}\{version}\{PackageId}\{version}\tools\{tfm}\any

so should you use a longer package id in your package because the package ID is stored twice you are quite likely to run into long path issues which causes this problem. The only way to install a tool is by not using the global flag but set the tool path to a shorter root path

danielmarbach · 2020-09-24T07:25:42Z

So any explanation why the {PackageId}\{version} is double stored?

wli3 · 2020-09-27T04:32:12Z

The first layer of {PackageId}\{version} is for future single package with multiple tools

The layout for the tools folder where the tool will be installed is described below:

.dotnet/tools/.store/packageid/version/packageid/version/
                                /dependency1 package id/
                                /dependency2 package id/
                                /asset file

The CLI will obtain the tool through NuGet by generating a fake (temporary) project, with a reference to the tool package. One fake project will has one tool package reference. We will then do a restore on this project, passing the packages parameter to indicate where we want this package (and its dependencies) restored.

To prevent normal package taking dependency on the tool package reference, NuGet will block package reference to a tool package type DotnetTool. The property RestoreProjectStyle=DotnetToolReference in temporary project file will be used to indicate that the project is temporary.

jbaehr · 2021-07-30T15:47:11Z

I just run into this issue, too. First installing a tool failed on a Windows 10 machine with dotnet 5.0.202 and after I found this issue here I tried with shortening the tool path. Now the installation went though, but starting the tool failed with a message like

Cannot use file stream for [{my-given-tool-path}\.store\{package-id}\{package-version}\{package-id}\{package-version}\tools\net5.0\any\{package-id}.runtimeconfig.json]: No such file or directory

And indeed, the complete path was 262 chars long. Shortening the tool path (--tool-path argument for dotnet tool install) even further was finally successful.

Are there any plans to address this problem for the upcoming .NET-6 release? A while back, I was quite exited by the BCL Team's announcement regarding MAX_PATH, but apparently there is still a long way to go...

radical · 2021-11-09T17:59:38Z

We are consistently hitting this on runtime-staging CI runs for browser-wasm:

Microsoft.NET.HostModel.HResultException: 80070002
   at Microsoft.NET.HostModel.ResourceUpdater.ThrowExceptionForLastWin32Error()
   at Microsoft.NET.HostModel.ResourceUpdater.AddResourcesFromPEImage(String peFile)
   at Microsoft.NET.HostModel.AppHost.HostWriter.<>c__DisplayClass2_0.<CreateAppHost>g__UpdateResources|1()
   at Microsoft.NET.HostModel.RetryUtil.RetryOnWin32Error(Action func)
   at Microsoft.NET.HostModel.AppHost.HostWriter.CreateAppHost(String appHostSourceFilePath, String appHostDestinationFilePath, String appBinaryFilePath, Boolean windowsGraphicalUserInterface, String assemblyToCopyResorcesFrom, Boolean enableMacOSCodeSign)
   at Microsoft.DotNet.ShellShim.AppHostShellShimMaker.CreateApphostShellShim(FilePath entryPoint, FilePath shimPath)
   at Microsoft.DotNet.ShellShim.ShellShimRepository.<>c__DisplayClass5_0.<CreateShim>b__0()
   at Microsoft.DotNet.Cli.TransactionalAction.<>c__DisplayClass5_0.<Run>b__0()
   at Microsoft.DotNet.Cli.TransactionalAction.Run[T](Func`1 action, Action commit, Action rollback)
   at Microsoft.DotNet.Cli.TransactionalAction.Run(Action action, Action commit, Action rollback)
   at Microsoft.DotNet.ShellShim.ShellShimRepository.CreateShim(FilePath targetExecutablePath, ToolCommandName commandName, IReadOnlyList`1 packagedShims)
   at Microsoft.DotNet.Tools.Tool.Install.ToolInstallGlobalOrToolPathCommand.Execute()
   at Microsoft.DotNet.Tools.Tool.Install.ToolInstallCommand.Execute()
   at Microsoft.DotNet.Cli.DotNetTopLevelCommandBase.RunCommand(String[] args)
   at Microsoft.DotNet.Tools.Tool.ToolCommand.Run(String[] args)
   at Microsoft.DotNet.Cli.Program.ProcessArgs(String[] args, TimeSpan startupTime, ITelemetry telemetryClient)
   at Microsoft.DotNet.Cli.Program.Main(String[] args)
D:\a\_work\1\s\.packages\microsoft.dotnet.helix.sdk\7.0.0-beta.21555.2\tools\xharness-runner\XHarnessRunner.targets(38,5): error : Failed to install the dotnet tool. Installation exited with 1.  [D:\a\_work\1\s\src\libraries\sendtohelixhelp.proj]
D:\a\_work\1\s\.packages\microsoft.dotnet.helix.sdk\7.0.0-beta.21555.2\tools\xharness-runner\XHarnessRunner.targets(38,5): error :  [D:\a\_work\1\s\src\libraries\sendtohelixhelp.proj]
##[error].packages\microsoft.dotnet.helix.sdk\7.0.0-beta.21555.2\tools\xharness-runner\XHarnessRunner.targets(38,5): error : Failed to install the dotnet tool. Installation exited with 1.

Build

cc @lewing @steveisok

steveisok · 2021-11-09T18:24:44Z

@radical I believe dotnet/arcade#8160 should fix the problem.

MarcoRossignoli mentioned this issue Apr 11, 2020

Fix nightly build versioning coverlet-coverage/coverlet#806

Merged

marcpopMSFT assigned joeloff Apr 16, 2020

marcpopMSFT added the untriaged Request triage from a team member label Apr 16, 2020

radical mentioned this issue Nov 10, 2021

[wasm] Run AOT, and Wasm.Build.Tests on windows dotnet/runtime#59479

Merged

MarcoRossignoli closed this as completed Feb 1, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

dotnet tool install fails #11244

dotnet tool install fails #11244

MarcoRossignoli commented Apr 11, 2020 •

edited

Loading

brcaswell commented Apr 13, 2020

brcaswell commented Apr 13, 2020 •

edited

Loading

MarcoRossignoli commented Apr 13, 2020

brcaswell commented Apr 13, 2020 •

edited

Loading

MarcoRossignoli commented Apr 13, 2020 •

edited

Loading

brcaswell commented Apr 14, 2020 •

edited

Loading

MarcoRossignoli commented Apr 17, 2020

danielmarbach commented Sep 23, 2020 •

edited

Loading

danielmarbach commented Sep 24, 2020

wli3 commented Sep 27, 2020 •

edited

Loading

jbaehr commented Jul 30, 2021

radical commented Nov 9, 2021 •

edited

Loading

steveisok commented Nov 9, 2021

dotnet tool install fails #11244

dotnet tool install fails #11244

Comments

MarcoRossignoli commented Apr 11, 2020 • edited Loading

brcaswell commented Apr 13, 2020

brcaswell commented Apr 13, 2020 • edited Loading

MarcoRossignoli commented Apr 13, 2020

brcaswell commented Apr 13, 2020 • edited Loading

MarcoRossignoli commented Apr 13, 2020 • edited Loading

brcaswell commented Apr 14, 2020 • edited Loading

MarcoRossignoli commented Apr 17, 2020

danielmarbach commented Sep 23, 2020 • edited Loading

danielmarbach commented Sep 24, 2020

wli3 commented Sep 27, 2020 • edited Loading

jbaehr commented Jul 30, 2021

radical commented Nov 9, 2021 • edited Loading

steveisok commented Nov 9, 2021

MarcoRossignoli commented Apr 11, 2020 •

edited

Loading

brcaswell commented Apr 13, 2020 •

edited

Loading

brcaswell commented Apr 13, 2020 •

edited

Loading

MarcoRossignoli commented Apr 13, 2020 •

edited

Loading

brcaswell commented Apr 14, 2020 •

edited

Loading

danielmarbach commented Sep 23, 2020 •

edited

Loading

wli3 commented Sep 27, 2020 •

edited

Loading

radical commented Nov 9, 2021 •

edited

Loading