How to update a NuGet library once the author isn’t available – The Reformed Programmer (2024)

Last Updated: May 28, 2024 | Created: May 27, 2024

I’m writing this article because I have an illness called dementia, which over time degrades a person’s ability to remember, think, and make decisions. This means at some point I won’t be able to build or update my open-source NuGet libraries, so this article shows you how to update my libraries when I’m not available.

I detected that something had changed because it affected my programming, in a bad way! This gave me early detection of my dementia, and the ways to overcome some the loss of me programming skills that dementia had taken away. (See the ENDNOTE dementia and programming section at the end of this article)

But my time is limited, so I have focused on making sure that users can still use my libraries before my dementia stops me from updating my libraries myself. Dementia works differently with each person so I won’t know if I can update my libraries to any new .NET, but I’m pretty sure I will be able to update my libraries to .NET 9, but I can’t say for sure on other years.

The rest of this article tells you which of my libraries need to be updated when Microsoft creates a new .NET version, e.g. .NET 9. While I have 20 NuGets in nuget.org, only seven of the NuGets use a specific .NET version – the others NuGets use NET Standard which doesn’t change.

NOTE: The approaches I describe in this article for updating my libraries also works on any NuGet libraries that aren’t being updated by their author(s).

TL;DR; – Summary of this article

• In this article I use the following names:
  • Library: I refer to the source code of a library with the name “library”.
  • NuGet: I refer to a library that has been turned into an easy-to-use file referred to as a NuGet. https://www.nuget.org is one place which holds NuGets. NuGet are normally managed by your development app, e.g. Visual Studio.
  • .nupkg file: When creating a new NuGet you might have to work with the file ending with .nupkg. Typically you will have to manually move / push a .nupkg file to code that handles NuGets.
• Many of my libraries use the NET Standard versions which will work with any supported .NET version . This means that you don’t have to update these libraries. This section covers this.
• The pros and cons of building libraries that needs a specific .NET version is covers in this section.
• I have seven libraries that use a specific .NET version, e.g. going from .NET 8 to .NET 9 (I call this a “NET-specific library”). These libraries needs to be updated when a new .NET version comes out, and some point I won’t be there to update them. There are two things I have done to make it easier to update:
  • I have made NET-specific libraries easier to update when a new .NET version comes out. This section covers this.
  • Then I detail how you can Clone the library’s code, update the library to a newer .NET version, and create a NuGet version. This section covers this.
• At the end of this article I have a section called ENDNOTE dementia and programming covering my experience of dementia and programming, both good and bad.

NOTE: I use Visual Studio Community to show you how to update a library because that what I use, but I expect other development tools can do this too.

My libraries that don’t need an update when a new .NET version comes out

Libraries that only uses NET Standard NuGets don’t have to be updated when new .NET comes out, e.g. NET 9. NET Standard libraries contains a set of fundamental APIs (commonly referred to as base class library or BCL) that all .NET implementations must implement.

Eight of my libraries uses NET Standard and they typically provide a basic specific feature that can be used anywhere. For instance, the NetCore.AutoRegisterDi library can automatically register your services into the Microsoft NET’s Dependency injection provider – this library has the most downloads at 3.1 million and is the smallest library with ~200 lines of code.

The table below contains the eight libraries using NET Standard with links to the NuGet, documentation and an article which gives you an overview of each library.

The rest of this article covers the libraries that works with a specific .NET version, e.g. .NET 9. These libraries are focused on EF Core and ASP.NET Core applications.

The pros and cons of using full .NET version NuGets

Microsoft releases a new .NET version, e.g. .NET 9, every year. This has allowed Microsoft to add new features and improve performance of .NET applications. These yearly releases have allowed .NET to up to date and very fast. But the downside is if you want to update your application to a new .NET version, then you need to upgrade all the NuGets that uses a NET-specific version, e.g. NET 9.

So, if you can’t get every NuGet for the .NET version you are moving to, then your application might not work!

I have six libraries that uses NET-specific that need updating every year. These libraries are listed below, ordered by the most downloaded version coming first.

Sometimes an older NET-specific NuGet version, e.g. .NET 8, will work for a new application using a higher .NET release, e.g. .NET 9. It depends on whether the new .NET version changes some part of the code that the older NuGet uses. I think most of my .NET 8 libraries will work with .NET 9 because my libraries typically use the basic features, but you can’t be sure it will work! If you have a lot of tests to check everything will work with the older NuGens, then it’s MUCH quicker.

