Sdk: dotnet store command: Long delay based on manifest location and unhelpful error message

[guardrex]

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 ...

<Project Sdk="Microsoft.NET.Sdk">
  <ItemGroup>
    <PackageReference Include="Newtonsoft.Json" Version="10.0.3" />
    <PackageReference Include="Moq" Version="4.7.63" />
  </ItemGroup>
</Project>

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 ...

<StoreArtifacts>
   <Package Id="castle.core"  Version ="4.1.0"/>
   <Package Id="moq"  Version ="4.7.63"/>
   <Package Id="newtonsoft.json"  Version ="10.0.3"/>
</StoreArtifacts>

(Note: Bad spacing and lowercase package names were addressed in https://github.com/dotnet/sdk/pull/1487).

Actual behavior

It hangs. Running with -v detailed, it runs for a while and stops at ...

Property reassignment: $(GenerateNuspecDependsOn)="Build;_LoadPackInputItems; _WalkEachTargetPerFramework; _GetPackageFiles; " (previous value: "_LoadPackInputItems; _WalkEachTargetPerFramework; _GetPackageFiles; ") at C:\Program Files\dotnet\sdk\2.0.0\Sdks\NuGet.Build.Tasks.Pack\build\NuGet.Build.Tasks.Pack.targets (43,5)

Environment data

.NET Command Line Tools (2.0.0)

Product Information:
 Version:            2.0.0
 Commit SHA-1 hash:  cdcd1928c9

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

Microsoft .NET Core Shared Framework Host

  Version  : 2.0.0
  Build    : e8b8861ac7faf042c87a5c2f9f2d04c98b69f28d

... and also occurs with latest 2.0.1-servicing-006933

[dasMulli]

when you place a csproj In C:\, msbuild will scan the entire volume, which could take quite a few minutes..

[guardrex]

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 (-v detailed) to a file as well. It stops at the same spot ...

Property reassignment: $(GenerateNuspecDependsOn)="Build;_LoadPackInputItems; _WalkEachTargetPerFramework; _GetPackageFiles; " (previous value: "_LoadPackInputItems; _WalkEachTargetPerFramework; _GetPackageFiles; ") at C:\Program Files\dotnet\sdk\2.0.0\Sdks\NuGet.Build.Tasks.Pack\build\NuGet.Build.Tasks.Pack.targets (43,5)

[dasMulli]

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 /p:EnableDefaultItems=false to the parameters.

Next problem is you are passing netstandard2.0 as a framework to store from, which is invalid - it should be netcoreapp2.0.

[guardrex]

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.

[dasMulli]

Agreed, the "error message" for a wrong / unsupported framework (or even runtime) is:

C:\Program Files\dotnet\sdk\2.0.0\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.CrossGen.targets(48,5): error : Unable to find resolved path for 'coreclr'. 

Which isn't very helpful if you just tried to use netstandard* or net* with dotnet store.

[guardrex]

@dasMulli ty ... good news here as u predicted! :tada: 🎈

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 ~make some changes over there to fix/surface these issues in the documentation.~ (We're waiting to see how [@]mairaw wants to play it.) I guess they'll consider here ...

• We can say in the topic 'use an empty folder somewhere to hold your package manifests,' but a ~hang~ insanely long delay just because the file is at the root of the drive or in the Documents folder seems like a bad UE to me. You just know devs are going to get into this situation no matter what the topic states.
• Of course ... the message ... it would be great if it said the framework (or runtime) provided isn't acceptable.

[eerhardt]

when you place a csproj In C:\, msbuild will scan the entire volume, which could take quite a few minutes..

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 dotnet store. Put a "HelloWorld.csproj" in C:\ and dotnet build or even msbuild it and you will see the same behavior.

/cc @rainersigwald @nguerrera @dsplaisted

For the error message - agreed, we should fix it. In reality, the dotnet store command only supports .NET Core App TFMs. It doesn't support desktop, netstandard, or any other TFM.

[rainersigwald]

Since store uses nonstandard projects, should it pass EnableDefaultItems=false to msbuild? Otherwise, there's no way for MSBuild to know that you _don't_ want to compile every *.cs file on your entire disk and it has to search for them.

[guardrex]

EnableDefaultItems=false

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.

the dotnet store command only supports .NET Core App TFMs. It doesn't support desktop, netstandard, or any other TFM.

Why have both the --framework and --framework-version options? ... Why not only have the --framework-version option if no other TFM is supported. Is the --framework option for the future?

[eerhardt]

Why have both the --framework and --framework-version options?

--framework specifies the TFM - netcoreapp2.0, netcoreapp2.1, etc.
--framework-version specifies the version of Microsoft.NETCore.App package - 2.0.0, 2.0.1, 2.1.0-preview2-12345.

These two options map to the MSBuild properties TargetFramework and RuntimeFrameworkVersion respectively.

[eerhardt]

Honestly - I'll be the first to tell you that we need some UX work on the dotnet store command. I had logged a few bugs in the 2.0 time frame that didn't meet the priority bar. The reasoning is that dotnet store is a fringe command that not many developers should/will use.

[guardrex]

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 --target-framework-version with only a value 2.0, 2.1, etc. and then --runtime-framework-version with values 2.0.0, 2.0.1, etc.

[dasMulli]

What about a dedicated .storeproj extension? .csproj isn't really appropriate since you don't intend to build a c# based output and only need "a thing" to get dependency resolution and msbuild support.

This would then allow for smarter defaults (=> no default items, current framework + runtime version etc.)