4

I'm coding on a project that has several Azure-based applications, as well as several Windows services, etc. Needless to say, it's just a bunch of individual applications that are deployed out to Azure, or elsewhere, and expected are all expected to work together.

We use Nuget for our underlying library project versioning. Every feature or change results in a bump to the Nuget version, a package published to our private Nuget server, and a subsequent update to every other application that needs the update. This is currently a tedious manual task, but is not even my most immediate source of frustration.

The thing that I struggle with the most, currently, is while doing development on a feature that requires changes across the entire set of applications, from bottom to top, and having to constantly push out Nuget packages and update Nuget packages just to even develop and debug.

Prior to using Nuget, we may have just added all of these projects as direct dependencies on disk, which removes versioning but instantly lets me develop against my local changes.

Now with Nuget, I can't develop against local changes without pushing out a new package.

Is there a workflow that I'm missing that would allow me to still use Nuget but also be able to make changes and work locally without having to push and pull Nuget packages all the time?

Can I somehow develop against local projects, but also somehow have the project dependencies know to use the Nuget packages?

Ryan
  • 7,733
  • 10
  • 61
  • 106
  • If I understand correctly you want your projects to auto update whenever a new nuget version is available? – André Sanson Jun 12 '19 at 12:03
  • @AndréSanson not necessarily, I guess. I was hoping for something like how npm, node.js' package manager, lets you work with local packages. With npm, you can link your local project directory to the local npm package cache folder. This just makes node.js load your local package instead of the one downloaded from npm. It's all just symbolic links, but it works well. To use it, you still have to tell your project to use a particular version of the library, though, so it doesn't do any automated updating. It's just a handy tool for local development and debugging before publishing the package. – Ryan Jun 12 '19 at 19:47
  • are the various projects in the same source control repository, or different repos? – zivkan Jun 13 '19 at 01:21
  • @zivkan sorry for late reply. they're all in the same git repository. – Ryan Jun 17 '19 at 15:50
  • 5+ years ago Eclipse/Maven already did this automatically when you reference a dep with SNAPSHOT in the version. Not sure what's taking the .NET space so long to catch up. – Kevin Wong Dec 12 '19 at 19:38
  • 1
    Does this answer your question? [Pain-free local development while also referencing NuGet packages](https://stackoverflow.com/questions/27711364/pain-free-local-development-while-also-referencing-nuget-packages) – Mark Rotteveel Jan 29 '21 at 15:52

3 Answers3

2

I ran into this issue when setting up a shared NuGet repo for my company. You can set up local a NuGet feed and 'publish' just by dropping files to a folder. This is extremely useful for local testing before you're ready to publish to the shared repo.

Also, NuGet uses semantic versioning. I find it useful to have pre-release versions by using a tag like MyLibrary.1.0.0-prerelease-12345 so you can still have incremental builds, but most other apps will not be notified of the changes until you create a major release such as MyLibrary.1.0.1. This could require you to make some changes to your DevOps process, but it allows multiple developers to test your package before 'officially' releasing it.

If your issue is that you want to be able to easily update multiple applications locally and test those changes. I have occasionally found it useful to create a single solution file encompassing all my projects so I can quickly open, update, and build everything in one Visual Studio instance. However, this solution is not particularly scalable, so you might be better off writing PowerShell scripts for automation.

Update Another solution that you might find useful is NuLink. I have never tried it so I can't actually endorse it, but it purports to provide similar functionality to npm link (and actually uses symlinks just like npm does).

p.s.w.g
  • 146,324
  • 30
  • 291
  • 331
  • OK. I suppose this works if it's the only option. This is essentially what npm, node.js' package manager, does for you. You've just described the manual way of doing so. It would be super handy is nuget had some built in functionality for linking projects to local nuget cache directory so that it puts out the built package every time you compile, or something. – Ryan Jun 12 '19 at 19:49
  • @Ryan A given project is built and tested with a given version of its dependencies, and if those dependencies change, the project could break in any number of dramatic or subtle ways. Generally speaking, package managers want you to be aware of this and so encourage you to manually update your dependencies. Of course, you can always add a [pre build event](https://learn.microsoft.com/en-us/visualstudio/ide/how-to-specify-build-events-csharp?view=vs-2019) to update your dependencies every time you build, just beware of volatile builds. – p.s.w.g Jun 12 '19 at 19:55
  • @Ryan After re-reading your comments, I see what you mean. See my updated answer for an alternative that could be helpful. – p.s.w.g Jun 12 '19 at 20:02
1

Given the projects are all in the same repo, just use project references instead of package references.

When you pack a project, NuGet will convert project references into NuGet dependencies, and the dependency version will be the same as what the other project is if/when it is packed.

zivkan
  • 12,793
  • 2
  • 34
  • 51
  • I've marked this as the answer because it's closest to the workflow I was hoping for - something managed and built into the VS workflow. There is a caveat though in that it only works for projects in the same solution. – Ryan Jun 17 '19 at 17:15
-1

Check this answer, where you could:

  • build the dependency's code locally to produce DLLs.
  • replace the DLLs in your machine's nuget cache folder corresponding your dependency with the local DLLs produced in the previous step

That's a quick way to see changes locally without publish-consume cycles

Bahaa
  • 1,577
  • 18
  • 31
  • While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Link-only answers can become invalid if the linked page changes. - [From Review](/review/low-quality-posts/28195746) – zrfrank Jan 29 '21 at 11:22
  • Well, I didn't want to repeat the content of the answer here producing redundancy. I don't think this earned me a downvote, but I see your point. Answer edited. – Bahaa Jan 29 '21 at 12:05
  • Note that you could also flag the question as duplicate, if an answer of a different question is a perfect fit. – janw Jan 29 '21 at 16:24