Tag: NuGet

For a couple of months now, I’ve been pondering about what tools are at your disposal in .NET to help build and execute a supply chain attack. My goal was to see what is available out there, and what we, as .NET developers, should be aware of. Prepare for a long read! Now, forget that short introduction, and let’s start anew…

Yesterday, Aaron Stannard posted some awesome news for the .NET community: the introduction of Sdkbin. Sdkbin is targeted at solving the OSS sustainability problem by automating the majority of the sales, fulfillment, licensing, and accounting needed to sell libraries, frameworks, and support plans. It’s (roughly speaking) an App Store, delivered as a NuGet feed. This seems like a great idea, and most of all, one that is needed.

In this post, I’ll describe a little trick I used while building a Rider plugin for XAML Styler, which is referencing a specific assembly from a NuGet package. Let’s start with some background on why I needed this, followed by how to reference a specific assembly from a NuGet package. If you don’t care about the background, feel free to skip the first section.

In an application I’m writing, I need to deserialize some JSON. I know the class to use is JsonConvert, but which NuGet package was that type in again? Granted, that’s an obvious one. Yet, there are many uses for a “NuGet reverse package search” that helps finding the correct NuGet package based on a public type.

A few weeks back, .NET Core 1.1 was released (and a boatload of related tools such as Visual Studio 2017. For .NET Core projects, a big breaking change was introduced: the project format is no longer project.json but good old .csproj. That’s a little bit of a lie: the .csproj is actually an entirely new, simplified format that combines the best of the old .csproj and project.json and works with .NET Standard and .NET Core.

You may know (or not, shame on you!) Xavier Decoster and myself are operating MyGet, a hosted service providing teams with hosting and management of NuGet, npm, Bower, VSIX and debugger symbols. Recently, we started looking into how we could do better on the content marketing front, an important piece of getting people to visit and hopefully sign up to our service. We decided on starting a series on the MyGet blog, named “NuGet and NPM news from the community”.

A while back, I signed up for the beta of Bitbucket Pipelines, a new continuous integration service from Atlassian, built into Bitbucket. The build system promises easy configuration using YAML files to describe the build steps. It runs builds in a Docker image, so that means we can also use it for building and packaging .NET Core libraries. Let’s see how. I created a simple .NET Core library which contains a useless Hello.cs class, and a project.json that holds project metadata. The class itself is not very interesting, the project.json file is:

Twitter celebrated its 10th birthday this week, and those who have been on that social network long enough know that at least once a week there’s a massive outrage about something that, in the end, usually does not seem so bad. This week’s topic: someone broke the Internet!

When working in larger projects, you will sometimes encounter errors similar to this one: “Could not load file or assembly 'Newtonsoft.Json, Version=4.5.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed' or one of its dependencies. The system cannot find the file specified.” Or how about this one? “System.IO.FileLoadException : Could not load file or assembly 'Moq, Version=3.1.416.3, Culture=neutral, PublicKeyToken=69f491c39445e920' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)”

Some developers prefer to strong name sign their assemblies. Signing them also means that the dependencies that are consumed must be signed. Not all third-party dependencies are signed, though, for example when consuming packages from NuGet. Some are signed, some are unsigned, and the only way to know is when at compile time when we see this: That’s right: a signed assembly cannot consume an unsigned one. Now what if we really need that dependency but don’t want to lose the fact that we can easily update it using NuGet… Turns out there is a NuGet package for that!