2

Suppose that a large project is split into multiple projects, each housed in an individual Mercurial repository (as per What's a good way to organize projects with shared dependencies in Mercurial?).

Suppose also, that a dependency manager is being used internally (we're using NuGet, but the same could apply to Maven) so that:

  • ProjectA depends on Ninject and MongoDB
  • ProjectB depends on ProjectA, and log4net

Projects A and B can be built independently; NuGet automatically downloads both OSS and internal dependencies from a NuGet server (ProGet in this case).

Suppose finally, that ProjectB depends on v1.2.3.4-SNAPSHOT of ProjectA, and that a CI server continually updates the ProjectA.1.2.3.4-SNAPSHOT package in the NuGet server. Thereby ProjectB will always be developed against the latest checked in changes of ProjectA.

What if related changes are required in both Project A and B? What neat and clever ways are there to do this properly? Some ideas:

  • Developer checks out Project A and B. Changes are made to A, built, and checked in. Developer waits for CI server to build and update the NuGet server. Changes are made to B, built, and checked in. (I dislike this as code is being checked in as part of development process.)
  • Developer checks out Project A and B, and rewires B to use A source as a dependency (instead of NuGet package ProjectA). Changes are done to both A and B. Check in is performed for both A and B together after proper testing, but developer must ensure dependency changes are not checked in.

I'm not particularly good at this, so I think that someone will blow my ideas out of the water with something quite clever.

Community
  • 1
  • 1
Bob
  • 21
  • 1
  • For the second idea, this extension might help you: https://nugetreferenceswitcher.codeplex.com/wikipage?title=Guide – Rico Suter Sep 22 '14 at 11:37

2 Answers2

0

I don't know about how NuGet does it, but with Maven, your second idea works fine, apart from 'rewires B to use A source as a dependency' being unnecessary. You would just build A locally (using install) and it would be installed to the your local Maven repo. Then when building B, it will pick up the newly built A, rather than the one from the central repo.

artbristol
  • 32,010
  • 5
  • 70
  • 103
  • That's good. I'm new to both Maven and NuGet, but it seems the Maven method you describe is what we want. It may be that NuGet will get developed towards this method, but currently there is no local repository, only a local cache and nothing is by default 'installed' to it. Looking into Maven, it appears that it doesn't really integrate well into Visual Studio, which I think rules it out for us. – Bob Aug 03 '12 at 10:40
0

I could think of the following with nuget : In Project A drop the packages at a central location (in this example I am placing it in c:\localpackages)


Build A with MSBUILD.exe /t:Build,Package A.csproj

With Project B you could add a .nuget\nuget.config that specifies (you can read more about specifying package folder location here http://docs.nuget.org/docs/release-notes/nuget-2.1) This should pick the changes made by project A. It might become tricky when you have different versions of nuget package dropped for A

Hope this helps.

Deepak
  • 2,223
  • 17
  • 15