Tag: NuGet

Every time npm has a supply chain incident, it’s tempting to think “haha, npm had yet another supply chain attack!” and feel safe in .NET land. But the tools to do the same thing in .NET, or at least similar things, are all there. Module initializers, source generators, MSBuild targets, startup hooks. A number of techniques exist to smuggle code into someone’s codebase, and most of them run before your application’s Main method is even called.

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. TL;DR: Want to use Bitbucket pipelines to build .NET Core libraries? Grab this bitbucket-pipelines.yml and add it to source control.

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)”