Best practices for developing NuGet package alongside consumer?

Question

I'm writing a NuGet package mainly for data access and utility functions that is going to be consumed by multiple web applications, but there will be one main web application that is going to drive the development of the NuGet package. As such I'm going to want to be developing that web application alongside the NuGet package on the same machine so I can easily add the package functionality needed and then test it out in the web application immediately.

However, there is still some annoying overhead to this because the NuGet package has to be published and the latest version pulled down each time I add some functionality and want to test it out. If it doesn't work properly I'll need to fix it and go through this procedure again.

Is there a best practice for being able to easily develop a NuGet package alongside a consumer of the package? I could have the package solution output its DLLs to a common directory and add a direct reference to the DLLs in the consumer but that would be a temporary reference that shouldn't be checked in, so it seems like a bad way to do things. Would it be appropriate to have the NuGet package project in the same solution as this main web application which is going to consume it, but use a project reference rather than a NuGet package reference?

Answer 1

NuGet has the ability to point to any file system location. It will treat this directory as a local repository. Publish here during your dev cycle.

The other thing you’ll want to do is automate the packaging process in your MSBuild file. You don’t want to have to manually fuss with the GUI every time you want to update the local repo so you can test your client.

• Jez: Doesn't that mean I need to change the NuGet reference in the web application when I want to publish it?
• RubberDuck: I don’t remember the details exactly. It’s been a few years since I worked w/ the MS stack. You may be able to manage it locally by telling NuGet to check the local repo first. Not entirely sure if that changes things in the project or not.

Answer 2

I think 'best practice' is to develop the nuget package by itself, with enough tests to ensure that you can consume it without having to debug.

But I do know what you mean. I think the common work around is simply to reference the projects during development and switch to the package once you are stable.

Remember you can publish and reference a.b.c.d-prerelease versions.

• DrGriff: Ewan is right. Take your "Critical Success Factors" from the one main web application that you know about, and then write your Package using TDD with thorough testing. Use .NET Standard 2.x if you're not using Asp.Net MVC (see stackoverflow.com/questions/50276149/…)