I’m assume that most people will want a new NuGet that supports the new .NET version and rest of the rest of the rest of article shows you how to update a library yourself. But first I talk about how I have changed my libraries so that it much easier to update my libraries.

Making NET-specific libraries easier to update

When I created NET-specific libraries I usually created a NuGet which supported multiple .NET versions, for instance EfCore.TestSupport version 6.0.2 supports .NET 6, 7 and 8. The upside of supporting multiple .NETs is that if I add a new feature or fix a bug, then I can release one NuGet with the features/bug fixes that covers multiple .NETs.

But the downside is that it’s very hard to update to a new .NET release for three reasons:

1. You can’t use the Microsoft Visual Studio’s “NuGet Package Manager” features to update a library. Instead you must manually edit all the .csproj files in the library code. I have been doing this for years and it’s a pain to do.
2. It’s harder to find / update NuGets with a vulnerability. I found this when .NET 8 had a vulnerability in the System.Data.SqlClient. I had to go through my libraries to select the non-vulnerable replacement, including effected NuGets. You also can’t use the GitHub’s useful dependabot PRs to fix vulnerability, but you must manually edit the .csproj files.
3. I found it’s harder to find depreciated NuGets because sometimes a NuGet is valid in an older .NET version but is depreciated in the latest .NET version.

To make it easier for me, and you, I changed all my NET-specific libraries to only support one .NET version and fix any vulnerability and removed depreciated NuGets. I applied this to all of my NET-specific libraries and I released new versions of my NET-specific libraries that only support .NET 8.

NOTE: If you are still using .NET version below .NET 8, then the older versions of my libraries are still there for you.

After making my NET-specific libraries simpler to update and cleaner, then the next part shows you how to create a new version of these NuGets if the author (e.g. me!) can’t update the library when another .NET is released.

How to upgrade a NET-specific library to a new .NET version

This (long) section shows how you update a library that hasn’t been updated and the author(s) hasn’t updated to the new .NET version. I only assume you have access to the library’s code, e.g. GitHub, and you have a development application that can edit, compile and test the library’s code, e.g. Visual Studio.

The steps are:

1a. Get the NuGet’s code into your development app

1b. Update the .NET TargetFramework of the library

1c. Update the NuGets

1d. Compile the changed code

1e. Run the unit tests

1f. Update the NuGets information

1g. Create a local .nupkg file

1h. Add a local NuGet source to your application

1a. Get the NuGet’s code into your development app

Nowadays most Microsoft open-source libraries can be found in GitHub, and that’s where my libraries are situated. You usually can find the NuGet’s source code by looking the NuGet via www.nuget.org and clicking the “Source repository” link found on the RHS. Then you need to “Clone” the source code into your Visual Studio app.

Once you have cloned the library, I suggest you compile and run any unit tests before you change anything. This will let you know if something isn’t working, e.g. the unit tests need the database connection string changed to match your setup and give you a set of unit test results to compare with the unit test after you have updated to a new .NET version. See section ??LINK?? if your tests use databases.

1b. Update the .NET TargetFramework of the library

Each CS project contains a file ending in .csproj which holds the version or versions that the project can work with. Because I have tidied-up libraries to only have one version, e.g., .NET 8, which means it’s very easy to change – you just have to update the <TargetFramework> line from the old .NET to the new .NET. This is simple to do via Visual Studio’s “Find and Replace>Place in Files” feature, the screenshot below shows how to change a library using .NET 8 to .NET 9.

Once you have clicked the “Replace All” button then each project will be updated to the new .NET version. At this point Visual Studio will show an error (see screenshot below) because Visual Studio can’t handle this change automatically. Clicking the “Reload projects” normally fixes this, but in some cases I had to close Visual Studio and reopen the library again remove the errors.

1c. Update the NuGets

After the library has been updated to the new .NET, then you need to update all the NuGets in every project in the library. The simplest way to update all the projects’ NuGets is to use Visual Studio’s “Manage NuGets Packages” feature which is found by right-clicking the top “Solution” found in Solution Explorer window. The screenshot below shows the Manage NuGets Packages in Update mode (Note: the screenshot was taken before .NET 9 was released so I turned on “prerelease”, but normally you would have “prerelease” turned off).

