Make project compatible with .NET Standard 2.0 #444
Conversation
|
my problem with .NET Standard 2.0 is that it implies support for several runtime i have no intention of supporting. eg 461 and netcore 2. NET Standard is abandoned by MS and there will not be another one. so continuing to support netstandard seem a wasted effort so given net472 was release 5.5 years ago, isnt that enough of a concession to legacy frameworks? |
|
“Support” is different than “compiles for”, and it doesn’t really hurt anything to compile for an unsupported framework. Many of MS’s nuget packages compile for .NET Standard even though MS only supports newer TFMs. I have various projects that run on unsupported frameworks for various reasons. Sometimes they need to run on old unsupported operating systems. Sometimes the time investment to upgrade to a newer framework isn’t worth it. Some projects are built for Unity or other .NET languages. Check out Meadow for example. Before long .NET 6 will drop out of support, the last version to have System.Drawing supported on Linux. That will be a MAJOR problem for many of my applications. By targeting .NET Standard (with no additional effort) you can allow users to make the decision to upgrade when they are ready to do so. |
|
if it can be consumed on 461 then support is implied. is there a list of target frameworks you want to support (without tagetting net standard) ? |
|
Not specifically. But as an example for GraphQL.NET Server we support and run tests on .NET 4.8, Core 2.1, 3.1, and newer frameworks. (The library just targets .NET Standard 2.0 + Core 3.1 and newer ones as required, so the library should be compatible with 4.61 and other frameworks.) |
|
@SimonCropp I'd suggest taking a look at most of the Microsoft nuget packages currently available. They've always built them for .NET Standard 2.0 and still do, even though official support has long since been dropped. For versions 7.0 and newer, they will issue build warnings for older unsupported frameworks. See here:
Even though the above sample (Microsoft.Extensions.Caching.Memory) is built for all of their supported frameworks, they also built for .NET Standard 2.0, merely adding build warnings when the library is being used with an unsupported framework. But that doesn't mean the code won't run on those frameworks. Sure there's a couple notable exceptions such as Entity Framework and ASP.NET Core which are tied directly to the .NET version they were designed for. I don't know how to configure the packaged nuget file to have this folder structure, but if you're really concerned about someone thinking you're "supported" and old outdated framework, you could configure the package this way. At least it's not leaving people out in the cold. (Personally I'd just put a note in the readme file what's supported and what isn't.) You should also realize that MS has not abandoned older frameworks. Do you realize that Visual Studio 2022 includes build support for not only .NET Core 2.1 and 3.1, but .NET Framework as far back as version 2.0? .NET Framework 2.0 was released 22 years ago and will run on Windows 98 - and we can still build projects for it with a fresh install of VS 2022. Sure the non-LTS .NET Core versions (Core 1.0, 1.1, 2.0, 2.2 and 3.0) were abandoned, but those were never intended to have long-term support anyway.
While perhaps you keep all your software up to date on supported frameworks, I think overall you would find a very small percentage of people do so. Usually it's "if it ain't broke don't fix it", and with any sizable project no owner wants to invest in upgrades that have no perceptible value. As an example, I have one large website built on top of a very large OSS project that uses .NET Core 3.1. Upgrading means paying an experienced developer for probably 1-2 months full-time work. While it's on our wish list, we simply have far too many pressing needs to afford the time to spend on that. I also some small websites that still run on ASP Classic. Perhaps they would only take a couple weeks to rewrite (each), but it's not worth the time; the websites work perfectly as-is. It's all a matter of a cost-benefit analysis and weighing it against risks using unsupported software. That being said, have you had any runtime issues caused by the specific version of the framework the user was using? I'm not asking for any more support, nor any more code here. All of the project dependencies are .NET Standard 2.0 compatible. It just feels like this is a very small ask to build for .NET Standard 2.0, and certainly in line with the majority of the OSS community (in my opinion). Plus, two of the main consumers (based on your readme) -- Shouldy and ApprovalTests -- targets .NET Standard 2.0. |
|
why is continuing to use the older nuget not an option ? |
|
So you think Shouldly should reference an old outdated version of DiffEngine forever more? Seems like a last resort option to me. |
FYI "I can install the build tools" does not equate to "not abandoned". 2.1/3.1/2.0 etc are included just for the situation some poor sod needs to fix a line of code in a decade old system, not for people to do actual work on. Nobody at microsoft supports these versions, nor will respond to any support query about them.
1 month a very long time, is this a .NET CMS (Umbraco)? For the majority of line-of-business applications, upgrading from 3.1 to 5.0/.6.0 is a 1 day upgrade at most. |
|
In this case I’m talking about upgrading the underlying framework that my application is built on. For example, like if my application were built on Unity 5 which runs on .NET 3.1 and in order to use .NET 6 it required Unity 6. (I’ve never used Unity, it’s just an example.) And just FYI, I'm not understating the amount of work. We upgraded once, skipping a version, and it took about a month to upgrade, excluding bug fixes we found over time. That upgrade bumped .NET from 2.1 to 3.1 as the underlying framework. We are now 3 versions behind, so it is likely enough that it will take longer than last time. The current version runs on .NET 7. We probably won't upgrade until they move to .NET 8 later this year, so we are on a LTS version of .NET. Regardless, it's a very expensive investment, and in the interim, all of the libraries we rely on or features we add need to be compatible with .NET 3.1. One of these, for example, is GraphQL. Another is linq2db. Plus many internal libraries we have developed. |
Yes, and in this case I’m asking for this library to be built for .NET Standard, just like MS does for their libraries, not for support, just like how MS isn’t supporting old frameworks. |
|
Are there any benefits to explicitly targeting a .NET version, like specific code paths only accessible with that one or higher? If not then I would think the maintenance burden of supporting NS 2.0 is equivalent to what it is today. By targeting NS 2.0, you're not guaranteeing support for net472 or netcore 2.1, you're just guaranteeing that your code is buildable into a target that NS 2.0 supports. FWIW there's a near-perpetual need for NS 2.0 to remain actually-supported behind the scenes because Visual Studio runs on net472. |
|
sorry. not going to support netstandard2 |
Not in this case. The code compiles perfectly when targeting .NET Standard 2.0 and passes all tests as demonstrated in this PR.
Yup
Exactly
I don't understand this question. Why did you create a new version? To fix bugs or add features obviously. That is why using a newer version is always preferred.
Ok, but I really don't understand this decision. Microsoft recommends .NET Standard 2.0 be targeted for any project that supports both .NET Framework and .NET Core / .NET. Not following MS's recommendation here means that the library cannot be consumed by other projects should as Shouldly which are following MS's recommendation. |
|
2024 Microsoft recommendations:
|
|
in what context are u consuming diffengine? |
|
Indirectly via Shouldly. I test Core 2.1, 3.1, 5.0, 6.0, 7.0, 8.0 plus .NET Framework 4.8. Might drop testing on 5.0 soon. .NET Core 2.1 is particularly important for that project since it uses a different set of underlying APIs than 3.1+ Other projects: https://github.com/Shane32/AsyncResetEvents/blob/master/src/Tests/Tests.csproj https://github.com/graphql-dotnet/graphql-dotnet/blob/master/src/Tests.props |
|
and how many of the consumers of these libs are using net5.0 or lower |
|
I can't say. I just gave references to the ones that I am affiliated with. I certainly can't be the only developer that performs testing to ensure their library works for older platforms as well as current platforms. But that's not the point. In Microsoft's words:
|
|
If you're talking about the libraries themselves, I support multiple production applications running on .NET 5 and lower. I have my own reasons for each scenario. Anything new I build with the latest LTS version, but that doesn't mean I don't have to support older software. I expect other developers are in the same boat. |
This change makes the project compatible with .NET Standard 2.0, which Shouldy and ApprovalTests targets. This change also reduces the size of the nuget download. Note: The only reason .NET 6.0 target exists at all is because I can't figure out how to get PolySharp to exclude generating the ModuleInitializerAttribute.