Every once in while when I publish a NuGet package and then try to use the published package in another project I end up with a situation where the new package simply is not recognized. Most of the time it shows up after a few minutes, but on more than a few occasions I've stuck waiting for quite a while waiting for the package cache to refresh. Luckily there's a way to nuke the cache and force Nuget to re-read local packages and while that is the nuclear option that requires downloading a lot of packages it works to make your project compile - right now!

I recently needed to add a local reference to my project and I couldn't quite figure out the best way to do it in a transparent way to consumers of the repository, so that they wouldn't have to explicitly configure additional build settings in order to find dependencies. In this post I discuss how to add local references or use a local Nuget source to add non-public packages to your projects without explicit package feed configuration.

.NET SDK style projects no longer support packaging NuGet content into projects as older projects did. So if you need to ship some dependent content with your library you need to find a different way to do so. In this post I look at a specific example of library that requires additional content and look at how to distribute the extra content as well as displaying a readme file to link to instructions when the NuGet package installs

ASP.NET 5 and the new DNX runtime make it very easy to include external source code based packages into your own projects. It super easy to pull a project - including Microsoft's core DNX runtime projects, from GitHub and then link it into your own projects. This is great for debugging and fixing an immediate problem that might be a show stopper for you, or makes it very easy to contribute back to an open source library. In this post I'll describe a debug scenario I ran into in my last post involving a bug in the DNX runtimes, and show how to download and link the library from Microsoft's GitHub repository, fix the bug and integrate the code into my own project.

In getting ready to put out version 2 of Westwind.Globalization I've been rearranging the NuGet package layout a few times and I'm considering further breaking out the package layout. In this post I describe some of the dilemmas I'm looking at in deciding how much abstraction is required in breaking the NuGet packages into easily usable and maintainable components with the least amount of friction.

There's little known NuGet command that allows you to re-create assembly redirects for all NuGet packages in your project or an entire solution.