Before we start I just want to preface this with some  warnings

• This works for me, it might not work for you
• To get this working for you, you may need to tweak some of the code referenced
• This is not under any support or warranty by anyone
• Running Nuget.exe update command outside of Visual Studio will overwrite your files so there is a manual review process (more info below)
• This is only for ASP.NET Framework using packages.config – Yes I know that is super old and I should get with the times, but this has been an ongoing behind the scenes project of mine for a long time. When I need this for Package Reference projects, ASP.NET Core/5, I’ll update it but there’s nothing stopping you from tweaking this to work for you
• This only works for a specified csproj, not an entire sln – it could work for that but I’ve not tested, there would be a few tweaks to make that work
• This does not yet work for GitHub actions but the concepts are all here and could probably very easily be converted UPDATE: This works now!

Now that’s out of the way …

How do I do it?

With a lot of PowerShell :) This also uses a few methods from the PowerShellForGitHub project.

The process is:

• Run a pipeline/action on a schedule (i.e. each day)
• This checks against your source code for the installed version for a particular package
• Then it checks with Nuget (using your Nuget.config file) to see what the latest stable version is
• If there’s a newer version:
• Create a new branch
• Run a Nuget update against your project
• Build the project
• Commit the changes
• Push the changes
• Create a PR for review

Azure Pipelines/GitHub Actions YAML

The only part of the YAML that needs editing is the variables, here's what they mean:

• ProjectFile = The relative path to your csproj that you want to upgrade
• PackageFile = The relative path to your packages.config file for this project
• PackageName = The Nuget package name you want upgraded
• GitBotUser = The name used for the Git commits
• GitBotEmail = The email used for the Git commits

For Azure Pipelines, these are also required:

• GitHubOwner = The repository owner (i.e. https://github.com/Shazwazza/Articulate )
• GitHubRepository = The repository name (i.e. https://github.com/Shazwazza/Articulate )
• There is one Secret setting you need to create in Azure Pipelines: GitHubAccessToken which is a GitHub PAT that you need to create that has access to this repository.

Then there are some variables to assist with testing:

• DisableUpgradeStep = If true will just check if there’s an upgrade available and exit
• DisableCommit = If true will run the upgrade and will exit after that (no commit, push or PR)
• DisablePush = If true will run the upgrade + commit and will exit after that (no push or PR)
• DisablePullRequest = If true will run the upgrade + commit + push and will exit after that (no PR)

Each step in the yaml build more or less either calls Git commands or PowerShell functions. The PowerShell functions are loaded as part of a PowerShell Module which is committed to the repository. This module’s functions are auto-loaded by PowerShell because the first step configures the PowerShell environment variable PSModulePath to include the custom path. Once that is in place, all functions exposed by the module are auto-loaded.

In these examples you’ll see that I’m referencing Umbraco Cloud names and that’s because I’m using this on Umbraco Cloud for my own website and the examples are for the UmbracoCms package. But this should in theory work for all packages!

Show me the code

The code for all of this is here in a new GitHub repo and here’s how you use it:

You can copy the folder structure in the repository as-is. Here's an example of what my site's repository folder structure is to make this work (everything except the src folder is in the GitHub repo above):

• [root]
  • auto-upgrader.devops.yml (If you are using Azure Pipelines)
  • .github
    • workflows
      • auto-upgrader.gh.yml (If you are using GitHub Actions)
  • build
    • PowershellModules
      • AutoUpgradeFunctions.psd1
      • AutoUpgradeFunctions.psm1
      • AutoUpgradeFunctions
  • src
    • Shazwazza.Web
      • Shazwazza.Web.csproj
      • packages.config

All of the steps have descriptive display names and it should be reasonably self documenting.

The end result is a PR, here’s one that was generated by this process:

Nuget overwrites

Nuget.exe works differently than Nuget within Visual Studio’s Package Manager Console. All of those special commands like Install-Package, Update-Package, etc… are all PowerShell module commands built into Visual Studio and they are able to work with the context of Visual Studio. This allows those commands to try to be a little smarter when running Nuget updates and also allows the legacy Nuget features like running PowerShell scripts on install/update to run. This script just uses Nuget.exe and it’s less smart especially for these legacy .NET Framework projects. As such, it will just overwrite all files in most cases (it does detect file changes it seems but isn’t always accurate).

With that  warning it is very important to make sure you review the changed files in the PR and revert or adjust any changes you need before applying the PR.

You’ll see a note in the PowerShell script about Nuget overwrites. There are other options that can be used like "Ignore" and "IgnoreAll" but all my tests have showed that for some reason this setting will end up deleting a whole bunch of files so the default overwrite setting is used.

Next steps

Get out there and try it! Would love some feedback on this if/when you get a change to test it.