1
Visual Studio 2019

I have a .NET Core solution that needs to reference a single .NET Framework package just for the purposes of expanding the package contents into the packages folder so that some tools are available.

In my .csproj I have this line : 

<PackageReference Include="roundhouse" Version="1.1.0" TargetFramework="net472" />

I'm finding that when I build my solution ( either in local dev Visual Studio, or TeamCity ) that sometimes NuGet restores my package to this folder structure : 

\packages\roundhouse.1.1.0\roundhouse.1.1.0.nupkg

This is what it's doing currently.

But on another dev machine ( and on TeamCity Build Agent ) the build creates this folder structure :

\packages\roundhouse\1.1.0\roundhouse.1.1.0.nupkg

Notice the slight difference.

I haven't been able to figure out could be causing these different behaviors. I can't find any config setting related to NuGet package folder-structure.

Does anyone know ?

BaltoStar
  • 8,165
  • 17
  • 59
  • 91
  • Hi BaltoStar, is there any update for this issue? I checked your line above and found this is not a normal PackageReference format. It looks like a combination of package.config and packageReference... And I assume it could be the cause of the strange behavior you met, what's the result if you remove the ` TargetFramework="net472"` and run a rebuild, can it make the strange behavior go away? Please feel free to let us know if it's still blocking you, we'll try our best to help and hope it can help other members with similar issues. Thx :) – LoLance Dec 17 '19 at 09:34
  • Hi, BaltoStar, did you try Lance's suggestion to troubleshot your issue? By the way,`TargetFramework="net472"` means installing packages into projects that are part of framework 4.7.2, so it's not suitable for .net core projects at all. If you have any concern, please feel free to let us know. – Mr Qian Jan 02 '20 at 06:01
  • I know it's not normal to include a `net472` package in a `netcore` project but I need to do it to force the this package's files to be unpackaged and located in the `package` folder because I need to make use of them for a tool. As far as I can tell it causes no issues. I never figured-out why sometimes it's unpackaged to a slightly different folder-structure. – BaltoStar Jan 07 '20 at 02:45

1 Answers1

1

I can't find any config setting that controls which folder-structure is used.

I think this behavior is related to nuget package format packages.config and PackagesReference.

The global-packages folder(%userprofile%\.nuget\packages ) is where NuGet installs any downloaded package. Each package is fully expanded into a subfolder that matches the package identifier and version number. Projects using the PackageReference format always use packages directly from this folder. When using the packages.config, packages are installed to the global-packages folder, then copied into the project's packages folder. Hint from here.

Conclusion

When you use PackageReference, the path of the nuget which in the global-packages folder is like the structure 2.

\packages\roundhouse\1.1.0\roundhouse.1.1.0.nupkg

Besides, the packages in the solution which is copied from the global-packages folder has changed the path to structure 1.

\packages\roundhouse.1.1.0\roundhouse.1.1.0.nupkg

When you use package.config format, Nuget modifies the path of the nuget which is copied from the global-packages folder to the solution for some specific reasons.

It is just the normal behavior of the package.config and PackagesReference and it is designed by that.

Update1:

I found that you add <PackageReference Include="roundhouse" Version="1.1.0" TargetFramework="net472" /> into xxx.csproj of a core project. And that format is like the content in the packages.config of a framework project. I guess you just copy the content from packages.config into xxx.csproj of a core project though you use packageReference. Also, TargetFramework="net472"means that it will install the package on framework4.7.2, so it will not appear in the core project.

l have do these test；

1) Framework project with packages.config

packages.config

enter image description here

xxx.csproj

enter image description here

It loads the packages.config to loads the nuget package

2) Framework project with PackageReference

xxx.csproj

enter image description here

3) Core project

enter image description here

So I think it is the way you imported the nuget package that's causing this strange behavior. And please do not use packages.config format like TargetFramework="net472" in a core project(PackageReference).If you make sure that you use PackageReference in all the projects in your solution and you can try the following steps:

Solution:

1) clean the nuget cache

2) change your initial reference format in xxx.csproj like

<ItemGroup>
    <PackageReference Include="roundhouse" Version="1.1.0" />
</ItemGroup>

And then you can whether the restore path is different.

Hope it could help you.

LoLance
  • 25,666
  • 1
  • 39
  • 73
Mr Qian
  • 21,064
  • 1
  • 31
  • 41
  • Thanks for the info. I've expanded my post to include more detail - specifically that I'm using `PackageReference` for a `.NET Framework` package within a `.NET Core` solution but still seeing the `roundhouse.1.1.0` folder. – BaltoStar Dec 06 '19 at 17:42
  • I think the difference in the way you restore nuget on two machines leads to this problem.Please check in your machine and change `Packages.config` to `PackageReference` management format. – Mr Qian Dec 09 '19 at 05:32
  • As I already mentioned and edited my original post to include : I am exclusively using `PackageReference` in my `.csproj` for my `.NET Core` project. I do not have any `packages.config`. – BaltoStar Dec 09 '19 at 11:03
  • Usually,we should not use net core project to reference a framework nuget package which will leads a warning of incompatible items. And l am not sure whether it is the reason for this strange behavior. If you want to make it compatible with the net core project, I suggest you could change the nuget to [net standard](https://learn.microsoft.com/en-us/dotnet/standard/net-standard) which is suitable for framework and core project. – Mr Qian Dec 10 '19 at 03:17