Sdk: Package restoration layout changed

[andschwa]

Steps to reproduce

On a case-sensitive file-system (say, defaults of Ubuntu 16.04):

dotnet restore

Expected behavior

Packages get restored using their correct name, not the lower-cased version:

~/.nuget/packages/Microsoft.CodeAnalysis.Common

Actual behavior

Package names are getting lower-cased:

~/.nuget/packages/microsoft.codeanalysis.common

Environment data

dotnet --info output:

.NET Command Line Tools (1.0.0-preview3-003546)

Product Information:
 Version:            1.0.0-preview3-003546
 Commit SHA-1 hash:  c0c07ed959

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  16.04
 OS Platform: Linux
 RID:         ubuntu.16.04-x64

The last known good version was 003246.

This caused a CI break for PowerShell, see https://github.com/PowerShell/PowerShell/pull/2162.

@brthor is this a NuGet.Client problem?

/cc @vors

[brthor]

/cc @joelverhagen @eerhardt

This was an intentional change

[andschwa]

Why are breaking changes being introduced in rel/1.0.0?

[joelverhagen]

Yes, this is an intentional change, driven by NuGet. Progress on this work is available here:
https://github.com/NuGet/Home/issues/2522

.NET CLI and DotNetHost (core-setup repository) will be updated to prefer reading paths mastered by NuGet libraries (rather than composing ~/.nuget/packages/{id}/{version} themselves).

Could you provide some details about your scenario?

[andschwa]

@joelverhagen For PowerShell, with the lack of GetAssemblies in .NET Core, and the need to be speedy at start-up, it is designed to create a type catalog of all its dependencies types, which is then compiled into PowerShell. .NET CLI team previously helped me do this for .NET CLI builds using Microsoft.DotNet.ProjectModel, which is then fed into PowerShell's type catalog generator, the output of which is compiled into our custom assembly load context, of which @daxian-dbw can explain further.

[eerhardt]

@andschwa - a few thoughts:

1. The ProjectModel library is going to be deleted with the transition from project.json/.xproj projects to to normal MSBuild .csprojs.
2. Would using the DependencyModel API instead work for you? It reads in the deps.json file, and gives you information about all the dependencies of a project. Here's the DependencyContextJsonReader class.
   
   
   
   • The deps.json file for an assembly is generated during the build.
   
   
3. If you want to resolve an assembly out of the NuGet cache, you should use the FallbackPackagePathResolver class. Here is some code you can copy that is using it.

[andschwa]

I don't think 2 will work without some funky logic, as this has to be generated before the build (its output is is consumed by another program, whose output is finally consumed by the build), so deps.json won't work.

Keep in mind this is only a workaround for the lack of GetAssemblies() (yes I know that's done at runtime and the current method is pre build, ask @daxian-dbw for details). If we can continue to use ProjectModel until then, a lot of unnecessary work can be avoided.

Also @daviwil you probably want a heads up on these pending API removals.

[eerhardt]

If we can continue to use ProjectModel until then, a lot of unnecessary work can be avoided.

You can continue to use ProjectModel as long as you are using project.json/.xproj style projects. But as soon as you move to using MSBuild .csproj, you will need to find another way to generate your file during the build.

/cc - @terrajobst and @ericstj - to see if they have a timeline on when GetAssemblies will be supported in .NET Core.

[ericstj]

timeline on when GetAssemblies will be supported in .NET Core

@gkhanna79 @jkotas would know better.

[andschwa]

Thanks @eerhardt, that's a bit more clear. So we can either figure out another workaround to move to msbuild based .NET CLI sooner, or wait on .NET Core, remove our workaround, and then move. I'll leave that up to @daxian-dbw and @vors.

@ericstj we've been operating on the timeline of "next big patch" in November.

[terrajobst]

@eerhardt

AppDomain.GetAssemblies() will become available in the next version of .NET Core. We don't have a public release date yet, but it's likely showing up on early builds soonish. /cc @weshaggard

[gkhanna79]

We intend to bring it up in Nov timeframe.

[TheRealPiotrP]

@andschwa is this bug still tracking any open work? Or can we call it closed?

[andschwa]

We can close this.