The Modern .NET Show

S07E09 - Modern .NET NuGet Packaging with Scott Harden

Sponsors

Support for this episode of The Modern .NET Show comes from the following sponsors. Please take a moment to learn more about their products and services:

Please also see the full sponsor message(s) in the episode transcription for more details of their products and services, and offers exclusive to listeners of The Modern .NET Show.

Thank you to the sponsors for supporting the show.

Embedded Player

S07E09 - Modern .NET NuGet Packaging with Scott Harden
The Modern .NET Show

S07E09 - Modern .NET NuGet Packaging with Scott Harden

Supporting The Show

If this episode was interesting or useful to you, please consider supporting the show with one of the above options.

Episode Summary

The interview with Scott Harden discusses the topic of modern .NET NuGet packaging, focusing on the latest developments and best practices in this area. Scott shares his expertise as the author of ScottHarden.com, a popular website for learning about data visualisation and other technical topics.

One of the key aspects discussed during the conversation is colour space, which is an important topic in data visualisation. Scott reveals that he was quoted in a prestigious scientific journal to discuss the use of colour in figures and data visualisation, despite being colour blind himself. This highlights his passion for this topic and his willingness to share knowledge with others.

The interview also touches on Scott’s background as a dentist and neuroscientist, which may seem unrelated to .NET NuGet packaging at first glance. However, Scott explains that his experience working in different fields has given him a unique perspective on the importance of effective data visualisation and clear communication in software development.

Scott shares some insights into his journey with ScottHarden.com, including the launch of his popular website and the growth of the associated community. He also discusses the creation of ScottPlot, a project that aims to provide simple and intuitive ways to create plots and charts for .NET developers.

Throughout the conversation, Scott emphasizes the importance of continuous learning and staying up-to-date with the latest developments in software development and data visualisation. He encourages listeners to explore different resources and communities, including his website and Discord channel, where they can connect with other developers and learn from each other’s experiences.

Episode Transcription

So a lot of these features are new features that probably weren’t there when you first made your package. But I’d like to just briefly talk through what each of these are and talk about how to fix them. So before jumping into the complexity of those red Xs, let’s just take a little step back and talk about how to edit what appears in a NuGet package. Because it might be a little bit confusing for someone who’s brand new.

- Scott Harden

Welcome friends to The Modern .NET Show; the premier .NET podcast, focusing entirely on the knowledge, tools, and frameworks that all .NET developers should have in their toolbox. We are the go-to podcast for .NET developers worldwide, and I am not your host: Jamie. I’m Delilah and I will be recording the intro for this episode because Jamie is suffering with a throat infection.

In this episode, Scott Harden joined us for the final part in a special three part series. This final part of our conversation takes the major points from the previous two episodes and applies them specifically to authoring NuGet packages.

We start by discussing what NuGet packages are, cover the NuGet Package Explorer (which you can run in your browser, by the way), and finally wrap everything up by taking a look at a PR that Scott had provided for one of Jamie’s open-source packages: OWASP Headers.Core.

So in this case, it’s like, well, okay, what icon do we use? A lot of developers are like, "I’m a programmer. I’m not a graphic designer." But—I just want to encourage everyone. It doesn’t matter. First of all, no one’s downloading your NuGet package because you’re a graphic designer. Some of the most popular NuGet packages have really, really, really simple icons. And I’m not going to call any by name but it’s kind of a joke where a lot of people make a really simple one-off icon when their project gets small and they kind of feel like they can never change it later because the project got big, so you have a lot of really great projects with really simple icons, so don’t be intimidated by that.

- Scott Harden

Anyway, without further ado, let’s sit back, open up a terminal, type in dotnet new podcast and we’ll dive into the core of Modern .NET.

My voice was created using Generative AI.

Jamie : [0:00:00] Yeah sure. So like we’ve got a whole list of of things, but like let’s talk about…—I know we’ve got the PR that you’ve very kindly raised for one of my packages that is a NuGet package that you can download. But—I think it might be worth just really quickly talking about what a NuGet package is, you know. Because, you know, from my… like anyone can just download a NuGet package, and if you right click and open with WinZip or 7Zip or whatever, you’ll find out it’s just a zip file. It’s way more complicated than that, but it’s kind of just a zip file, right. And it just, because like i… some of my first .NET Framework apps was before NuGet was a thing, right. Y ou just downloaded random DLLs and threw them in the directory with your binaries and everything just worked, right.

Scott : [0:00:51] Yeah. So i’d love to have this conversation, just bringing in everyone. Maybe someone has very little or no experience with with NuGet or maybe they’re very early in their software development journey. Let’s actually just kind of call out here what—I assume we’re both thinking: why would you generally advise people not to download DLLs off the internet and just copy them to the computer?

