0

For packages which aren't restored by NuGet (normally because the package is specific and unique to projects you work on), where do you put the package files?

NuGet convention is to have a folder named packages in the root of the solution.

There's a question which already references this issue: managing non-nuget dlls along with nuget packages

And I agree that having a separate folder of non-nuget packages which are source controlled is a good idea.

But what should the name of the folder be? Is there a convention here? A process recommended by Microsoft?

The only name I've seen is NonNugetAssemblies.

Community
  • 1
  • 1
harvzor
  • 2,832
  • 1
  • 22
  • 40
  • I doubt there's any specific recommendation, or any need for one. Normally I just have a "lib" folder in the root of my solution and stuff any DLLs or other 3rd party things in there. – David May 19 '17 at 11:30
  • Do you want to add dll files or nuget packages to source control? - Like a folder containing .nupkg files that aren't published to a nuget feed – Martin Ullrich May 19 '17 at 11:42
  • @MartinUllrich It could be DLLs, source files (such as application config/markup files) or full .nupkg files which are stored in this folder. The whole lot needs to be restored to each dependent project, and therefore needs to be source controlled. – harvzor May 19 '17 at 15:42
  • @harvey all of these options are possible options, which is why I believe the question is too broad / "primarily option based". There's up- and downsides to all approaches and depend primarily on the used project types and development workflow. I suggest you look into all approaches and ask questions if you hit issues with one of them. – Martin Ullrich May 19 '17 at 15:59
  • personally I prefer nupkgs in a folder since it also works well with .net core & .net standard projects and multi-targeting but this demonstrates how broad the topic is.. – Martin Ullrich May 19 '17 at 16:01

0 Answers0