-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
dotnet store command: Long delay based on manifest location and unhelpful error message #8632
Comments
when you place a csproj In |
Placing the file in the Documents folder has the same result ... dotnet store --manifest c:\users\<USER>\documents\packages.csproj --runtime win10-x64 --framework netstandard2.0 --framework-version 2.0.0 Logged the output (
|
My documents folder is also large enough to slow it down.. it works great from a new empty folder. An alternative would be to add Next problem is you are passing |
ah! The instructions I started with for the topic were written by another author. It's also possible that a typo (cut-and-paste) error along the why threw me off. I'll see now. However if the difference here is passing the wrong framework, a hang is a lot worse UE than a proper error message. |
Agreed, the "error message" for a wrong / unsupported framework (or even runtime) is:
Which isn't very helpful if you just tried to use |
@dasMulli ty ... good news here as u predicted! 🎉 🎈 Yes, it did run from an empty folder in Documents. Yes, that error message isn't very helpful. I'm going to leave this open but go back over to the topic issue now and
|
This is because of the implicit globbing support in the new SDK. It will happen for any command when you use a new "SDK" csproj, not just /cc @rainersigwald @nguerrera @dsplaisted For the error message - agreed, we should fix it. In reality, the |
Since |
Yes, please, because this soooooo looks like a hang when it happens, and there's no reason to think that devs will grok it was merely the result of where they placed their manifest file. Simply placing it in the Documents folder (with many projects in there) leads to this problem.
Why have both the |
These two options map to the MSBuild properties |
Honestly - I'll be the first to tell you that we need some UX work on the |
It conflates them then a little bit. The word "framework" used in both places but not meaning the same thing ... "target" framework ... "runtime" framework. I wonder if the options should be |
What about a dedicated This would then allow for smarter defaults (=> no default items, current framework + runtime version etc.) |
Due to lack of recent activity, this issue has been labeled as 'stale'. It will be closed if no further activity occurs within 30 more days. Any new comment will remove the label. |
This issue will now be closed since it has been labeled 'stale' without activity for 30 days. |
Steps to reproduce
Create a package store manifest (for this example, I create it at the root of my drive for easy access), e.g., in a file named packages.csproj ...
Run the
dotnet store
command to provision the package store ...dotnet store --manifest c:\packages.csproj --runtime win10-x64 --framework netstandard2.0 --framework-version 2.0.0
Expected behavior
Provisions the package store and produces the target manifest in the .dotnet/store subdirectory of the user's profile ...
(Note: Bad spacing and lowercase package names were addressed in #1487).
Actual behavior
It hangs. Running with
-v detailed
, it runs for a while and stops at ...Environment data
... and also occurs with latest
2.0.1-servicing-006933
The text was updated successfully, but these errors were encountered: