配置Nuget.Config在VS2013和VS2017中都可以工作

Question

Below is my current nuget.config that is working in VS2013.

Im looking to move over to VS2017 but i need to make changes to the nuget.config file in order to do so.

Is there anyway i can write my nuget.config so that it can work in either VS2013 or VS2017?

The reason i ask is because not all developers are working on the same version of visual studio, and when i checkin the changes required to work with nuget it will break for those loading the solution in VS2013.

<!-- VS2013 -->

<?xml version="1.0" encoding="utf-8"?>
<settings>
  <repositoryPath>..\lib</repositoryPath>
</settings>


<!-- VS2017 -->

<configuration>
 <config>
     <add key="repositoryPath" value="..\lib" />
     </config>
     <packageRestore>
     <add key="enabled" value="True" />
     </packageRestore>
 </configuration>

Answer 1

My suggestion is update the nuget version that you have to the latest one, then add a nuget repository in all visual studios in your teams to point to the same folder location.

The only thing that you need to understand at least is if one of your developers(Team A) using 2013 version removes a package there should not be any problem for the developer(Team B) using 2017 because when Nuget recognizes after you get the latest version of the repository folder, that a folder is not present on the package folder because it recognizes based on the package.config which are installed and which not, then you should get the dependency again an submit it as new change to your source control tool, after that the second project will point to the correct references, and your Team A will not have it included as part of their dependencies.

Second approach: you can go to your vs2013 projects and update all references to the new repository using the latest configuration(NuGet.Config file) , that should work

Here are the steps I follow when I need to configure NuGet from scratch

NUGET CONFIGURATION: The approach is to unify and reduce duplicated dependencies of all projects and place them in a common place where every project can make use of it. The advantage is not just unifying the dependencies; it also brings a reduction of space on the TFS and preserves a hierarchical structure for automatic builds as well.

STEP 1: Common folder for Nuget Packages

First you need to create the Common folder at the root level of all your projects with a Packages folder inside. Feel free to copy manually if you want all .NuGet packages that you have in other projects to the latter folder or leave it to the Visual Studio when you include a new dependency. Common will work as a Nuget repository, but on this case as a local Nuget. repository. Your Visual Studio configuration should know that. Follow the next step

Then you need to create with the plus button a new Seed Repository (your local). Below I named: Packages. After that browse the folder for your new packages. Then click ok

Now you can go to your Project and make a right click to include a new dependency

Then go to package source and select Packages and you will see all the packages available on the Packages folder that should be empty the first time

The idea here is to download the packages we need from the Packages folder instead from the Nuget repository, if the package don't exist then change to the search to nuget.org option and download the package from there. The effect should be the same

STEP 2: Prepare the configuration files

Here we want to avoid that Nuget to save packages inside “packages” folder at the root of our project, which is the default behavior of nuget when you download a package.

Rather we want to download the package to Common/Package folder. In order to do that, we need to add a Nuget.config file in our structure. Create a NuGet.Config file inside the root of your project. TFS View

Inside NuGet.Config type

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <config>
    <add key="repositoryPath" value="$\..\Common\Packages" />
  </config>
</configuration>

For the repositoryPath setting, you can specify an absolute path or relative path (recommended) using the $ token. The $ token based on where the NuGet.Config is located (The $ token is actually relative to one level below the location of the NuGet.Config). So, if I have \\ Team Project\\NuGet.Config and I want \\Team Project\\Common\\Packages I would need to specify $..\\Common\\Packages as the value.

STEP 3: Final step.

Start downloading the packages and make sure you check in all changes. If you have a package folder at the root of your project you can get rid of it in case you want to set the correct references to the new folder. Feel free to delete it if that is what you want. But if you want to keep the legacy code pointing to the package and start using the new Common folder for future packages, then you need to keep both. Below I fixed all references, there is no “package” folder and still can include new packages.

Enjoy!!!

Answer 2

I'm sorry to tell you that this is not possible. This was a breaking change to accommodate .Net Core and other versions of VS (ie, VS for Mac). I stumbled upon this info when looking into vs 2017 RC and .net core tools preview.