The obvious way to update all the NuGets in the library is to select the “Updates” button and tick the “Select all packages” to select all the NuGets to be updated to the latest version. This is it quick and it works, but it’s worth checking that you are using the lowest valid versions of the NuGets in the library – typically the lowest valid version that ends with “0.0”, e.g. 9.0.0. Having higher versions, e.g. 9.0.1, can cause problems if your application has the same NuGet at a lower version (i.e. 9.0.0) but of the same NuGet in the library has. In this case it will show an error saying that NuGet SomeName needs a >= 9.0.1, but your app is using SomeName 9.0.0.

There are a couple of my libraries that have specific versions for some of its NuGets:

• EfCore.TestSupport: When updating my EfCore.TestSupport library you don’t want the highest versions of the xunit.core and xunit.assert NuGets. Thats because when Visual Studio creates a xUnit Test Project it doesn’t use the latest xunit versions. I suggest you create a xUnit Test Project via Visual Studio and find the xunit version it uses, then use the same version in EfCore.TestSupport xunit.core and xunit.assert NuGets.
• AuthPermissions.AspNetCore: the AuthP library uses Microsoft.Graph version 4, not version 5. Therefore you should select Microsoft.Graph 4.54.0, and NOT the latest 5.?.? versions.

1d. Compile the changed code

Once you have changed the library’s .NET version (step 1b) and updated the NuGets (step 1c) then you are ready to compile the code. I recommend you use the Build>Rebuild Solution to compile the code because changing the version and NuGets have a lot of effects.

Normally the code compiles OK, but in some very rare cases the compile fails. In this case it’s likely that the new .NET version has changed, moved (e.g. changing the method’s name) or removed some code features. In this case you need to see what the problems are and decide what to do about it.

WARNING: In my EfCore.TestSupport library I added a feature called EnsureClean which uses code that is not supported by Microsoft (see this section about EnsureClean and why it might fail). If this occurs, I suggest you remove the SqlServer EnsureClean code and use the normal EnsureDeleted / EnsureCreated approach of creating an empty database for a test. (I like EnsureClean because it makes my database tests run quicker than EnsureDeleted / EnsureCreated).

1e. Run the unit tests

All of my NET-specific libraries have a Test project which uses my EfCore.TestSupport library to test the library. You are looking for every test to be passed, but in some cases I have a failing test to say that a feature that doesn’t work (EfCore.SchemaCompare has one of those). That way I suggested you ran the unit tests on the original library in step 1a because you it will show you what a good run looks like.

NOTE: My EfCore.TestSupport library allows you set up a SQLite in-memory database, and a way to set SqlServer and PostgreSQL connections strings – see this documentation on how this.

1f. Update the NuGets information

To define a NuGet there lots of values you need to provide to create a valid NuGet. For most of my libraries there is one project file (.csproj) in the code that contains the setting to create a NuGet file. For instance the EfCore.TestSupport NuGet has the NuGet information in the TestSupport.csproj file. So before you compile the library you need to update three values to create a new version, as shown below.

In the case of the AuthP library, which has multiple projects going into a NuGet, I had to create a dotnet tool called JonPSmith.MultiProjPack, found in nuget.org. This used a file called MultiProjPack.xml in the AuthP and the values you need to change are:

1g. Create a local .nupkg file

All my libraries, apart from AuthP, are designed create a NuGet .nupkg file on every compile. You want to be in “Release” mode when compiling to create a NuGet because it will create a smaller and faster NuGet file (“Debug” NuGets are useful if you want to see debug information from the NuGet).

On compile in “Release” mode the NuGet file will be created in:

…<SolutionName>\<PrimaryProjectName>\bin\Release\<NuGetName>. nupkg

And here is a real example of my EfCore.TestSupport NuGet:

…\EfCore.TestSupport\TestSupport\bin\Release\EfCore.TestSupport.8.0.1.nupkg

In the case of the AuthP library, which has multiple projects to create the NuGet, I created a dotnet tool called JonPSmith.MultiProjPack to create the .nupkg file. The “How to create an AuthPermissions.AspNetCore NuGet package” in the AuthP’s ReadMe file shows how to install and run this dotnet tool.

NOTE: You can read about why I create the JonPSmith.MultiProjPack dotnet tool in the ReadMe of the code.

TIP: I recommend using the NuGet Package Explorer app to check that the NuGet Package you just created has the settings / information that you was expecting.

1h. Add a local NuGet .nupkg file source to your application