Jamie : [0:01:13] Oh okay. Yeah, yeah. So that’s a really good question. It is definitely to do with security, right. If you don’t know about where this stuff is is coming from, then there is no way that you can actually ensure that the code you are randomly adding into your application actually runs, right. There’s no visibility. All you’re doing is downloading a pre-compiled binary, it’s just a random stream of ones and zeros, and you’re saying, "yeah. Cool. There is some code in here, but—I have no idea what it is." So there’s no governance, there’s no attestations, there’s no provenance There’s none of this. It’s just, "we promise that there is some code here and we promise that it’s not going to do anything nasty."

Scott : [0:01:57] Yeah, so it’s very much not advised to download DLLs off the internet and to put them on your computer. It’s essentially like downloading an exe file, which—I think more people would know, like, "hey, that’s a very big security concern." But when you download a DLL, it’s pretty much the same thing. You’re downloading code that who knows who wrote that could be executed on your system. So what you said is interesting what you said a few minutes ago is interesting.

Scott : [0:02:22] We kind of mentally treat NuGet packages differently. But if you go to NuGet and you look up your favourite package and download it, the extension is, .nupkg. If you just rename it to .zip, you’ll see it’s just a zip file and you can extract it. And inside the zip file is DLLs. And it’s like, well, wait a minute. There is almost no difference between downloading a raw DLL from the internet or downloading a zipped DLL from NuGet. They are both just downloading DLLs from the internet.

Scott : [0:02:54] And a lot of people, myself included initially, thought that, "well, you know, the NuGet packages just contain source code or even .NET DLLs," and that’s not even necessarily true. They typically contain .NET DLLs, but you can include a third-party DLL in a NuGet package. One of my NuGet packages does it.—I distribute a package that uses a third-party DLL that the source is not available for. It’s a binary from a reputable company, presumably written in C++, but—I don’t have the source code for it.—I just have a header file, and—I distribute it with my NuGet package.

Scott : [0:03:30] And the day that—I realised you can just put arbitrary DLLs in NuGet packages, that’s when it really clicked for me that, "wow, like security is a thing. You can’t just be installing random NuGet packages." This is really important to get right. So some of the things we’re going to talk about today are some things that you can do to kind of secure up your own package and make it a little bit easier to signal that you are who you say you and the package contains what it should contain.

Scott : [0:03:57] So, yeah. So, okay, we talked about a NuGet package, kind of what it is. Most people get their start with NuGet packages, probably consuming them in Visual Studio or maybe in the console they’re using dotnet add package. But when you install a package, it gets downloaded from NuGet as that .nupkg file. And that’s how it’s distributed.

Scott : [0:04:16] But let’s say that someone’s kind of early on their software development journey and they want to make one of their own packages. The way to do it is actually pretty easy. Most people are used to using Visual Studio or the command line, And in Visual Studio, you can build a project, but there’s also a button you can click to pack a project. And on the command line, you can do dotnet build to build it or dotnet pack to create your own NuGet package. And when you do either of those, your source code gets built. And if you have different platform targets, it’ll actually make different DLLs and just package them all together and make a NuGet package and it’ll drop it in your bin folder that’s just ready to use. And you can consume it locally. And for testing purposes, it’s worth knowing how to install NuGet packages from your own local computer. You can search that on the internet to learn how to do that. Or you can make an account at NuGet, and you can just drag and drop that NuGet package into the browser and upload it right from the website. And now anyone can install that NuGet package.

Scott : [0:05:20] So—I just wanted to point out, if someone knows a little bit of c#, but they’ve never made a NuGet package, it’s actually pretty straightforward to get started. And in a lot of cases,—I find it much easier to consume code from a NuGet package.—I find that easier than downloading someone’s repository and copying the source code to my computer. So it’s definitely something I’d recommend people explore if they haven’t done it before.

Jamie : [0:05:42] Definitely, definitely. And for those who don’t know, if you’ve been doing anything with, say, ASP .NET Core, you’ve been using NuGet packages. One of the primary benefits of the new architecture for .NET versus the architecture for .NET Framework is that lots of things were split off into their own little NuGet packages. "Little" is the wrong word, I’m sorry. "Little" as in scale of functionality, not scale of effort required to create them. And so you’ll probably… what you’ll find is most of the common namespaces in c# and .NET… rather than .NET because… yeah i’ve confused everything by saying that. But let’s just ignore what—I said there.

Jamie : [0:06:27] A lot of the smaller namespaces in .NET have been packaged up as their own packages and ASP .NET Core is a pack… well it isn’t a pack… i’m getting really pedantic now, i’m sorry everyone. it’s not a package it is a meta package. So it is a package of packages, and so you’ve been using NuGet, perhaps, without even realising.

