19

Trying to figure out the best way to use Nuget in a development environment to manage our own libraries.

We want to standardize on Nuget way of doing things for our 3rd party libs, but would also like to use Nuget to manage our internal utility libraries, for developers consuming the in house libs this is great and everyones happy. However, for devs actively working on the Utility lib it seems to be more problematic, their previous process of build lib , build main app , F5 and go is now slowed down with publishing, and updating and potentially lots of packages, not to mention the moaning about additional process!

We use TDD on the internal libs but everyone needs to be able to debug and modify libs along with main app, have seen Phil Haacks demo on debug packages in 1.3 and read David Ebbos blog, but that fits different scenario.

So what is the best process for dev/debug cycles? if to use Nuget then we need to accept the existing constraints, or is there a hybrid practice people are using and maybe 1.3 gets closer to automating all this, or do we just avoid Nuget for internal packages which would be a real shame.

Loving Nuget, maybe wanting way to much from the little guy, feedback appreciated.

Thanks

DoodleWalker
  • 289
  • 3
  • 8

2 Answers2

3

I'd suggest you use separate network shares or feeds (similar to what myget.org supports in the cloud) for different scenarios. You could imagine creating a CI share, a QA share, a Releases share, ...

Make people working on the referenced library do CI builds that drop CI packages on the CI repository for instance, and have them picked up by other projects (who just need to do a simple update, could be automated through PowerShell in pre-build: check for new version, if so, update).

Just make sure that when products release their milestones, they also release with released dependencies (could be as simple as switching feeds, releases will always have a higher version number than CI builds).

Hope that helps! Cheers, Xavier

Xavier Decoster
  • 14,580
  • 5
  • 35
  • 46
  • This is what I also think should be possible. However, I have not found any practical solutions on how the dependencies are to be resolved. We are currently looking at doing the following: 1. Local dev builds being published to the devs' own local feed. 2. Build-server Development builds being published to the shared Development feed. 3. Build-server QA builds being published to the shared QA feed. 4. Build-server Release builds being published to the shared Release feed. But, I am not sure how to set up the dependencies in the projects to choose the right feeds when dl'ing the assemblies. – Spiralis Jan 26 '14 at 22:08
  • You can't configure feeds "per package". NuGet.config is per solution. Also, I don't think pushing packages to each dev machine is the approach you wan't to take. What if a dev-machine isn't available, or is working offline? Note that every dev-box already has a local cache. Out of curiosity, did you try myget.org? Especially, take a look at the package sources concept: http://docs.myget.org/docs/reference/package-sources – Xavier Decoster Jan 27 '14 at 07:42
  • Pushing to the developers own machine is only for easily resolving dependencies on that devs own machine. It is not for sharing to anyone else. Each package is in our setup a repo in its own, sp the root folder can contain the nuget.config file. We have started setting it up like this, and even though we are not done yet, it does actually seem like it is going to work. Although, we have different challenges that we are trying to get around though (http://stackoverflow.com/questions/21467094/nuget-issues-with-packages-config-project-references-and-the-solutionwide-packa) – Spiralis Feb 02 '14 at 23:23
1

If you're working on the source code for the lib and the main app at the same time, I'd say NuGet is probably not a good solution. I think it'll only work in situations where you work with a "stable" version of the library that don't need to change frequently during the development of your main app.

That said - is it possible the development on your library could be done in isolation? You already mention you're doing TDD on the lib, so why can't that work be done, then built, deployed, then the main app work done?

Danny Tuppeny
  • 40,147
  • 24
  • 151
  • 275
  • I had the same problem, working on the application and the library at the same time, then create a new package and upgrade the app to the new version, try this extension for this: http://visualstudiogallery.msdn.microsoft.com/68878c27-110c-43ec-ae61-3ea3f7aae88c – Rico Suter Aug 23 '14 at 13:39