Changes in multi-targeting

[jodydonetti]

Scenario

Some time ago I started enabling multi-targeting on FusionCache: I didn't do that because I needed to special case some parts of the code, but just because I wanted to reduce the amount of explicit dependencies for certain TFMs fater after a request from the community.

But recently community user @nick-randal noticed in #416 that having multi-targeting explicitly towards .NET 6 creates a situation with transitive dependencies where:

• FusionCache explicitly targets .NET 6 (so, it "supports" it)
• FusionCache depends on one or more Microsoft core packages with recent versions (eg: System.Collections.Immutable v9)
• but .NET 6 is not supported anymore (and for a long time)
• those Microsoft core packages does not explicitly target .NET 6, so they do not officially "support" it

This inadvertently created a not so good situation.

Problem

Because of all of that, an app that still targets .NET 6 and references FusionCache now generates warnings like "System.Collections.Immutable 9.0.0 doesn't support net6.0 and has not been tested with it", which is not great.

This happens because FusionCache is saying "I explicitly support .NET 6" but at the same time it also says "I depend on a v9 core package" while the core package itself is saying "I'm NOT explicitly supporting .NET 6".

Add to this that some people turns on the option "warnings as errors", and we can even get a compile time error.

Solution

From now on FusionCache will have explicit targeting only for currently supported TFMs, which today means no more .NET 3.1, .NET 6 or .NET 7, and for them it will have the minimum set of explicit dependencies.

This, for the main FusionCache package, means going from this:

<Project Sdk="Microsoft.NET.Sdk">

	<PropertyGroup>
		<TargetFrameworks>netstandard2.0;netcoreapp3.1;net6.0;net7.0;net8.0</TargetFrameworks>
		<!-- ... -->
  	</PropertyGroup>

	<!-- ... -->

	<ItemGroup>
		<PackageReference Include="Microsoft.Extensions.Caching.Memory" Version="9.0.0" />
	</ItemGroup>

	<ItemGroup Condition="'$(TargetFramework)' == 'netstandard2.0'">
		<PackageReference Include="System.Diagnostics.DiagnosticSource" Version="9.0.0" />
		<PackageReference Include="System.Threading.Tasks.Extensions" Version="4.6.0" />
		<PackageReference Include="System.Collections.Immutable" Version="9.0.0" />
	</ItemGroup>

	<ItemGroup Condition="'$(TargetFramework)' == 'netcoreapp3.1'">
		<PackageReference Include="System.Collections.Immutable" Version="9.0.0" />
		<PackageReference Include="System.Diagnostics.DiagnosticSource" Version="9.0.0" />
	</ItemGroup>

	<ItemGroup Condition="'$(TargetFramework)' == 'net6.0'">
		<PackageReference Include="System.Collections.Immutable" Version="9.0.0" />
	</ItemGroup>

	<ItemGroup Condition="'$(TargetFramework)' == 'net7.0'">
		<PackageReference Include="System.Collections.Immutable" Version="9.0.0" />
	</ItemGroup>

</Project>

which generates this:

to this:

<Project Sdk="Microsoft.NET.Sdk">

	<PropertyGroup>
		<TargetFrameworks>netstandard2.0;net8.0;net9.0</TargetFrameworks>
		<!-- ... -->
	</PropertyGroup>

	<!-- ... -->

	<ItemGroup>
		<PackageReference Include="Microsoft.Extensions.Caching.Memory" Version="9.0.0" />
	</ItemGroup>

	<ItemGroup Condition="'$(TargetFramework)' == 'netstandard2.0'">
		<PackageReference Include="System.Diagnostics.DiagnosticSource" Version="9.0.0" />
		<PackageReference Include="System.Threading.Tasks.Extensions" Version="4.6.0" />
		<PackageReference Include="System.Collections.Immutable" Version="9.0.0" />
	</ItemGroup>

</Project>

which generates this:

Consequences?

But wait: does this mean that those older versions of .NET wil not be able to use FusionCache anymore?

Absolutely not!

Since FusionCache targets .NET Standard 2.0, this means that ANY version of .NET compatible with .NET Standard 2.0 (meaning: all versions) will still be able to use FusionCache, just without an explicit "support statement", since those versions are anyway not supported anymore.

This will ideally remove the problems highlighted above, without reducing the amount of .NET versions that can enjoy using FusionCache.

Thoughts?

Any opinion or suggestion is more than welcome, please share!

[SimonCropp]

IMO targetting netstandard2.0 is misleading. it implies suppot for the following

which i assume is not correct?

[SimonCropp]

given System.Collections.Immutable has min support for net462. you may as well muti-target that

ie it gives a warning for net461

[jodydonetti]

Hi @SimonCropp , it is: FusionCache works on all of those platform, and it is being used on mobile apps, classic framework and all.

The key here probably is "supported", depending on what it means: since .NET Standard transitively expand to all of them, and is the normal way to express "it works with anything compatible with it", I'd say it is correct.

Most libraries and packages (including Microsoft core ones) do target .NET Standard 2.0 precisely for that, without making a "direct statement" about .NET 3.1, .NET 6 and so on.

For example, in the case of Microsoft.Extensions.Caching.Abstractions we can see these targeted:

which in turns means these compatible:

Makes sense?

[jodydonetti]

given System.Collections.Immutable has min support for net462.

Not really "min support" (again, depending on the definition of "support", which is what I'm trying to get a better grasp of here), because by looking here I can see that it also targets .NET Standard 2.0, so transitively it also supports net461, confirmed by this:

Also, regarding classic framework, there's this note:

Thoughts?

[mgravell]

Netstandard2.0 on netfx is ... sort of a hack and a hope. My experience has been that having an explicit netfx target avoids a few binding problems vs people on netfx consuming ns2.0 bits. However! Since you presumably haven't had problems with that in the past, I'm not saying add it. More of a reason not to remove netfx (which doesn't apply since you didn't have it) than to add it. Just context to consider!

Otherwise: looks fine to me!

[jodydonetti]

Netstandard2.0 on netfx is ... sort of a hack and a hope. My experience has been that having an explicit netfx target avoids a few binding problems vs people on netfx consuming ns2.0 bits.

I was thinking about adding that one specifically, just to be sure, but...

However! Since you presumably haven't had problems with that in the past, I'm not saying add it. More of a reason not to remove netfx (which doesn't apply since you didn't have it) than to add it.

... but this: since it's kinda "delicate", and nobody ever complained, I may as well just leave this as it is. So yeah, no change about netfx for now.

Just context to consider!
Otherwise: looks fine to me!

Thanks, really appreciate it!

[mtmk]

+1 looks very sensible to me. I can't see any issues might be caused by this change but I'd say getting people to try it out with a preview release would be enough as a precaution.

[jodydonetti]

+1 looks very sensible to me. I can't see any issues might be caused by this change

Thanks @mtmk

but I'd say getting people to try it out with a preview release would be enough as a precaution.

I was thinking about that, although that would slow down the release.
But oh well, next week I'll be off all week for the MVP Summit, so better to release a preview and see how it goes, instead of getitng out with something official, break something, and having to wait for a week for the next version...

Will update in the next few days for the preview release, thanks all!

[jodydonetti]

Update: sadly I've not been able to publish the preview version, and in a couple of hours I'll be leaving for the MVP Summit.
Will publish that when I'll be back on the next we.

[jodydonetti]

Hi all, v2.2.0-preview-1 is out 🥳