Scott : [0:06:48] Yeah, so there are a lot of features about NuGet packages. So now we’re leaning in to get a little bit more advanced here. There’s some features that a lot of people might not be aware of, but if you make NuGet packages, it’s to your benefit to learn that these features exist and to figure out how to implement them in your own projects. So these are some of the topics that—I put in the pull request that—I put on one of Jamie’s NuGet packages, and we’re going to kind of talk through that. But before we jump there,—I just wanted to point out that the NuGet website, has a really useful column on the right side of the page. If you go to any NuGet package website, page on NuGet.org on the right side it lets you download the package but it also has a few other pieces of information. It might link to the source repository, it might link to the license, and there is a button, right now, that says, "open in NuGet package explorer." Jamie have you ever used this on the website?

Jamie : [0:07:42]—I have not.—I have not. in fact I’m actually going to open it now for one of my packages; do it live right.

Scott : [0:07:48] Okay.

Jamie : [0:07:48] Let’s see what happens.

Scott : [0:07:49] Yeah just for the for the listeners which package are we going to.. .

Jamie : [0:07:53] Oh, yeah, yeah. Io i’m looking at my OWASP Headers.Core package. It’s loaded a bunch of wasm, so web assembly. Oh my goodness it’s Uno Platform. That is awesome. So it’s running .NET in my browser. That’s awesome.

Scott : [0:08:06] So yeah this is really cool. This is a fancy file browser that lets you view the contents of that zip folder that that makes the nuget package. So you can actually poke through the package. And we’ll go in a little detail in a minute. But although this web app is absolutely fantastic,—I do want to point out that there’s a companion desktop app. It doesn’t come with Visual Studio right now. You just have to install it manually.—I think it’s a .NET tool. I’m sure you can find it. It’s the NuGet Package Explorer for the desktop. But the advantage of having it on your computer is you can open these files locally. And it makes it really convenient to poke through and make sure they’re built correctly. And you can also edit the fields, which is just really, really convenient. So yeah.

Scott : [0:08:49] So let’s poke through here.—I want to mention a couple of the things. There are a lot of features in here. We’re not going to go through all of them. But—I will point out that before you install a NuGet package, if you’re really security conscious, you can kind of pop open these folders and get an idea of what’s going to be copied to your system just from this package. Now, this doesn’t show you the contents of all of the dependency packages. That’s kind of its own thing. But this lets you really quickly, poke through what’s in a NuGet package. And one of the things—I want to call your attention to is on the left side of the screen, and this is probably open on Jamie’s website right now, there is a health section. And on Jamie’s page, it has some red Xs.

Jamie : [0:09:30] Yeah. Oh, my goodness. I’m terrible at contributing towards open-source.

Scott : [0:09:34] No, it’s okay. So a lot of these features are new features that probably weren’t there when you first made your package. But I’d like to just briefly talk through what each of these are and talk about how to fix them. So before jumping into the complexity of those red Xs, let’s just take a little step back and talk about how to edit what appears in a NuGet package. Because it might be a little bit confusing for someone who’s brand new. You type dotnet pack and a new package file comes up. Where does it get all of its information? And the answer is, or at least the modern answer, because this changes sometimes between .NET framework and .NET Core, But the modern .NET answer for where it gets its information is the csproj file.

Scott : [0:10:15] So your modern project will have a csproj file. And if you define certain elements in there, they will automatically be consumed when it builds the NuGet package. And—I highly recommend there’s a website that’s sort of like the modern best practices for building NuGet packages. A lot of my suggestions today are going to come from that. But you can just kind of step through that website item by item and make sure that your csproj has all those things. But we’re going to talk about the big ones today.

Scott : [0:10:43] So let’s dive right in. So—I can tell from the package explorer on this package that you have bundled a license file with your package. And the root directory of the package is license.txt. And—I can see from line one that it’s an MIT license. Now, I’m not going to read every word. Now, I’m not going to use a file differ, but I’ve got to kind of assume that this is an MIT license. And without actually reading it word for word,—I can’t really know. And it makes sense if you have a custom license to include your license.txt in your package. But the modern best practice, if you’re going to use a standard license, you can use what’s called a license expression. So if you edit your csproj file,—I think originally you had a license file. You can remove that and you can add an element that’s PackageLicenseExpression. And most people will just need to add MIT or GPL or Apache 2. You can just add those few words there. And—I think licenses.nuget.org has a list of what’s available. But all the common ones are available, and you can just stick your license right there. And then the advantage if you do that is that when you go to the package website on NuGet, instead of saying, "click here for the license file," it’ll actually say, "MIT license." So you don’t have to do a bunch of reading and try to figure out what license is. It just, you know immediately what it is. The license expression. Oh yeah, go ahead.

Jamie : [0:12:06] Just real quick to your point there, Scott,—I could include a file that is license.txt and it looks like it’s the MIT license, but actually there could be, like you said, you’re not going to get a diff out and actually check it. There could be something in there that is like, you know, "disregard everything that we’ve said above. This is now actually a Jamie-2024 license that says if you install this you owe me five hundred thousand dollars."

