dotnet-restore should accept --configuration

[livarcocc]

From @anoordende on June 15, 2017 23:45

Steps to reproduce

Build a project that selects packages based on configuration:

    <ItemGroup Condition="'$(Configuration)'=='Debug'">
        <PackageReference Include="Some.Fantastic.Package" Version="1.0.0-dev*" />
    </ItemGroup>

    <ItemGroup Condition="'$(Configuration)'=='Release'">
        <PackageReference Include="Some.Fantastic.Package" Version="1.0.0-master*" />
    </ItemGroup>

Expected behavior

When using dotnet restore with --configuration specified, it restores the correct package, especially now MSBuild does support this (and so does VS2017)

Actual behavior

It doesn't, because the --configuration flag cannot be specified.

Environment data

.NET Command Line Tools (1.0.4)

Product Information:
 Version:            1.0.4
 Commit SHA-1 hash:  af1e6684fd

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

Copied from original issue: dotnet/cli#6894

[livarcocc]

I disagree here. I think that your restore should not really be conditioned on any msbuild properties. I can see you needing to specify nuget config, like NuGet.Config or additional package sources. But everything else, should be restored by default in your project. If you depend on properties to be passed, this won't work in VS, for instance, where you can not pass any of these values to restore there.

cc @nguerrera @emgarten @rrelyea since we were talking about this this week.

[anoordende]

Actually it works rather well in VS2017, if you don't mind restarting the solution. But that's besides the point, this is an extremely powerful feature in CI/CD workflows. Properties are an intrinsic part of MSBuild and therefore /t:restore happily abides.

All I'm asking for is for this to be exposed in dotnet-restore, but maybe I'm missing the point and it is going to be a complicated issue :)

I think that your restore should not really be conditioned on any msbuild properties

Sorry but I disagree, we can't dictate what one can do with MSBuild in csproj.

This is an interesting article that reads:

With the existing features of MSBuild, you can conditionally reference a NuGet package. This allows you to choose package references per target framework, configuration, platform, or other pivots.

[nguerrera]

Consider that the assets file, unlike most other artifacts, has the same location between configurations. This means a high risk of crossing the wires between debug and release if the assets file changes between them. That article should be updated to not encourage switching assets based on configuration IMHO.

we can't dictate what one can do with MSBuild in csproj.

You can pass /p:Configuration if you want and understand the risks. The only question is whether we encourage it or not via shorthand syntax and I don't think that we should. It would give the impression that you must re-restore when switching configurations, which is not the common case.

[anoordende]

What do you mean by assets file?

[emgarten]

What do you mean by assets file?

obj\project.assets.json is where restore writes output. Currently this file supports multiple target frameworks, but not multiple configurations or combinations of other msbuild input properties.

[nkolev92]

Duplicate of #5895.

As indicated in that issue.

TargetFramework is the only support condition allowed for PackageReference items.

To work with other conditions you will need to handle them yourself by passing the extra property values to restore, and ensuring that restore is done appropriately before each build.