8000 aspnetcore GenerateFiles.csproj uses global package dir · Issue #4444 · dotnet/source-build · GitHub
[go: up one dir, main page]
Skip to content

aspnetcore GenerateFiles.csproj uses global package dir #4444

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.

Sign up for GitHub

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

Jump to bottom
Closed
corngood opened this issue Jun 3, 2024 · 5 comments · Fixed by dotnet/dotnet#176
Closed

aspnetcore GenerateFiles.csproj uses global package dir #4444

corngood opened this issue Jun 3, 2024 · 5 comments · Fixed by dotnet/dotnet#176
Labels
area-upstream-fix Needs a change in a contributing repo

Comments

@corngood
Copy link
corngood commented Jun 3, 2024

In 9.0.0-preview.4, I noticed that this explicit restore operation:

https://github.com/dotnet/dotnet/blob/7b92d4092abc8b04f79a9412a712257966724494/src/aspnetcore/eng/Tools.props#L7

uses $HOME/.packages. This seems like it's probably unintentional. Adding the following causes it to use the inner source build package cache, which is what I would expect it to do:

        Properties="NUGET_PACKAGES='$(CurrentRepoSourceBuildPackageCache)'"
@ghost
Copy link
ghost commented Jun 3, 2024

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

@ghost ghost added the untriaged label Jun 3, 2024
@MichaelSimons
Copy link
Member

[Triage] @corngood - can you help us understand what the impact of this is?

@corngood
Copy link
Author
corngood commented Jun 6, 2024

In nixpkgs we use the per-repo package cache dirs to enumerate dependencies.

We could also look at the default package dir in $HOME, but this just seemed like an oversight, because everything else seems to use CurrentRepoSourceBuildPackageCache.

Here's an example of a similar issue: #4293

In that case it was using .packages in the VMR root, rather than $HOME.

@MichaelSimons MichaelSimons moved this from Backlog to 9.0 in .NET Source Build Jun 27, 2024
@MichaelSimons
Copy link
Member

@wtgodbe - Is this something you can take a look at?

@MichaelSimons MichaelSimons added area-upstream-fix Needs a change in a contributing repo and removed untriaged labels Jun 27, 2024
@MichaelSimons MichaelSimons moved this from 9.0 to 10.0 in .NET Source Build Jul 1, 2024
@wtgodbe
Copy link
Member
wtgodbe commented Jul 2, 2024

Sure, is the ask to just set the package cache correctly when in source build? I don't fully understand why this restore operation is "special", how do repos normally set the packages root in the source build context?

@MichaelSimons MichaelSimons moved this from 10.0 to 10 Candidate in .NET Source Build Feb 6, 2025
@MichaelSimons MichaelSimons moved this from 10 Candidate to 10.0 in .NET Source Build Mar 24, 2025
@ViktorHofer ViktorHofer mentioned this issue Apr 15, 2025
Merged
11 tasks
@github-project-automation github-project-automation bot moved this from 10.0 to Done in .NET Source Build May 6, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area-upstream-fix Needs a change in a contributing repo
Projects
.NET Source Build
Archived in project
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Remove VMR inner-build concept dotnet/dotnet
3 participants
@corngood @MichaelSimons @wtgodbe
0