Scott : [0:12:33] Yes, yes. So that is a concern that is just totally eliminated if you use license expression. So i’m not going to go into it here, but—I will say that the license expression, although most people just put a single word in there, it’s actually a little language. It’s called a SPDX format. There’s this whole specification. It’s almost like a SQL statement. You can have ands and ors and parentheses. So you can have like "MIT and," and then the whole thing in parentheses, "(LGPL or BSD3)". So it gets complicated, but—I just wanted to say that, hey, you can switch to a license expression and that’ll be an improvement for modern packages.

Scott : [0:13:15] So the next thing—I want to point out is one that you’ve already done, which is fantastic to see. But a lot of older projects don’t have this. And it seems so simple now because we kind of take it for granted. But that’s to add a readme. And this readme file is not meant to be consumed in a text editor. But rather, it’s the content of the web page that will be displayed to the user when they go to your packages page on NuGet. So when we go to your packages page on NuGet, we see the information about it. Here’s a quick start. Here’s some code. All of that is fantastic. And back in the day, that didn’t exist. You’d go to someone’s NuGet package page. It would just be blank. You’d have a name and that’s it. Maybe if you were lucky, you’d have a link to their website and you’d have to read their website to figure out what the project did. So, yeah, so people can search the internet for how to add this package-readme file, but there’s a PackageReadmeFile element that you include in your csproj file, and you also have to add a line that tells NuGet to bundle that text file with the package. So yeah, so you’ve already got that checkbox marked with the readme, so you’re doing well there.

Jamie : [0:14:22] Okay, 1 and 0.

Scott : [0:14:23] Yeah, you’re doing it so far. Okay, so the next pair—I kind of think of together,—I highly recommend doing. And they are two elements that you can add to your csproj file. One of them is PackageProjectUrl, and the other one is RepositoryUrl. So both of these help connect the person who made the NuGet package with where the consumer can learn more about it. Because if—I just go to your… currently, because right now your package doesn’t have these, if—I just go to your NuGet page, it’s not actually trivial for me to figure out where the source code lives. Luckily, you have a readme. If you didn’t have a readme,—I would have nothing. But you have a readme, and halfway down the page, there’s a link to your GitHub project. And that’s how—I can figure out, "oh, this is where the source code lives."

Scott : [0:15:11] On the other hand, if you just added that RepositoryUrl, then the source code would have a link on the right head of the page right next to where the license info is, and you could just go straight to the source code. The PackageProjectUrl is good if you have a website which is separate from the source code. So in my case, for Scott Plot, for example, my RepositoryUrl goes to GitHub/Scott Plot, but the PackageProjectUrl goes to scottplot.net where you can get the documentation and all that type of thing. So yeah, those are two more things—I recommend adding.

Scott : [0:15:45] So there’s, okay, let’s talk about the three red X’s now that showed up on yours. And they’re going to be a little bit less fun. And then we’ll come back at the very end and we’ll talk about the fun one. So, okay, the three red X’s. And it’s sort of like if you fill out all three, you get a bonus. These all three kind of work together to do some magical stuff.

Scott : [0:16:07] So the gist is that by having these checked, it slightly enhances the credibility and security of your package, but it also makes it much easier for your consumers to use debugging tools as they’re using your package. So the first one is to create debug symbols. So some people might be familiar with debug symbols. They kind of give more information about pieces of the code, especially like function signatures and that type of thing. So if part of the code blows up, the user has a little bit more useful information that might help the original maintainer figure out how to debug this thing. So enabling or including debug symbols, there’s an element IncludeSymbols, and also in SymbolPackageFormat—we’re not going to talk about the nuance of those, but we can just include them—and make the format snupkg. If you add those two lines to your csproj file, then every time you build your NuGet project, you won’t just get a dot .nupkg, you’ll also get a .snupkg. And if you publish your projects to NuGet using the console or using the command line, they automatically send the symbols to NuGet. If you’re using the browser, you have to manually upload the symbols. But if the symbols are there, then they’ll show up on the right side of that page on your website or on the NuGet website.

Scott : [0:17:32] But the cool thing about having the symbols there is if you use an IDE like Visual Studio and you’re consuming someone’s NuGet package, and some function blows up, it gives you more useful debug information about exactly where the issue is. And the really, really cool thing is that if you, connected your project with a Git repository, it’s smart enough to kind of wire that together. And it says, "well, OK,—I know the file that blew up. And—I know the function name or the function information. And—I have the URL for the Git repository," IDEs like Visual Studio are actually smart enough to let you jump right into the source code. This also works for F12. So in Visual Studio, you can use F12 to jump inside of a function. It is the coolest thing ever that now we can if we enable this right combination of things we can enable a feature called source link that when you press F12 it lets you jump, not just into the functions of your own code, but you can jump into the source code of a NuGet project that you’re using.

