Ensuring .NET 8 versions of system assemblies

Johan Book

Vote:

We've updated our CMS12/Commerce14 solution to .NET 8 more or less by changing the target framework in the csprojs.

I belive we had to bump one or two System.* and Microsoft.* assemblies as well for the compilation to work.

But I notice there are many implicitly referenced System assemblies (that we get via Optimizely nugets and others) that are still on old versions in bin, for example System.Runtime.Caching.dll (which still comes as 5.0, but 8.0 is probably recommended for .NET 8).

How can we make sure we get all the latest and greatest versions of the System.* and Microsoft.* assemblies, that are paired with .NET 8?

The closest I've come to finding out which versions are the latest is by running the command:

dotnet list package --include-transitive --outdated

But I'd like to avoid having to add references to every [transitive] package explicitly just to get the desired version...

#315235

Edited, Jan 07, 2024 19:21

Vincent

Vote:

Hi Johan

In SDK-Style project, NuGet picks a single version to use for each package you depend on, I don't think it's possible to avoid adding direct references if you want to use the desired version unless all top level packages updates their references.

Please share your solution if you have a workaround later.

#315327

Jan 08, 2024 23:58

Johan Book

Vote:

I don't think there's a way around having to explicitly install the transitive deps to be able to select versions.

But luckily, I came across this tool: https://github.com/dotnet-outdated/dotnet-outdated

It makes it a lot less painful to do the upgrade 😅

dotnet outdated -t -td 6 <csproj or sln>

(Will show latest versions of transitive dependencies to a depth of 6)

And if you add the -u:auto switch, it will actually install all those versions in your project, and then you can choose to keep/remove the ones you like.

There is also an interactive mode, using -u:prompt where you will be prompted for every version upgrade.

#315349

Edited, Jan 09, 2024 12:41

vRune4

Vote:

FWIW for those of us not eager to install yet another tool:

The biggest culprit is the outdated version of Castle.Windsor. Azure.Identity and MailKit should also be upgraded.

And once you've done all that, the reward is three fresh compiler warnings:

1>C:\repos\visma\EPiTest\EPiTest.csproj : warning NU1608: Detected package version outside of dependency constraint: EPiServer.CMS.Core 12.20.1 requires Castle.Windsor (>= 5.1.1 && < 6.0.0) but version Castle.Windsor 6.0.0 was resolved.
1>C:\repos\visma\EPiTest\EPiTest.csproj : warning NU1608: Detected package version outside of dependency constraint: EPiServer.CMS.Core 12.20.1 requires Castle.Core (>= 4.4.1 && < 5.0.0) but version Castle.Core 5.1.1 was resolved.
1>C:\repos\visma\EPiTest\EPiTest.csproj : warning NU1608: Detected package version outside of dependency constraint: EPiServer.CMS.Core 12.20.1 requires MailKit (>= 3.0.0 && < 4.0.0) but version MailKit 4.3.0 was resolved.

Incidentally, Castle.Windsor 5.0.0 was released February 12th 2019, almost five years ago. Vulnerable packages can be scary. I was called back to a previous employer because they hadn't upgraded Telerik for a couple of years. The result was total pwnage of their production environment. That included the encryption of quite a few databases.

#315397

Edited, Jan 10, 2024 7:42