I've written about NuGet Central Package Management in the past, but since then there were some news in this field. Most importantly, the .NET Upgrade Assistant Visual Studio extension and command line tool has been extended with support for upgrading projects to Centralized Package Management.
For the command line tool I was working on recently, I decided to distribute it as a .NET tool. It didn't have anything to do with .NET, except for it being developed in .NET, and the few potential users being .NET developers. That's also why I didn't want to publish it to NuGet Gallery at first and was considering the GitHub Packages NuGet registry instead.
As I wanted to make my side project more easily available to others by releasing it to GitHub and NuGet, I tried automating this step in GitHub Actions as well. It took me less time to get it working than expected.
When you have many projects in your Visual Studio solution, it's not uncommon that the same NuGet packages are installed in multiple projects. In such a case, it's all too easy for the version of the same NuGet package in different projects to diverge. Once you notice this problem, you can quickly fix it with the Consolidate tab of the NuGet Package Manager in Visual Studio. But it would be even better if you could prevent it from happening in the first place.
Caching of NuGet packages can significantly speed up .NET builds in GitHub Actions, especially if your projects has many dependencies. The generic cache GitHub action used to be the only way to do that and I described how to configure it a while back in my article for DotNetCurry Magazine. However, recent versions of setup-dotnet GitHub action now have this functionality built in which makes the configuration even simpler.
When I was looking into GitHub Actions, I found an example configuration for dependency caching that seemed wrong to me. It specified that a unique key for caching dependencies should be generated by hashing all files named package.lock.json in the repository. I would expect the *.csproj files to be used instead.
The recently disclosed vulnerability in Newtonsoft.Json prompted me to take a closer look at the tools available in the .NET ecosystem for identifying referenced packages with known vulnerabilities.
Visual Studio Tools for Unity enable the convenience of developing Unity scripts inside Visual Studio. A naive attempt to install a random NuGet package into the UnityVS project will still most likely fail. To make it work, the NuGet package will need to comply with special requirements. Even then, there will still be some manual work left.
On Tuesday Microsoft Slovenia organized the second TechDays event leading up to the 20th NT conference. The event consisted of 4 tracks; I had the opening session for the Visual Studio 2015 track. As always slides and demos from my session are available for download.
I focused on the advantages NuGet brings to the process of managing project references, but also gave a short tutorial on how to create and publish a new NuGet package. I concluded the session by taking a broader look at the NuGet ecosystem and the tools improving it and taking advantage of it.
Packt Publishing is currently celebrating 10 years of its existence. For this very special occasion they have decided to offer a significant discount on their complete catalog of eBooks and videos - until July 5th all their titles can be purchased for just $10. Since I'm also the author of NuGet 2 Essentials, one of the books in their line-up, I encourage you to take a closer look at this book.
When using NuGet, you typically don't need to worry about its repository location. In simple every day scenarios it just works without even paying attention to it. Once you have more than a single solution file for your product, this default approach starts to break down. To be more precise; the problems occur when a single project file is included in multiple solutions files, which are not placed in the same folder.
NuGet 2 Essentials is an up-to-date complete guide to NuGet, written in a very concise and practical manner with many hands-on examples to learn from and to see the features in action. As the book author, I'm of course biased, but I think currently it is the best available resource for learning about NuGet.
When moving a Windows Phone project referencing Microsoft.Bcl.Async package to a new computer I was unpleasantly surprised. Although I had NuGet package restore enabled on the solution, it not only failed to build, it even failed to load. After some investigation I found out that this was a known limitation in NuGet.
If you've only been using NuGet in typical scenarios with a single solution containing a couple of projects, it probably worked great for you. As soon as the project structure is a bit more complex, things start falling apart. There are two main reasons why it doesn't work as expected when individual projects are included in multiple solution files residing in different folders.
If you've tried accessing an OData feed from a Windows Store apps you've already come across WCF Data Services Tools for Windows Store Apps. It's a downloadable package which extends the Add Service Reference functionality in Visual Studio 2012 to support OData feeds. Without it OData feeds can't be added as services references to a Windows Store app project.
NuGet is a valuable tool for managing references to external libraries in your projects. If you're not using it yet, you owe it to yourself to try it out and see what you're missing. Though, that's not what this post is about. Not only are NuGet packages a great way to distribute publicly available libraries, they can be used just as well for custom internal libraries with their own release management which are used in multiple projects.