Scott : [0:18:32] It is so helpful because half the time, you know, if—I need to do this half the time I’m just calling a function wrong because I’m misunderstanding what the function is actually doing and by looking at the source code—I can figure it out; and the other half maybe the function was written wrong and it’s a project that—I maintain. Now my users, just with F12, can immediately see where it’s blowing up. And if it’s something wrong with my code, they can very quickly create a pull request that lets them fix it without having to download all the source code and do all the debugging on their end. So if you enable all these check marks, it’s sort of like the win that you get is source link, and it makes it really easy for consumers to jump through your source code in their IDE. So it’s pretty cool.

Jamie : [0:19:11] And that’s all from that, what did we say? It was the snupkg file, right? That’s just taking those debug symbols, packaging them up, and then allowing the debugger at the other end, on the consumer end, to actually do that for us, right?

Scott : [0:19:28] I’ll say yes, but with a star. The star is that we also have to enable the next thing, which is called deterministic builds and continuous integration builds. We’ll talk about that in a second. You have to have kind of the magic combination of elements in here. And also, you have to be on a modern .NET platform. So starting with .NET 8,—I think these source link features just automatically become available if you have the right elements in your csproj file. But if you have an older project, you can still use all these features. Even if you’re on .NET Framework, you just have to install the source link NuGet package. And it truly is as easy as just installing the SourceLink.GitHub or whatever it is, NuGet package, and the installation process kind of wires it up for you. And—I know this because—I have packages in production that use SourceLink and multi-target builds for .NET Framework and .NET 6 and .NET 8. So it is getting easier in the future, but just because it’s easier for new projects doesn’t mean it’s not possible for old projects. My understanding is right now this works across the board. So this is a really neat feature to enable in your projects.

Jamie : [0:20:30] Nice. Because—I do know that, because—I use Rider a lot,—I do know that Rider can kind of do this a little, you know. Like if you if you F12 on something that is not your code, that is included in some kind of nuget package, it can try and do the same thing. It does a whole bunch of stuff where it downloads the nuget package from source, tries to figure out where you are and what you’re doing. So i’m thinking that behind the scenes they’re probably doing something similar to this: they’re trying to get that information for you.—I don’t know whether that’s how that works or not,—I just know that that is a thing. But it’s really cool that there is a way to do it for non-Rider users, right; for people who are using Visual Studio.

Jamie : [0:21:12] Because, you know, i’m not…—I am very much a case of, similar to,—I think it’s Scott Hanselman who says, "use what you like. Use what works for you. Use what makes you happy." So some people want to write .NET with Rider, some people want to write .NET with Visual Studio, some people want to use Visual Studio Code.—I know at least one person who’s using neovim, and that’s all totally cool. Whatever works for you. You can totally do programming in hard mode; that’s totally fine.

Jamie : [0:21:39] But, like,—I love this ability to be able to take a nuget package that i’m consuming and hit f12, and be able to actually dive in and say, "oh right. No—I get it. Yep, i’m doing this wrong, because I’ve made this misunderstanding.—I get it now." And then you can fix your own code, right?

Scott : [0:21:57] Yeah and—I assume by the time this episode airs, these things will be fixed and we can see this in your package. But in the meantime, I’m just looking at one of the Scott Plot packages. But in the NuGet package explorer, on the left side of the screen where it shows all the information, if you have SourceLink connected, it’ll show you your repository URL and the git commit hash. And my understanding is that’s how it kind of just wires everything together. Because if you know from the debug symbols where the code is and you know from the Git URL and the hash, you can kind of wire everything together behind the scenes.

Jamie : [0:22:31] Right. That’s really cool. Yeah.

Scott : [0:22:34] So that last magic element you need is if you’re on a modern .NET platform. Well, actually, in all platforms, you need something called a ContinuousIntegrationBuild. And you need to be set to true. And all it does is it forces your csproj file to not contain absolute file paths. It forces everything to be relative file paths to make sure that your build could happen purely from the source code repository. So if you set that to true, that’s one of the requirements. Older .NET projects also need the Deterministic element to be set to true. Older .NET projects, if you recompile multiple times, the DLL will have a slightly different hash. Well,—I guess a very different hash, but the DLL will be slightly different enough to totally change the hash, and you have to enable the deterministic build for it to be bit-for-bit the exact same binary every time. So that’s the last kind of magical piece of this puzzle that lets this work.

Jamie : [0:23:30] Nice. And that’s, like—I mean… we’ll get on to it in a moment because you’ve very graciously provided a PR that that pulls all of this stuff in.—I mean what you’ve said is, "add a couple of things to the csproj file and magic happens. And it does it all for you," right. Is that literally what you’ve done? Like because—I still…

Scott : [0:23:51] It’s that easy, yeah.

Jamie : [0:23:52] Great. So for listeners—I still, whether you believe me or not,—I haven’t opened the PR yet.—I don’t know if this is what… Scott could have wiped out all the code.—I don’t know, but I’m sure that you haven’t.