The previous step created the NuGet .nupkg file, but to use this file you need to setup Visual Studio’s NuGet Package Manager to handle local .nupkg files. Typically you would get NuGets via the https://www.nuget.org app, but Visual Studio’s NuGet Package Manager has a way to find NuGet from a directory on your development computer.

To use this “local NuGets” feature you need to:

1. Create a directory to hold the local NuGets. My local NuGet directory is called “LocalNuGet” in my user account, i.e. C:\Users\JonPSmith\LocalNuGet.
2. Then you manually copy the new .nupkg file in the Project > bin > Release directory to your local NuGet directory you set up in the last step.
3. You need go into the Options>NuGet Package Manager>Package Sources and add a new source where source is a directory on your development computer – see the screenshot below.

After that you can click on the “Package source” and select the “Local NuGet” you can access to the local NuGet(s) you updated. That allows you to update your application’s NuGets using the normal NuGets via https://www.nuget.org and local NuGets you created yourself on your local computer.

NOTE: In the case of the AuthP library, the MultiProjPack dotnet tool automatically copies the new NuGet to the “{USERPROFILE}\LocalNuGet” directory.

Conclusion

It would be great if all the NET-specific NuGets you use are always updated when a new .NET version comes out, but sometimes they aren’t. That usually means the author(s) should update a NET-specific NuGet and then add it into the https://www.nuget.org application. But in my case, I know that some time I won’t be able update my libraries, which would be a pity for people who use my libraries.

I hope I’ll be able to still do programming for years, but with dementia you just don’t know. That’s why I created this article now while I’m doing well so that you‘re covered if I’m not around. The other reason for me to keep programming is that it helps me to counter dementia’s degrading of my brain – see the ENDNOTE dementia and programming after this conclusion.

One thing I would say is please don’t try to help me by sending me random Pull Requests. Even before I had dementia, I found some Pull Requests with no information, and typically no test results, and it takes me time to work out what the PR does and is it useful. The really good improvements come from someone opening an issue or PR with a conversation with me to work out what is the best way to do this – this PR as an example.

ENDNOTE dementia and programming

It was my programming that alerted me that something had changed. Normally I can hold all of parts of the code in my head, and I would instinctively know where to go and what to do, but in 2022 I found I couldn’t hold the code in my head, which was devastating! It took over a year to get the diagnosis of dementia in Alzheimer’s disease which I got in early 2024. NOTE: Currently there are no known cures for Alzheimer’s.

Once I had the diagnosis there was no one to tell me what this means for me, so I googled “Alzheimer’s disease” and it wasn’t nice, or useful. Thankfully a friend who is a dementia nurse came over and talked about what is happening to me. They didn’t sugar-coat the future, but they said what will happen and what I could do to slow down my decline. Thankfully my programming changing meant that I caught the dementia early (most people are diagnosed in the middle stage of dementia) so had time to work on things.

From my perspective the best suggestion my nurse friend gave me was Cognitive Stimulation Therapy (CST). The core of CST is that you tackle jobs that are hard, but ones you can complete. The typical suggestions to do crossword puzzles, Sudoku, Rubik’s Cube, etc. I do some of these but for me the best CST work is programming! I had to change my approach to programming to counter the dementia’s symptoms, for instance:

• Because dementia affects my memory I have to use lists of the things to do and tick them off when I have done them (I rarely used worklists before).
• Because dementia affects problem-solving I must accept that I will be slower when programming. I was very fast before (so my clients said) but now I’m five times slower or more.
• I also have to handle the frustrations when I can’t do something I could before, or it took longer than before. I have found that trying to something while I’m frustrated will usually fail and I will feel bad. I have to accept my situation and enjoy the things I can do.

A concrete example of how this works can been in this article and the many months of thinking, coding, and writing. I starting my cleaning with my biggest library, AuthP library, which has 20 projects including seven example applications. During cleaning the AuthP library I felt I regained some of programming skills that I had before dementia, for instance I started get back a similar feeling that I could hold “the code is in my head” came back. That was a WONDERFUL feeling to see some of damage from dementia could be rolled back.

But on the other hand I now do need a worklist to help me manage the whole cleanup and update process, which covers many months. And I had to accept that I’m slower at programming, but the good news I that I CAN still code.

While I focused on dementia and programming because my blog is about programming, but I also have lots of other things outside programming, like talking to people to keep my speech up and using apps to make sure I remember things and dates. In fact writing this article is another CST’s “hard, but possible” job, especially as one part of dementia’s symptoms is not remembering words.

Thanks for reading this.