search

manuelroemer / Nullable

A source code only package which allows you to use .NET's nullable attributes in older target frameworks like .NET Standard 2.0 or the "old" .NET Framework.
https://www.nuget.org/packages/Nullable
MIT License
185 stars 8 forks source link

Make NullableAttributes internal or configurable #30

Closed loop8ack closed 1 month ago

loop8ack commented 1 month ago

Issue Description

The Nullable NuGet package provides attributes necessary for Nullable Reference Types when working with .NET Standard 2.0. However, these attributes are currently declared as public, which leads to conflicts when the .NET Standard 2.0 project is used in a .NET 8 project that already includes these attributes.

Problem Details

  1. The Nullable package adds public attributes for Nullable Reference Types.
  2. These public attributes conflict with the built-in attributes in newer .NET versions (e.g., .NET 8).
  3. Users working with mixed .NET Standard 2.0 and newer .NET projects face compilation errors due to these conflicts.

Proposed Solution

To resolve this issue, I suggest the following changes:

  1. Make the attributes internal by default.
  2. Optionally, add a configuration option to allow users to choose between public and internal visibility for these attributes.

This change would maintain compatibility for projects that need these attributes while preventing conflicts in mixed-version scenarios.

chucker commented 1 month ago

Hm, you may be able to achieve this with NULLABLE_ATTRIBUTES_DISABLE, if you conditionally set that for the modern BCL.

However, I don't recall it being necessary for my uses in the past. The nuspec already doesn't copy the attribute files for .NET 5.

Perhaps you have to dual-target instead of using .NET Standard: instead of <TargetFramework>netstandard2.0</TargetFramework>, use <TargetFrameworks>net472;net8.0</TargetFrameworks>, or similar.

loop8ack commented 1 month ago

Using NULLABLE_ATTRIBUTES_DISABLE wouldn't really solve my issue, as the goal is to actually use these attributes in my .NET Standard 2.0 project. I understand that the nuspec doesn't copy the attribute files for .NET 5+, but the problem occurs when I reference the .NET Standard 2.0 project from a .NET 8 project, which leads to conflicts.

Your suggestion about multi-targeting is indeed a good one and should work as a workaround.

However, I still believe it would be beneficial to make the public vs. internal visibility configurable. This would allow users to resolve such issues with a single setting in the future, providing greater flexibility for various project configurations. I understand that making the attributes internal by default is likely not an option due to potential breaking changes, which is why a configurable option seems ideal.

manuelroemer commented 1 month ago

Hey there! Maybe I am misunderstanding something, but from my point of view, the attributes are already tagged as internal classes to avoid the problem that you describe. In what situation / scenario do they appear as public types in your projects?

loop8ack commented 1 month ago

Good point, I don't have an answer. In my local NuGet cache (version 1.3.1) the classes are all public, I don't know why.

Clearing the cache and restoring packages has helped.

Strange world - sorry for the trouble and thanks.

manuelroemer commented 1 month ago

No worries - glad that things could be resolved that easily! :heart: