Akka.Analyzers can't install in .NET Framework projects using pre-SDK project styles

[lamereactor]

Version Information
Version of Akka.NET? > 1.5.14
Which Akka.NET Modules? Akka

Describe the bug
On a .NET Framework project (4.8 to be exact), when I try to update Akka to a version higher than 1.5.14, I get the error below:

Could not install package 'Akka.Analyzers 0.2.1'. You are trying to install this package into a project that targets '.NETFramework,Version=v4.8', but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author.

The problem seems to come from the addition of the dependency on Akka.Analyzers starting with version 1.5.15.
Ticket akkadotnet/akka.analyzers#66 discusses this, but it has been closed.
Does this mean that Akka is simply no longer compatible with .NET Framework starting from version 1.5.15?

To Reproduce

1. Create a .NET project
2. Install Akka 1.5.14
3. Try to update it to latest version (currently, 1.5.27.1)
4. See error

Expected behavior
Being able to update Akka on a .NET Framework project to version > 1.5.14

Actual behavior
Cannot update Akka on a .NET Framework project to version > 1.5.14

Environment
Windows 10, Visual Studio 2022 17.9.6.

[Aaronontheweb]

Akka.NET is still 100% compatible with .NET Framework (we still target .NET Standard 2.0.) All of our unit tests are dual targeted for .NET Framework 4.8 and .NET 8.

akka.net/src/core/Akka.Cluster.Tests/Akka.Cluster.Tests.csproj

Line 5 in 55827b7

<TargetFrameworks>$(NetFrameworkTestVersion);$(NetTestVersion)</TargetFrameworks>

We closed akkadotnet/akka.analyzers#66 because we added multi-targeting support for many older versions of Roslyn - so that compatibility issue has less to do with the version of .NET being used versus the version of Visual Studio / MSBuild / ultimately, Roslyn being used.

The problem you're running into is that the version of Akka.NET you're installing references Akka.Analyzers v0.2.1, which doesn't include the compatibility fixes we added in akkadotnet/akka.analyzers#66 - those are all available in Akka.Analyzers v0.2.3 and later. So you can fix this by:

1. Upgrading to a later version of Akka.NET that references a newer Akka.Analyzers version
2. Explicitly referencing Akka.Analyzers v0.2.3 or higher.

[lamereactor]

Thanks for your detailed answer.

I created a .NET Framework 4.8 project and tried to install the NuGet package Akka.Analyzers 0.2.5, but I keep getting the error below:

Could not install package 'Akka.Analyzers 0.2.5'. You are trying to install this package into a project that targets '.NETFramework,Version=v4.8', but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author.

Am I missing something?

[Aaronontheweb]

Thanks for your detailed answer.

I created a .NET Framework 4.8 project and tried to install the NuGet package Akka.Analyzers 0.2.5, but I keep getting the error below:

Could not install package 'Akka.Analyzers 0.2.5'. You are trying to install this package into a project that targets '.NETFramework,Version=v4.8', but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author.

Am I missing something?

Try cloning and running any of Akka.NET's test suite with --framework net48

If that doesn't work, then it's the version of your tooling that's the issue. Capture a dump from the about screen in Visual Studio to capture version numbers.

[Aaronontheweb]

So I just tried opening a new .NET 4.7.1 solution in Rider and got the same problem

[Aaronontheweb]

I think this is a more subtle build tooling issue than I originally suspected - apparently it works in our test suite because we're referencing it through a .NET Standard 2.0 project which... semantically, shouldn't be an important distinction. But, here we are.

[Aaronontheweb]

lol the worst part is - Akka.Analyzers is, itself, a .NET Standard 2.0 package 🤯

[Aaronontheweb]

Working on a reproduction here: akkadotnet/akka.analyzers#103

Apparently it's a bug with how we're delivering the NuGet package. A local reference to the Akka.Analyzer's .csproj works fine.

[lamereactor]

That reminds me of DLL hell :-)
Thanks for watching anyway !

[Aaronontheweb]

That reminds me of DLL hell :-) Thanks for watching anyway !

No problem - it's one of those cases where we literally run .NET Framework builds of this package hundreds of times a day, but that works only as a result of some transitive dependencies. When explicitly installing the Analyzer package it doesn't work - so there's some.... MSBuild / DLL hell hackery at work that needs to be fixed.

