Automatic project/NuGet reference resolution with new proj files?

[kierenj]

TL;DR:

I used to be able to reference a package and, depending on build environment (global.json with all of the project's references present and referred to therein / just the project standalone), have it resolve as the local project or a NuGet package. Was this a casualty of the move back to msbuild?

Steps to reproduce

1. Have a project.json referencing a package by name
2. Demonstrate that if project is built with project in the context of a larger global.json containing both projects, the local project version is used
3. Demonstrate that if the project is built in isolation, the reference will be resolved via NuGet
4. dotnet migrate
5. Build in situations from 2 and 3 again

Expected behavior

• When referenced project present, resolved locally
• When referenced project not present, resolved from NuGet

Actual behavior

• Explicit ProjectReference OR PackageReference nodes generated in proj file

Environment data

dotnet --info output:

.NET Command Line Tools (1.0.2)

Product Information:
 Version:            1.0.2
 Commit SHA-1 hash:  54743c8b7b

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

[livarcocc]

If I understand your ask correct, you wanted your reference to be resolved automatically as a project reference or as a package reference.

If that's correct, this is something that we do not support in csproj. In csproj, you have to be explicit about whether your reference is a Project or a Package by using either ProjectReference or PackageReference.

[kierenj]

Yes that's what I'm asking - it used to be the case with the old build system, so it's lost functionality with MSBuild. Is there no way to achieve this? Perhaps some conditional msbuild magic?

[livarcocc]

@eerhardt @dsplaisted do you guys have any idea if this is possible in MSBuild.

I am not aware of any way to do that in MSBuild. And like I said above, this is something that we explicitly do not support in MSBuild world. I will close the issue to indicate that. But maybe the people above know of a way to achieve something like this in the new project system.

[eerhardt]

Seems like a duplicate of https://github.com/dotnet/cli/issues/4997.

@davidfowl @emgarten @rrelyea @srivatsn - from my understanding (and @davidfowl's comment NuGet/Home#4119 (comment)), there is a plan to support this. But I'm not sure when it is coming. Someone tagged here should be able to link the correct issue that is tracking this work.

[emgarten]

There is no plan/issue on the nuget side for this that I know of. It would be a nice feature but I think this needs some design work around how this would look in the project file.

For example, if there is no ProjectReference how would Restore know where to go look for a project with the package id now that we are in the linked world of MSBuild and not the folder structure based world of DNX?

Also, how would Build handle Restore add/removing ProjectReferences, these would not be actual items in the project file.

[jjanuszkiewicz]

@emgarten Microsoft has already announced that "Package project duality" is available, but I can't find any relevant examples or other information. Can you help me figure out what's supported?

[kierenj]

Huh - it does look like they're suggesting a solution to this issue.

I'm not sure I understand the complexities of the problem @livarcocc : wouldn't it effectively work to provide a relative project path, which, if it exists is used, or otherwise a NuGet package reference is used? I feel like this would be possible with MSBuild. Alternatively, some conditional flag which switches between the two types would also work for me.

Providing some kind of advice for migrating the only work I've ever done with .NET Core would be very welcome :)

[davidfowl]

@kierenj the most relevant issue is here #1151