Scott : [0:24:05] You can look at the PR if you want. The whole thing is maybe 10 lines of changed code and one more feature that we haven’t talked about yet. But the only code change is the csproj file. That’s all I’m doing. And you’ll get all these new features, presumably just by merging it in.

Jamie : [0:24:20] Right, okay. Well, we’ll have a look at that in a moment. But yeah, let’s talk about this other feature that you want to talk about.

Scott : [0:24:25] Okay, so we will close on this one. And this is,—I won’t say it’s a best practice, but—I would say do it because it’s fun and it’s an opportunity to do something that is more than code. And that’s just pick an icon. Like pick an icon and apply it to your project. Because when you search for, in your case, OWASP, I’m sure there are a million OWASP things. And if you know exactly what you’re looking for, it is so convenient to just immediately have that brand recognition. or—I recognise this author or—I recognise this person or this package. And the logo, if you add an icon file, it’s pretty easy to do. You just add two lines that you add to your csproj file, one to include the icon file. It’s just a PNG file.—I think it’s 128 by 128. And another line just to say that, "hey, use this icon, this package icon." That’s all it takes to add an icon. And it’s not just visible on the NuGet page. It’s visible from within your IDE. So if you use Visual Studio and manage packages. You’ll be able to see your icon there. And they support your transparency, too. So if you have the opportunity to add an icon, go for it.

Scott : [0:25:35] So in this case, it’s like, well, okay, what icon do we use? A lot of developers are like, "I’m a programmer. I’m not a graphic designer." But—I just want to encourage everyone. It doesn’t matter. First of all, no one’s downloading your NuGet package because you’re a graphic designer. Some of the most popular NuGet packages have really, really, really simple icons. And I’m not going to call any by name but it’s kind of a joke where a lot of people make a really simple one-off icon when their project gets small and they kind of feel like they can never change it later because the project got big, so you have a lot of really great projects with really simple icons, so don’t be intimidated by that.

Scott : [0:26:11] The other thing is this pull request—I just went ahead and made an icon for you we can change it I’m not going to commit you Jamie to using this icon but I’ll talk through the process that—I used to make it just because—I thought it was kind of interesting, and hopefully it’ll kind of lower the intimidation factor for some people who might be listening who don’t consider themselves graphic designers.

Scott : [0:26:31] So what—I did was, and again,—I don’t know that much about your package.—I don’t do a lot of API .NET stuff.—I do some, but—I have not used your package before. So rather than do a deep dive, trying to figure out the details,—I just took your readme and—I gave it to ChatGPT and—I said, "generate an icon for this NuGet package." And—I gave it the one-liner. And it gave me a logo. And what’s funny is—I post these on the pull request too, so you can kind of see my thought process. It gave me a logo that kind of looked like a shield in a browser window. And it’s like, okay, that’s cool. But—I said, "ok, make it simpler. And it gave me a simpler version." And the gist is like, "oh,—I kind of like this idea. It’s a shield which conveys security. And there’s like a browser window which communicates HTTP. But then it had this letter H where kind of like a logo would be."

Scott : [0:27:21] So—I thought about it, and—I looked at the official OWASP logo, and it’s a WASP. But also, legally,—I looked at their licensing. You’re not supposed to use it unless you’re official and all this stuff. So it’s like, okay,—I want a WASP, but—I don’t want their WASP. So—I just went on Google Image Search and found some WASPs, and—I found two versions of WASPs—I liked. So—I used Inkscape just to make a line drawing that was kind of a hybrid between these two designs. And then—I got that WASP, and—I just stuck it inside the shield. So the whole thing only took a few minutes.—I made a logo. It’s fine. Like, it’s probably not going to win any awards, but it is so much better than no logo in many cases. And yeah, so—I made it as an SVG, so it scales to any size.—I exported it as a 128 by 128 PNG, and—I just edited the csproj file to say, "hey, include this icon in the package," and now it’ll show up in your package listing whenever you use it on NuGet.

A Request To You All

If you're enjoying this show, would you mind sharing it with a colleague? Check your podcatcher for a link to show notes, which has an embedded player within it and a transcription and all that stuff, and share that link with them. I'd really appreciate it if you could indeed share the show.

But if you'd like other ways to support it, you could:

  • Leave a rating or review on your podcatcher of choice
  • Consider buying the show a coffee
    • The BuyMeACoffee link is available on each episode's show notes page
    • This is a one-off financial support option
  • Become a patron
    • This is a monthly subscription-based financial support option
    • And a link to that is included on each episode's show notes page as well

I would love it if you would share the show with a friend or colleague or leave a rating or review. The other options are completely up to you, and are not required at all to continue enjoying the show.

Anyway, let's get back to it.

Jamie : [0:28:14] Yeah. Nice, let’s take a look, then. So I’m going to take a look, then.

