5

I hired a contractor to do some coding for me. He setup nuget.config in the solution folder with the following repository path:

<configuration>
  <solution>
    <add key="disableSourceControlIntegration"
      value="true" />
  </solution>
  <config>
    <add key="repositoryPath"
      value="../lib" />
  </config>
</configuration>

And I'm not too happy about his decision: this will place the nuget package folder outside the solution folder. I can easily change the repository path, simply by setting:

value="../<mySolutionFolder>/lib" />

However when I do this a curious thing happens: every single reference that I use in my solution is now broken. And nothing that I change in the .csproj files or other *.config files will allow my projects to find their references.

The only workaround is to re-create each project in my solution by starting from scratch, and add->existing items, etc. and reference->manage nuget packages, and install every reference again.

I have many projects in my solution and performing this for every one is understandably time consuming.

I would like to know if there is an easy way?

It seems like there should be a way for Nuget and VS to play nicely so that I can easily move the repository folder to a different path location.

sapbucket
  • 6,795
  • 15
  • 57
  • 94

5 Answers5

6

One way to fix the reference paths is to use the Package Manager Console.

From the Package Manager Console you can run the following command to reinstall the NuGet packages which will fix the hint paths for the references.

Update-Package -reinstall

This will reinstall all NuGet packages in the solution. I am assuming you have the code under source control so you can see what changes are made to the projects if you need to revert them after this reinstall.

There is more documentation on reinstalling NuGet packages on the NuGet documentation site.

Another way to fix this is to do a find and replace in the .csproj files to fix the hint path.

Matt Ward
  • 47,057
  • 5
  • 93
  • 94
2

I encountered this problem when I moved the actual folders around in my solution. I usually do a find/replace with VS Code looking for >..\packages\ and replace it with >..\..\packages\. This time I did the following:

  1. Perform Update-Package -Reinstall
    • this worked for everything with hint paths
    • does not work when your project uses NuGet packages to build your project because there are custom MSBuild statements that need to be manually fixed, see next step.
  2. Edit the .csproj files manually that do not build, in my example:
<Import Project="..\..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.8\build\net45\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props" Condition="Exists('..\..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.8\build\net45\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props')" />
<Import Project="..\..\packages\Microsoft.Net.Compilers.2.4.0\build\Microsoft.Net.Compilers.props" Condition="Exists('..\..\packages\Microsoft.Net.Compilers.2.4.0\build\Microsoft.Net.Compilers.props')" />

Notice that there are 2 condition statements in the <Import> that use relative pathing to ..\..\packages.

Hopefully these steps will help someone else.

Reece Bradley
  • 74
  • 3
0

Package.config is used for put file somewhere else from the folder, it help best to not upload package unusually when you add something in your project through Nuget.

Try to copy the package to that folder (new path you set) or simply close the project, open it again and click on Restore after going to Manage project reference.

Anirudha Gupta
  • 9,073
  • 9
  • 54
  • 79
0

After trying all solutions posted here I could not escape one primary issue: references to non nuget items, such as System and System.Core remained invalid (yellow triangle listed next to them). Removing them and adding them did not make them valid again. Further (as we all know) Visual Studio is terrible and giving reasons for why a reference is considered invalid.

So while Matt's solution does indeed relocate the nuget package folder, the solution in not left in a working state. Further, updating hint paths did not help because those are specific to the nuget packages. I cannot explain why basic references suchas System also become invalid. Perhaps someone reading this a year from now can leave a message with an explanation.

What I ended up doing is rebuilding my entire project without a nuget.config file (I deleted it). This causes nuget to use all defaults. Downloaded packages get stored in \\<solution_folder>\packages\. After the solution was working again, I added back the nuget.config file but with the following removed:

  <config>
    <add key="repositoryPath"
      value="../lib" />
  </config>

...and removing that section causes nuget to rely on default behavior which turns out to be exactly what I wanted (installing packages to \packages, etc).

If anyone else is about to undertake this laborious effort, I found this SO solution helpful for moving folders and files from the old solution to the new one.

Community
  • 1
  • 1
sapbucket
  • 6,795
  • 15
  • 57
  • 94
0

I managed to do this to my own solution without realising how (and ended up with a packages folder at the *.sln level and another one at The level below that) - but I'm pretty sure now that this all has to do with migrating from using a packages config file, to the new method of using package references. This can occur if you use a newer version of visual studio (which is possibly what your contractor did) or via a button/commend in NuGet, or via a right-click context menu.

One of the things that happens is the creation of a 'global' packages folder (the one at .sln level) which is meant to save your space since it means you can have multiple solutions using the same package without having huge duplicate package folders repeated in every solution.

I found this out when I was merging The text is two csproj files and needed to Google: import project difference to package reference

See https://learn.microsoft.com/en-us/nuget/reference/migrate-packages-config-to-package-reference

Esco
  • 194
  • 2
  • 5