Package restore + Custom package folder location issues

Topics: General
Dec 20, 2012 at 3:11 PM

Hi,

I use Nuget 2.2.31210.9045 on VS2012+TFS2010 with enabled "Package Restore" and configured "custom package folder location" and met several issues.

Steps to reproduce:

1) I created a solution with project A.

2) Enabled Package restore on solution.

3) Created nuget.config in the solution folder with the following contents

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <config>
    <add key="repositoryPath" value="Shared" />
  </config>
</configuration>

4) Opened “Manage Nuget Packages” form and installed NLog package to ProjectA.

Expected behavior:

Folder with name “Shared” should be created on disk and not added to TFS.

Actual behavior:

Folder with name Shared was created but marked as added to TFS (Issue #1).

I guess it is not correct as Package Restore option is enabled, so it should have been just created but not added.

5) I closed solution, removed folder Shared from the disk in Explorer.

6) Opened solution again, initiated build.

Expected behavior:

Nuget should create Shared folder, restore packages into it and solution should be built successfully.

Actual behavior:

a)      Packages folder was created in the solution folder (Issue #2) Why?

b)      Shared folder wasn’t created and so the solution wasn’t build (Issue #3) Why?

7) I opened “Manage Nuget packages” window and saw an yellow message “Some Nuget packages are missing from this solution. Click to restore.”

After I clicked Restore, Shared folder was created with the required packages, so the next build was successful.

But this folder marked as added to TFS again :-//  (Issue #4)

Why all these issues #1-4 happen?

 

 

 

Dec 21, 2012 at 5:38 PM

I created a bug for this yesterday.  Check out this and upvote it.  It answers #2 and #3 I think.  I dont address the adding to TFS but I also saw that problem but it was not consistant for some reason.

http://nuget.codeplex.com/workitem/2921

Dec 26, 2012 at 6:20 PM

Regarding issue #1:

When you enable package restore, NuGet creates a nuget.config under the <solution root>\.nuget folder. That file has a flag 'disableSourceControlIntegration' set to 'true'. Do you keep that file in your solution? 

Dec 26, 2012 at 6:37 PM
dotnetjunky wrote:

Regarding issue #1:

When you enable package restore, NuGet creates a nuget.config under the <solution root>\.nuget folder. That file has a flag 'disableSourceControlIntegration' set to 'true'. Do you keep that file in your solution? 

Yes, sure

Dec 27, 2012 at 6:29 PM

I am also having the same issue hwere my \packages folder is being added to TFS.  I even tried to move the 'disableSourceControlIntegration' element section to the default Nuget.Config in %Appdata%\Nuget\ but it didn't seem to help.

I am able to reproduce this using: msbuild myproj.csproj /target:RestorePackages /v:diag

Dec 27, 2012 at 7:04 PM
Edited Dec 28, 2012 at 12:52 PM

Ok, some more testing/info. What I noticed is that the actual unzipped packages are not being placed into TFS but the "packages\repository.config" file is being placed there.  I initially missed this because I was just watching the "packages" folder level and not the contents.

If I delete the \packages from my solution folder and also make sure to delete the "add" from TFS. 
If I then go and use the nuget.targets to restore the package using this command:  msbuild myproj.csproj /target:RestorePackages /v:diag

It does NOT make anything go into source control initially.

It will automatically add the "packages" folder with the single "repositories.config" to TFS again if I perform ANY of the following operations:

-Right Click "References and goto Manage NuGet Packages, then just click Close on the dialog
-Close and reopen the .sln

This seems to me that Visual Studio is somehow causing it to automatically add it in.  Is this file required to be in source control?

If I set the 'disableSourceControlIntegration' to false it does go back and start adding all unzipped package content as well.

Are you seeing the same issue Almas?

Some more information:

If I comment out the 'disableSourceControlIntegration' section form the local projects .nuget\Nuget.config and add it to the default %appdata%\nuget\nuget.config it does not honor it for the following scenarios:

-If I undo the TFS adds again for the packages\repositories.config, delete the local packages folder in the sln folder and then Right Click "References and goto Manage NuGet Packages, and click the "Restore" button it adds Everything back into source control ignoring the 'disableSourceControlIntegration' even if it is specified in the default nuget.config file.

-If I Uninstall and reInstall a package via the GUI it also appears to ignore the 'disableSourceControlIntegration' switch and adds everything to sourcecontrol

-If I Uninstall and reinstall from the package manager console it adds everything to source control

Dec 27, 2012 at 8:07 PM

OK, now I feel like I am spamming this issue...some more things I noticed is that if you have multiple Nuget.config files with differing/missing values for 'disableSourceControlIntegration' It can cause an issue because of the order of evaluation/application of the values.  For example if at my '%appdata%\nuget\nuget.config' file I specify this value is true but completely remove the <solution/> element out of a nuget.config located in my project directory then this effectively disables source control integration.

Dec 28, 2012 at 8:03 AM
chekm8 wrote:

Ok, some more testing/info. What I noticed is that the actual unzipped packages are not being placed into TFS but the "packages\repository.config" file is being placed there.  I initially missed this because I was just watching the "packages" folder level and not the contents.

Yes, only "Shared" folder (my custom package folder) and repositories.config inside it are added to TFS, not unzipped packages. But anyway I wouldn't expect that.

Dec 28, 2012 at 12:25 PM

Almas,  I'm not sure if you have gotten this far or not yet...And was wondering if anyone else out there in the community has gotten these two features to work together.  It seems like package restore and a custom repository path will only work in the scenario where you can dictate to the developers how they use Visual Studio and their work spaces.