It's good that we're getting exposed to these types of problems now, rather than when we start leveraging Roslyn for things like code-gen in future versions.

[Aaronontheweb]

Ok, well I found a better explanation for this problem - it's your MSBuild tooling, using the old-style project types that pre-date MSBUILD15

xunit/xunit#2943 (comment)

dotnet/sdk#41352

I'll take a look at what xUnit did to fix this issue and see if we can ape that.

[Aaronontheweb]

After looking at xUnit's fix, I'm not sure I want to do that - moving everyone over to an ancient version of Roslyn because pre-SDK .NET Framework projects don't support the version-specific folders Roslyn uses seems like a step backwards to me.

You can upgrade to using MSBuild 15 without having to migrate framework versions. Please do that and the problem will be resolved. I'll mull whether or not I want to spend the time supporting the pre-.NET SDK MSBuild tooling, but my current lean is "no."

[lamereactor]

Thank you for your deep feedback, and sorry for the late response (summer break).

In my case, Akka is referenced in an ASP.NET Web Application which is not using the SDK-style project format.
I don't know if I'll invest in a migration to the SDK-style project format, as I'm not fully aware of the impacts, and I'm not even sure it's properly supported.
It's probably a sign that it's time to switch to .NET 8 or higher!

I'm closing this issue because I got my explanation, thanks again.

[Aaronontheweb]

@lamereactor

I don't know if I'll invest in a migration to the SDK-style project format, as I'm not fully aware of the impacts, and I'm not even sure it's properly supported.

I believe it should work ok, outside of ASP.NET WebForms.

I'm going to leave this issue open so other users can chime in - I'm open to changing my mind on supporting this so long as there's demand for it.

[kimbyungeun]

We are using .NET Framework 4.7 and are unable to update Akka.NET from version 1.5.13 to the latest version 1.5.28.

"Cannot install the 'Akka.Analyzers 0.2.5' package. You are trying to install this package for a project targeting '.NETFramework,Version=v4.7', but this package does not contain assembly references or content files compatible with this framework. Please contact the package author for more information."

[Aaronontheweb]

@kimbyungeun have you tried migrating your project to the new MSBuild15 format?

[kimbyungeun]

@kimbyungeun have you tried migrating your project to the new MSBuild15 format?

I will convert the entire project to the PackageReference format and try upgrading Akka.NET to version 1.5.28 again.

[Aaronontheweb]

Looks like there isn't going to be an official MSFT tooling solution to this problem any time soon dotnet/sdk#41352 (comment)

[Aaronontheweb]

I put this on Petabridge's Q4 OKRs - we're going to have this fixed before the end of the year.

[Arkatufus]

OK, after observing the installation behavior of both Rider and VS2022, this is the actual problem.

1. Old style .csproj does not support automated package installation. Rider and VS cheats by manually installing the NuGet package and scanning the nuget package directory for dlls, manually adds each dll as a reference inside the .csproj file, and then scans the dependency graph of the .nupkg, installing each one recusively.
2. .nupkg has a very specific folder structure, all library .dll s are put inside the /lib folder, tools/executables are put inside the /tools folder, and analyzer .dll s are put inside the /analyzers folder.
3. For old style .csproj, both Rider and VS does not recognize the /analyzers folder, they do not try to install anything from inside the /analyzers folder (following the old .csproj spec).
4. Since our .nupkg file only contain the /analyzers folder, both Rider and VS automatically categorizes the package as an invalid empty .nupkg file and deletes it from the /packages folder, this causes the error we see in IDE.

[Arkatufus]

The way to fix this is by adding some files inside the /tools folder, this prevents Rider and VS from deleting the installed package from the /packages folder. This will cause the IDE to log this message in the output console:

Adding package 'Akka.Analyzers.0.2.6', which only has tools group, to project 'Akka.Analyzers.NetFxInstallCanary'

The problem is with Rider. In VS, there's a special convention where VS will automatically run any file named install.ps1 if it exists inside the /tools folder. This is how xunit does its installation, it manually installs the analyzer files by calling the VS API from the PowerShell script. Rider does not do this, so while this is a good fix for VS, Rider users will still need to add the <Analyzers> tag manually.

[Arkatufus]

@lamereactor, @kimbyungeun, we just did a beta release for Akka.Analyzers that might fix the problem for you. Can you try and install Akka.Analyzer 0.3.0-beta1 and see if it fixes the issue?