Scott : [0:28:17] Oh, you haven’t seen it yet?

Jamie : [0:28:18] Okay. Not seeing it yet. I’m going to have a look. So, yeah,—I can see where… Yeah, so—I believe the PR will always be there, because that’s how PRs work. Like you said, it will likely be closed and merged way before this comes out. But—I can see the process. Oh, yeah, yeah,—I can see that. Oh, okay, right. Scott,—I got to say, this is a fantastic logo.

Scott : [0:28:41] Right, it’s actually really good.

Jamie : [0:28:42] Yeah, right?

Scott : [0:28:44] It communicates. It’s so simple. It communicates the things. It communicates security, browser, and the WASP.

Jamie : [0:28:51] Yep,—I love it.

Scott : [0:28:53] So, you know, I’m not here saying I’m some great designer. I’m just trying to encourage the listeners. "Hey, if you feel like you’re a programmer more than a designer, it’s okay. You can put something together that passes the bar. And if your project gets a million dollars in the future, maybe you can hire a professional designer to make it nicer." But don’t be intimidated by what it takes to make a logo.

Jamie : [0:29:13] Or you can hire Scott to do one for you.

Scott : [0:29:16] Or that. And actually, okay, on that note,—I will say the things that we talked about, just improving people’s NuGet packages, adding a link to the Git repo, adding a link to their website, adding an icon. None of these contributions are hard. And—I bet so many maintainers with older projects would love to have a user contribute these improvements for them. So if someone’s a little bit newer to open-source, doesn’t really know how to get started, maybe they’re intimidated by the actual code. A lot of these improvements can be made by people who are just getting their feet wet contributing to open-source. And also, it’s October. We’re in the thick of Hacktoberfest.—I know some people are into that. These type of code contributions are just unique. And—I bet a lot of maintainers would really benefit from having pull requests like this show up in their inbox. And even if they don’t merge it, even if they don’t like the logo exactly, it can start a conversation that can lead to possibly something that might be a better fit for the project. But yeah, either way, this isn’t just for maintainers. Contributors can do this stuff too. So yeah, I’m glad you like it.

Jamie : [0:30:19] Nice. Yeah, it’s awesome.

Jamie : [0:30:20]—I have to say, Scott, this is awesome.—I love the logo that you’ve created.—I love the, like reading through PRs. It’s often quite non-trivial to write a good PR. "These are the changes I’ve made. This is why. This is…" that kind of thing. But like reading through your PR it’s really clear what you’re doing, and what you’re suggesting, and the changes that you’ve made, and the rationale for why. And like—I said—I really appreciate the the inclusion of, "how did we make the the icon?" and obviously talking through it on the recording as well. Because then, like you know, for people who maybe come… like it could be that at some point in the future someone creates a logo that looks similar to this and then they try and get me in trouble for using a logo which looks similar to this. But actually,—I can then point to this PR and say, "actually, I’m taking it on good faith that Scott created this using the process that he wrote in this PR. And so therefore, it existed before this copyright claim came about." There’s my proof, right?

Scott : [0:31:24] Yeah. And in fairness, that’s why—I think it’s really useful just to have some kind of basic skills using some type of vector graphics editor. A lot of people use Illustrator.—I use Inkscape. Inkscape is totally free. It takes a little time to learn how to use it, but once you know how to use it, it’s such a great tool. Because in this case, both of my kind of inspiration images were free to use for personal use, but not for corporate use, without attribution. And it gets prickly if you can use a picture, but you have to include files. On the other hand, if you can kind of get inspired by what you find on the internet, and then just sling your own design using free tools that you have, and then you know you just on the rights to it, it’s a really liberating feeling. So it’s a great tool to have. But yeah i’m glad you like it.

Jamie : [0:32:07] Awesome. Yeah, yeah. I’ll put a link in the in the show notes folks, for you to come and check this PR out. It’s PR number 96. Also how did—I get to 96 pull requests?

Scott : [0:32:18] One million users that’s how you do it.

Jamie : [0:32:21] Well, specifically this is because—I work with pull requests. So like, personal opinion,—I if i’m work… even if it’s one of my own repos, even for the repos for the website for this show—hey folks this show is built from source, the website for it is built from a, it’s, a, i’m not going to tell you what—but it is built from source.—I create a pull request for each episode and then merge the pull request in. So, you know,—I end up with, at this point, OWASP Headers.Core on October 19th has 96 pull requests, because that’s how—I work. But that’s that’s just how—I work; everybody works differently.

Jamie : [0:32:59] No, that’s really cool.

Scott : [0:33:02] Hey, Jamie,—I really enjoyed the discussion. We’ve, we’ve had a long one here. We covered a lot of ground. But yeah, I’m, I’m happy we got to have this chat today. And hopefully you learn some stuff.—I know—I learned some stuff by putting this together, and hopefully the listeners learn some stuff along the way as well.

