Mixing projects with packages.config and PackageReference

[ThomasZitzler]

Hi,

we started transition to .Net Core and therefore we have some projects switched to multi-targeting and we are using PackageReference there.

We still have several projects that cannot be easily converted (e.g. ASP.NET projects), so for now we also have projects with packages.config.

The projects all build to the same output directory (DI is collecting those on startup of the application).

This causes double-writes on builds as we have the same package referenced, but they are copied from "globalPackagesFolder" and the "repositoryPath" (same files, but maybe different timestamp). That also causes rebuilds of some projects every time we run the application from Visual Studio.

I tried to setup nuget.config to copy the files to the same directory:

<config>
  <add key="repositorypath" value="..\packages" />
  <add key="globalPackagesFolder" value="..\packages" />
</config>

That nearly works, but the PackageReference creates subfolders and the packages.config references are "flattening" the directory structure:

Is there any chance to have the same behaviour there?
Or are we doing something wrong there in general?

[zivkan]

You should not redirect the global packages folder, except at the "user" level (~/.nuget/nuget.config on Linux/Mac, or $APPDATA/NuGet/NuGet.config on Windows). This reduces duplication when different solutions on the same account use the same package. Redirecting it per repo means that different repos using the same package, it will be downloaded and extracted multiple places on disk, which is one of the design goals PackageReference wanted to fix. It also means that packages.config projects that have not yet been restored can copy from the global packages folder, instead of downloading from the internet again.

The folder layout (id\version vs id.version) is another thing where the Nuget team learned from packages.config older design, and changed for PackageReference to fix certain issues.

packages.config has different design decisions, but for backwards compatibility, was never changed.

So, if you stop redirecting the global packages folder, when the package already exists because a different solution already restored it, it will avoid double writes. On a stateless CI agent (gets wiped between builds), there will be double writes when it's restored by both packages.config and PackageReference.

You can consider migrating your packages.config projects to PackageReference, before migrating the project to .NET Core (or SDK style projects), to more quickly get the PackageReference benefits. But note that not all projects/packages are compatible, with ASP.NET being the most common project type that is not.

[zivkan]

Also, check if anything in your build is modifying (the timestamp) of the files in the packages folder. When NuGet extracts to the global packages folder, it set the file timestamp to the timestamp from the zip file, so the timestamps should be deterministic. I would expect that the packages.config's solution packages folder (repository path) should use the same logic, but I'm not 100% sure about that.