Working on shared components from a solution that uses them

Topics: General
Aug 23, 2012 at 9:30 AM

Say I have component Foo which I want to share between solution A and solution B using my own private NuGet package source. Typically I will need to modify Foo at some point when I need extra functionality from one of the solutions, say solution A. How can I most easily get the source for Foo into solution A so that I can work on it at the same time as the consuming code, ultimately resulting in a new version of Foo (which I can then update in solution B using NuGet)?

I met some resistance to NuGet when my colleagues ran into this situation during a trial about a year ago, so I'm wondering how people are dealing with it now. I appreciate that NuGet helps control change in shared components which is a good thing, but it still needs to be done! :)

Aug 23, 2012 at 10:02 AM

Is the component Foo self-contained? I mean does it have its own solution and repository (or team project or dev branch)? As such, it can have its own development flow, lifetime, versioning and release schedule resulting in a NuGet package.

When you require the sources for development convenience, simply branch the Foo project into your current workspace and add it to your solution (or create a new one for this purpose). Modify what needs to be done during development, reverse integrate/merge your changes into the Foo project's home branch and make a release. Once modifications have been released, don't forget to consume the NuGet pkg again :)

This setup also facilitates changes being made simultaneously within the context of solution A and B separately, each in their own branch, and as such avoid release bottlenecks.

Using TFS, you can play with workspace mappings & branches. Using a DVCS, you achieve the same using repositories and local clones.

If all of this seems hard, then another question might pop up: what is driving change in Foo? Does the change belong in Foo, or should Foo be extensible enough to accomodate the change in the consuming project?

This approach has proven to work for me. Maybe it works for you as well.

Aug 23, 2012 at 10:26 AM

Thanks Xavier, that sounds like a reasonable workflow, although I'll have to see how cumbersome it is to switch back and forth between the Foo package and Foo project. Maybe this is something that the NuGet extension could help with in the future.

Aug 23, 2012 at 10:48 AM

I feel your pain, not saying it's a perfect solution either :)

I think it could be really awesome if we could add this to solution-level metadata for the consumed nuget pkg (so not contained within the pkg, but maybe a mapping in the project's packages.config file or so).

Flagging a pkg reference as "under development" could then switch the reference to the project path found in this packages.config file, and vice versa.

<?xml version="1.0" encoding="utf-8"?>
  <package id="Foo" version="1.0.1" targetFramework="net40" developmentMode="true" hintPath="$(SolutionDir)\..\OtherRepo\FooDir\Foo.csproj"/>

Right-clicking a package reference could expose an option to toggle this flag on the solution level (for this package Id and this version).

Just a thought, I'm sure something's possible to facilitate this scenario.

Aug 31, 2012 at 9:13 PM

My company has developed a tool to help with this workflow called SlimJim.

It started out as a .sln file generator and recently we built support to convert assembly references into project references to help make project build in the right order and get the changes as you make them.

The downside is you have to remember to "unconvert" these changes to the csproj files before you commit, or you'll probably break the build.

Hope you find it useful.