Jamie : [0:33:19] Oh, absolutely.—I certainly have learned a whole bunch of stuff and, it’s been an absolute pleasure talking with you, Scott. It always is.—I really appreciate it. And—I appreciate you coming on the show.

Jamie : [0:33:29] So I’m going to give you like as much time as you’d like to sort of do some, sometimes call them like selfish or whatever, shout outs. But yeah, tell the folks how to get in touch with you, or how to learn more about you, or about ScottPlot and things like that, right? Because—I know that you’ve kind of mentioned it a few times, but we didn’t really get a chance to talk about it. I’d love to, if you’re, and I’m doing this in the recording, folks, this will not be edited out. If you’re interested, Scott, I’d love to talk in the future about ScottPlot, but we could totally cut this.—I know—I just said I’m not going to cut it, but we could totally cut this in.

Scott : [0:34:05] All right, you put me on the spot now. No,—I would love to talk about ScottPlot. That has been a fantastic journey. I’ve learned a lot along the way and have some cool stories. So yeah, I’d be happy to talk about ScottPlot in the future.

Scott : [0:34:16] So yeah, closing us out here, thank you for being here. By the way, if you enjoy the show, buy Jamie a coffee. My name is Scott Harden, and my personal website is swharden.com. If you search the internet, you can find me pretty easily. For anyone who is interested in the medical stuff, my About page has a section at the bottom. It’s kind of hidden these days, but you can actually follow my medical situation. So you can see what stuff was like in the past. And if things ever change in the future, that’s where I’m going to share updates. So that’s been pretty interesting.

Scott : [0:34:47] I’m easy to find on GitHub and actually LinkedIn. So—I mentioned on the last episode, and again, if people haven’t listened to that last episode, but they kind of like the discussion here. There’s a lot more of it in the previous one. I’d recommend listening to it. But like—I said on the last episode, if people have had career changes, so—I guess we didn’t talk about it in this episode, but—I am not a full-time software developer. I’m a dentist and right now—I work as a neuroscientist in a research laboratory. But if there are other people who have had kind of interesting journeys that led them into software development,—I would love to connect and learn more about their stories and vice versa. So feel free to reach out to me on LinkedIn, connect with me and just mention that you heard me on the show. I’d be loved.—I would love to hear more about your story and meet other people who’ve had interesting career paths as well.

Scott : [0:35:32] But yeah. And then ScottPlot, you can find more just scottplot.net. And there’s a Discord. You can find it from the website. It’s a pretty interesting community got going on over there.

Scott : [0:35:41] So, but yeah, all together, Jamie, it’s been a pleasure. Thank you so much for having me.

Jamie : [0:35:45] It has been a pleasure. Absolutely, Scott. And I’m always so appreciative getting to spend time chatting with you because you are a super interesting guy,—I have to say. And it’s always really loads of fun just talking to you because no matter what we talk about,—I walk away going, "I learned a whole bunch of stuff there."

Scott : [0:36:07] Well, that’s a sign of a great conversation. So I’m glad we got to share it today, for sure.

Jamie : [0:36:12] Yeah, thank you ever so much. Sidebar: one of the notes that—I have from a conversation we had before was,—I talked to you about colour space. And—I also talked to you slightly before this call about colour space and then embarrassed myself because—I didn’t know something about you. So relating to colour.

Scott : [0:36:31]—I am very, okay. Yeah.—I actually, if you Google,—I don’t know what the exact phrase is. You’ll find someone wrote in a nature, an article that published in nature, which is kind of a prestigious scientific journal. It’s, I’m not an author.—I was just quoted in there. But it’s about the use of colour in scientific figures and in data visualisation. And the reason—I am so passionate about this topic is because—I am colour blind.—I have a really hard time distinguishing reds from blacks and greens. So the topic of colour and data visualisation is really close to my heart. So I’ll close with that.

Jamie : [0:37:04] There we go. Excellent. Thank you ever so much, Scott.—I really appreciate it.

Scott : [0:37:09] Yeah, you bet. It’s been a great time.

Wrapping Up

Thank you for listening to this episode of The Modern .NET Show with me, Jamie Taylor. I’d like to thank this episode’s guest for graciously sharing their time, expertise, and knowledge.

Be sure to check out the show notes for a bunch of links to some of the stuff that we covered, and full transcription of the interview. The show notes, as always, can be found at the podcast's website, and there will be a link directly to them in your podcatcher.

And don’t forget to spread the word, leave a rating or review on your podcatcher of choice—head over to dotnetcore.show/review for ways to do that—reach out via our contact page, or join our discord server at dotnetcore.show/discord—all of which are linked in the show notes.

But above all,—I hope you have a fantastic rest of your day, and—I hope that I’ll see you again, next time for more .NET goodness.

I will see you again real soon. See you later folks.

Follow the show

You can find the show on any of these places