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?
Best Answer
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.