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

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]

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

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