Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for dotnet SDK fallback folder #3242

Merged
merged 1 commit into from Jun 8, 2018

Conversation

Projects
None yet
2 participants
@csmager
Copy link
Contributor

csmager commented Jun 8, 2018

The dotnet SDK ships with various .NET Core and ASP.NET Core nuget packages in a NuGetFallbackFolder.

This changes to try to find packages in that folder before looking in other caches or downloading from source. In the event the package is found here, the contents are copied or linked directly from that folder instead of the user's cache.

Paket resolves a few packages with higher versions than the ones that ship, so this doesn't eliminate all downloads, but it makes a very significant dent. A before/after when starting with an empty cache for a project referencing Microsoft.AspNetCore.App:

Before

Performance:
 - Disk IO: 46 seconds
 - Average Download Time: 173 milliseconds
 - Number of downloads: 273
 - Average Request Time: 177 milliseconds
 - Number of Requests: 276
 - Runtime: 1 minute, 6 seconds

After

Performance:
 - Disk IO: 5 seconds
 - Average Download Time: 125 milliseconds
 - Number of downloads: 34
 - Average Request Time: 218 milliseconds
 - Number of Requests: 36
 - Runtime: 12 seconds

We could go further: I'd guess this won't work when e.g. FAKE does a local install of the dotnet SDK as that folder won't be on the path. It seems that there's an MSBuild property available during restore (as I mentioned in #2827 (comment)) that we could pass to paket.exe when called in Paket.Restore.targets.

Fixes #2827

Add support for dotnet SDK fallback folder
The dotnet SDK ships with various .NET Core and ASP.NET Core nuget
packages in a NuGetFallbackFolder.

This changes to try to find packages in that folder before looking in
other caches or downloading from source. In the event the package is
found here, the contents are copied or linked directly from that folder
instead of the user's cache.

@forki forki requested a review from matthid Jun 8, 2018

@@ -331,6 +331,21 @@ let GetTargetUserNupkg (packageName:PackageName) (version:SemVerInfo) =
let GetTargetUserToolsFolder (packageName:PackageName) (version:SemVerInfo) =
DirectoryInfo(Path.Combine(Constants.UserNuGetPackagesFolder,".tools",packageName.CompareString,version.Normalize())).FullName

let TryGetFallbackFolder () =
let dotnet = if isUnix then "dotnet" else "dotnet.exe"

This comment has been minimized.

@forki

forki Jun 8, 2018

Member

can we do it without calling dotnet?

This comment has been minimized.

@csmager

csmager Jun 8, 2018

Author Contributor

I'm just using it to find the folder, it's not executed. I guess the alternative is to try the default folder depending on platform.

This comment has been minimized.

@forki

forki Jun 8, 2018

Member

ah I see. that's neat

@forki forki merged commit a3a94d8 into fsprojects:master Jun 8, 2018

1 of 2 checks passed

continuous-integration/appveyor/pr Waiting for AppVeyor build to complete
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

@csmager csmager deleted the csmager:fallback-folder branch Jun 8, 2018

@forki forki referenced this pull request Jun 8, 2018

Closed

Writing to dotnet folder? #3243

@inosik inosik referenced this pull request Jul 11, 2018

Closed

Exception during restore #3290

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.