dotnet restore does not capture transitive framework assemblies from project references

[srivatsn]

From @NTaylorMullen on January 19, 2017 20:24

Trying to utilize a transitive project references framework assembly results in build errors. This looks to be the result of dotnet restore not capturing project references framework assemblies (doesn't exist in assets.json).

Note: This used to work in project.json land (built the repro in project.json then migrated).

See the simple repro here:
TransitiveProjectFrameworkRefs.zip

Go into ConsoleApp12 and dotnet restore; dotnet build

Copied from original issue: dotnet/sdk#691

[emgarten]

@NTaylorMullen The current design is that reference items do not flow transitively. You will need to reference this in your projects instead.

With project.json framework assemblies were explicitly defined for NuGet in a special section of the file. With csproj both references to external dlls on disk and framework references are reference elements and there is no clear way to find the subset of items that are actual framework assemblies.

If this were changed and a subset of reference items flowed transitively I think it would be confusing as to why some automatically showed up in parent projects and some did not.

@srivatsn what would you expect here?

[NTaylorMullen]

That's unfortunate then. This used to work in project.json land. If we're to not support this scenario we should at the very least raise transitive framework assemblies during dotnet migrate.

[emgarten]

@NTaylorMullen fixing this as part of migrate sounds like a better way to handle this. Afterwards the information project.json had as to what was a framework assembly reference that should flow vs a normal reference is gone.

[NTaylorMullen]

/cc @livarcocc

[livarcocc]

Migration used to do this, but once transitivity was to the SDK we removed this. So, I guess we need to add it back?

Is this related to dotnet/sdk#714?

[livarcocc]

@NTaylorMullen please, file an issue in the CLI for this.

[NTaylorMullen]

Done: https://github.com/dotnet/cli/issues/5494

[livarcocc]

As Sri pointed out in the CLI issue. This would bring back problems where we would need to keep the project.json around until migration is fully done. This would be a problem for VS, as they migrate each project separately (including moving artifacts to backup).

This is copied over from the CLI issue:

1. Make this work if the --skip-project-references is not passed. But that means that whenever the flag is passed (100% the case for VS), projects may be migrated missing this information.
2. Make migration find project.json for dependencies in the backup folder. But in this case, I think we should also allow for the backup folder to be passed to migration, so that migration is not aware of how VS calculates the path to this folder. This would be potentially a significant change for migration so late in the game and I am a bit nervous about taking it.
3. Fix this in NuGet and the SDK?
4. Do nothing. Migrate these projects wrong and have people add the references themselves.

I am not sure why NuGet decided not to honor this in the MSBuild world. But I feel like none of the options above are ideal for the stage we are in the cycle.