Should new APIs added to System.IO be excluded from MS.IO.Redist?

[jozkee]

When EnumerationOptions.MaxRecursionDepth was added (#48148), it was also added for MS.IO.Redist.
Is that something that we should revert by ifdefing the code? If yes, then we should do a long-term solution to avoid hitting this problem.

cc @ericstj

Originally posted by @jozkee in #54253 (comment)

[ghost]

Tagging subscribers to this area: @Anipik, @safern, @ViktorHofer
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Good point, no one has asked us for it. We added these dependencies because this project was already compiling FileSystemInfo.
It looks to me that any API that we add to any type already compiling for MS.IO.Redist will be automatically released for that version as well. Is that desired?

e.g: when EnumerationOptions.MaxRecursionDepth was added (#48148), it was also added for MS.IO.Redist.
Is that something that we should revert by ifdefing the code? If yes, then we should do a long-term solution to avoid hitting this problem.

cc @ericstj

Originally posted by @jozkee in #54253 (comment)

Author:	Jozkee
Assignees:	-
Labels:	area-Infrastructure-libraries, untriaged
Milestone:	-

[ghost]

Tagging subscribers to this area: @dotnet/area-system-io
See info in area-owners.md if you want to be subscribed.

Issue Details

---

When EnumerationOptions.MaxRecursionDepth was added (#48148), it was also added for MS.IO.Redist.
Is that something that we should revert by ifdefing the code? If yes, then we should do a long-term solution to avoid hitting this problem.

cc @ericstj

Originally posted by @jozkee in #54253 (comment)

Author:	Jozkee
Assignees:	-
Labels:	area-System.IO, untriaged
Milestone:	-

[jkotas]

If we are hesitant to add new APIs to this package, should we archive it and stop building it?

[ericstj]

Not sure what the problem is alluded to above, I'm guessing just needing to maintain the project file (and test the library). @JeremyKuhne created the package originally for Visual Studio and MSBuild to leverage the APIs he was adding to System.IO while still on .NETFramework (without changing NETFramework). I believe his idea was to share as much of IO as possible so that our dev tooling (that needed to stay on .NETFramework) could benefit from his IO improvements.

I see it's used here: https://github.com/dotnet/project-system/blame/0476235d70d1b65b8062492075db6fd86995612a/src/Microsoft.VisualStudio.ProjectSystem.Managed/IO/WindowsFileExplorer.cs cc @davkean
Couldn't find any other consumers in our repos in github.

[JeremyKuhne]

No, APIs don't need to be excluded from this library.

[jeffhandley]

My read on this is:

1. Let the new APIs ship in the MS.IO.Redist package
2. During .NET 7.0 planning, we should reevaluate the value this package offers and determine whether or not we should continue producing it

[adamsitnik]

We can add new APIs to the Redist package, but only when it does not require a lot of effort and does not increase the complexity on our side. When it does, we need good business justification.

During .NET 7.0 planning, we should reevaluate the value this package offers and determine whether or not we should continue producing it

That is a very good idea!

[jeffhandley]

With #58359, we've stopped shipping Microsoft.IO.Redist.