Obsolete APIs about standard HOT 9 CLOSED

For reference there are about ~250 APIs marked as obsolete in netstandard.

from standard.

I don't think we can exclude APIs just because they are marked as obsolete.

from standard.

@terrajobst This isn't the "a future release" where it "may" be removed? :)

from standard.

Our problem with .NET Core isn't that it's not "clean enough". Our problem is that .NET Core is too hard to target.

I think moving forward, we've a much better way to experiment on top of .NET Core. I could see a world where we can make more adjustments there, because everything is app-local and folks can update on their own cadence. But we're aren't there yet.

from standard.

Our problem with .NET Core isn't that it's not "clean enough". Our problem is that .NET Core is too hard to target.

It's too hard to target for old, existing code, I'd say. I think it's hard to argue that bringing back obsolete API's is really going to help any new code target .NET Core (except by having more dependencies using obsolete code available).

In my opinion, the line between API's that we actually marked obsolete and "really bad APIs that should have been obsoleted but never were" is too ambiguous to be useful. We haven't been consistent enough in the past with obsoleting and deprecating for those categories to be relied upon now. We've also had cases where we needed to UN-obsolete some members because they shouldn't have been marked in the first place: https://github.com/dotnet/corefx/issues/8043. I think we should ignore the attribute in most cases, because it's not proved to be very reliable.

I could see a world where we can make more adjustments there, because everything is app-local and folks can update on their own cadence.

It kind of seems like a pipe dream at this point, especially with the introduction of the shared framework and the implicit compatibility guarantees offered by the .NET Standard work (even if we, in theory, reserve the right to make breaking changes).

from standard.

In my mind the obsolete attribute means "don't write new code that uses this, it may not work well, the compiler will help warn you" and does not mean "we may remove this API in a future version" as our predecessors hoped it would mean.

from standard.

In my mind the obsolete attribute means "don't write new code that uses this, it may not work well, the compiler will help warn you"

That's generally a good idea until you hit something like the issue I linked above. And I'm not really sure we haven't made the same mistakes elsewhere in the framework. We had different priorities at different times when we used the attribute, so it's no wonder that some of them don't make sense anymore.

from standard.

It's too hard to target for old, existing code, I'd say. I think it's hard to argue that bringing back obsolete API's is really going to help any new code target .NET Core (except by having more dependencies using obsolete code available).

That were true if all the obsolete APIs have equivalents that folks can use. Also, keep in mind that folks write plenty of new code that still needs to interoperate with existing code. It's not just new code vs existing code; it's about evolution vs. building a complete island. The latter case is much more rare.

from standard.

While it it is kind of unfortunate I agree that we should keep the APIs marked as Obsolete unless there is some other reason to remove them. The presents of the attribute alone isn't enough of a reason to exclude for netstandard.

from standard.