Let me explain.  If we set up a relative custom repository path to say "Shared".  It will depend on where this repository path is set.  Lets assume for now that it  is in the default %appdata%\Nuget\nuget.config.  When the packages are unzipped they will be placed in %appdata%\Nuget\Shared.  This is great and ensures that only one copy of the unzipped repository exists on the developer's PC (Which I believe is the main intent behind this feature).

With the above configuration, if a developer installs a package the sets up project references the reference will have a HintPath to the dll's out in %appdata%\Nuget\Shared; maybe something like "c:\users\JohnDoe\Appdata\Roaming\Nuget\Shared\somepackage\something.dll.  When a user checks in this to source control and another user grabs it  or a build server tries to act on it, they will not find the .dlls because the HintPath is not going to be found on their pc.

If we place the "repositoryPath" in a nuget.config at a location which is at the root of our project collection it would work a bit better for other developers because the relative patch would be the same for all of them but, this assumes that you have dictated that all developers have a single workspace and that that workspace is mapped at the root of source control for all projects.  In this case we may have a csproj that points to "..\..\..\Shared\somepackage\something.dll". Also that the build server is set up similarly so that the exploded packages are placed in the same relative path that is stored in the csproj.

I'd love to hear from someone that has this working and what they have implemented.  I am almost leaning towards not using the repository path and let the packages explode in the default location then it will just work for all devs and the build server.

Almas, you stated that you would be modifying a Nuget.config at the sln level to specify shared.  I am not sure why you would specify this at the .sln with a relative path because inst that the same as not specifying it and having it drop into the "\packages" folder that is created at the .sln level?

Dec 28, 2012 at 1:15 PM

Probably my use cases are quite specific but they are following from the our branching schema and from the fact that some common projects are included into different solutions on different levels of folder structure.

E.g. I have team project $Common which is branched into several other team projects, so it exists on the level 2 and on the level 3.

Using this approach i need to have packages folder on the level 2 and on the level 3 (in the each particular team project) to have valid relative file references in Common. But I need to place into TFS several copies of packages. So i wanted to avoid it using combination of Package Restore and Custom package folder location.

<root>

    |---$Common

             |---<Common>

             | Common.sln  (custom package path points to <root>\packages folder, otherwise by default packages will be placed into <root>\Common\packages)

    |---$TeamApp

       |--Trunk

            |--- <Common> (branch of $Common)

            |--- <WebApplication>

            |--- <packages>

            |--- TeamApp.sln (custom package path points to <root>\TeamApp\Trunk\packages folder, so both Common and WebApplication use it together)

   |--- packages (is used by $Common)

Also sometimes I need to branch the whole TeamApp into level 3, so hierarchy will go deeper. <root>\TeamApp\Development\Dev1Branch

So I can't set single repository path in the global nuget.config for my projects as their branched copies will have broken file references to the package files. 

 

 

 

Apr 8, 2013 at 1:06 PM
Edited Apr 8, 2013 at 1:12 PM
Hi guys,

I'm testing the newest Nuget build 2.5.40405.130 on VS 2012.
As I can see most of the issues i described in the first post have gone, but some not obvious behavior still exists.

Steps to reproduce:

1) I created a solution with project A.
2) Enabled Package restore on solution.
3) Created nuget.config in the solution folder with the following contents
<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <config>
    <add key="repositoryPath" value="Shared" />
  </config>
</configuration>
4) Opened “Manage Nuget Packages” form and installed NLog package to ProjectA.

Actual behavior:
Folder with name Shared was created and repository.config was placed into. Both items were marked as added to TFS.

Expected behavior:
Folder with name “Shared” should be created on disk and not added to TFS.
It may contain repository.config but IMHO it shouldn't be marked as added to TFS.

5) I closed solution, removed folder Shared from the disk in Explorer.

6) Opened solution again, initiated build. Nuget created Shared folder and restored packages. It is good.

7) I reopened solution.
Shared folder and its repository.config were marked as added to TFS again.


Questions:
Why Nuget tries to put repository.config to TFS all the time?
Is it bug?
I would think that with enabled "Package Restore" option folder containing packages shouldn't be placed into TFS at all.

According
http://stackoverflow.com/questions/7286261/nuget-repositories-config/7297465#7297465
@MattHickford If you use the Package Restore workflow, you can completely omit the Packages folder from source control (including this file). – David Ebbo Jun 26 '12 at 17:41
Apr 9, 2013 at 11:58 PM
It's not a bug. We do want to add repository.config to TFS. What problem is it causing that you don't want to add it to TFS?

That said, we do want to move the repository.config file to under the .nuget folder, so that the entire 'packages' folder can be left out of source control.
Apr 10, 2013 at 8:54 AM
I just thought that Package Restore feature makes it not necessary and David Ebbo confirmed that on the link above.
Apr 11, 2013 at 2:51 AM
David Ebbo's statement was true at that time, but we made a change after that.
Apr 19, 2013 at 2:10 PM
dotnetjunky,

It is clear that there was an intentional change to add repositories.config to TFS, and this appeared starting with NuGet 2.2. I think many of us are puzzled as to why this change was needed? I'm on a project where we have dozens of solutions using package restore, many of them sharing projects which require us to use a common packages folder. If we checked in repositories.config this would cause a major issue with merging changes from over 50 developers and having this part of every build would cause every CI build to get triggered any time someone touched this file. I have resorted to deleting repositories.config from TFS, then checking it out and locking it so nobody can check in a new copy. This seems to work fine and nothing is breaking when repositories.config is not checked into source control. So if repositories.config can easily be rebuilt the next time someone opens the solution in visual studio, why does it need to be in source control?