Include repository.config definition

Jul 4, 2011 at 3:07 PM


I want to know if there is already a way to handle the following scenario. Let's say that we have 2 projects A and B (not in the sense of a project file, but as an entirely different software).

- A depends on B, but B is intended to be used in source form so it is included in source form on A (actually we are including the source from a Mercurial external).
- B depends on several nuget packages.
- A depends on a subset of the B's dependencies. 

Now if I install packages on A they will be stored with their own assemblies so if B packages change A would not know it. Is there any way to link the repository.config file of A with B like for instance:

A sample ProjectA repositories file would look like:

  <repository path="..\Source\ProjectA\packages.config" />
  <repository path="..\External\ProjectB\packages\repository.config" />

Thanks in advance,

Jul 4, 2011 at 4:00 PM

Hi, I think you are over complicating things.

First of all, NuGet doesn't work like you suggest. It sounds like you're trying to merge two independent projects that are stored locally and have NuGet manage the interdependencies. NuGet deals with packages and dependencies between packages.

So what you really want to do is make ProjectB into a NuGet package (PackageB). You can create packages that include source code. Just reference the source in the content node of the .nuspec file. ProjectB can have whatever package dependencies it needs. If ProjectB is really for internal consumption only, then create a local repository to store this package.

Now in ProjectA, you simply reference PackageB. This will pull in the source code in the package and any of PackageB's dependencies. You said A also had a subset of B's depenedencies. These packages will have already been downloaded when adding PackageB, so the references will simply be added to A.

If later on B is updated, A will still work fine since it is dealing with a specific version of B. Once you're ready, you can update PackageB from A and it will update the source files (as long as you haven't changed or moved them) and pull in any new packages as needed.

So as you can see, if you think in terms of packages even for internal projects, then NuGet will definitely simplify things.

Hope this helps.

Jul 4, 2011 at 4:50 PM

Hi, Kiliman.

As you stated it is true in most scenarios, except where you have externals. The issue is that ProjectB is not completely independent from ProjectA, in a sense it is part of ProjectA even though it has its own identity. If they were independent projects I agree with you, such a solution would be overkill and better solved encapsulating it in a package.

Mercurial externals work exactly like a source pull would but with a far greater degree of control over versioning. Without it you cannot have fine grained versioning. What I am trying to solve here is having to commit 100s of megabytes because they both use the same packages and storing them in mercurial is killing us; the size of the repository is already in the 600s megabytes because of binary dependencies updates (should be on the 50MB without binaries) and worse it is growing fast.

Given I cannot allow the references path to modify the assembly referencies to the broader solution (ProjectA) packages directory (as that would affect the standalone assembly reference for ProjectB) I dont see any viable solution. Any idea would be welcomed, and more importantly tried :)

An example as the one I provided would work as a WPF Merged Dictionary. The other potential solution is for packages.config files to store where they are getting their packages from (it is not as elegant though). Merged repository files can solve this and similar dependency locations problems quite elegantly for projects using Mercurial or Git externals (something it is only possible now storing the binaries with all the gotchas apllied).


Jul 5, 2011 at 5:07 PM
NuGet does not and is not meant to support every scenario we as a development community dream up. To do so would overcomplicate the toolset and make it unmanageable. Now that I've said that, it does support quite a few scenarios.

One option for you: nuget has a command line version. You don't get all of the referencing/running powershell scripts goodness, but then again there is no tool in any community that gives you that kind of experience (that only happens in an open visual studio solution scenario - multiple solutions would each need to run install package for that kind of goodness).

Due to space limitations that you suggested, your option here is not to check in the packages directory. There are some nice posts about how to do this so I won't elaborate any further.

A lot of people complain about the packages directories not sitting nicely next to each other when the solution files are at different levels. Symlinks solve that problem nicely. - use them, love them. They are underused but extremely powerful and should solve the job for most people out there that need the packages directories to look the same.