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.