Remove libraries folders that don't have src/*.cs files

[jozkee]

Based on a conversation on https://github.com/dotnet/runtime/pull/78935/files#r1035029354.

It would be nice if we could remove folders that don't generate implementation assemblies because their types were moved to another assembly for unification.

If I browse through C:\Program Files\dotnet\shared\Microsoft.NETCore.App\7.0.0 I can see that there are assemblies that ship with dotnet and don't have a folder or a csproj in our src\libraries. e.g: System.IO.Compression.FileSystem.dll.

Is it possible to remove more folders from libraries in a similar way?
In case is not possible, what makes System.IO.Compression.FileSystem.dll special?

In case of being possible we could be able to potentially remove all these folders (at least from the ones owned by my area pod):

• System.IO.FileSystem.Primitives
• System.IO.FileSystem
• System.IO.Pipes.AccessControl
• System.IO.UnmanagedMemoryStream
• System.IO
• System.Security.Cryptography.Algorithms
• System.Security.Cryptography.Cng
• System.Security.Cryptography.Csp
• System.Security.Cryptography.Encoding
• System.Security.Cryptography.OpenSsl
• System.Security.Cryptography.Primitives
• System.Security.Cryptography.X509Certificates

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

Issue Details

---

Based on a conversation on https://github.com/dotnet/runtime/pull/78935/files#r1035029354.

It would be nice if we could remove folders that don't generate implementation assemblies because their types were moved to another assembly for unification.

If I browse through C:\Program Files\dotnet\shared\Microsoft.NETCore.App\7.0.0 I can see that there are assemblies that ship with dotnet and don't have a folder or a csproj in our src\libraries. e.g: System.IO.Compression.FileSystem.dll.

Is it possible to remove more folders from libraries in a similar way?
In case is not possible, what makes System.IO.Compression.FileSystem.dll special?

In case of being possible we could be able to potentially remove all these folders (at least from the ones owned by my area pod):

• System.IO.FileSystem.Primitives
• System.IO.FileSystem
• System.IO.Pipes.AccessControl
• System.IO.UnmanagedMemoryStream
• System.IO
• System.Security.Cryptography.Algorithms
• System.Security.Cryptography.Cng
• System.Security.Cryptography.Csp
• System.Security.Cryptography.Encoding
• System.Security.Cryptography.OpenSsl
• System.Security.Cryptography.Primitives
• System.Security.Cryptography.X509Certificates

Author:	Jozkee
Assignees:	-
Labels:	area-System.Security
Milestone:	-

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

Issue Details

---

Based on a conversation on https://github.com/dotnet/runtime/pull/78935/files#r1035029354.

It would be nice if we could remove folders that don't generate implementation assemblies because their types were moved to another assembly for unification.

If I browse through C:\Program Files\dotnet\shared\Microsoft.NETCore.App\7.0.0 I can see that there are assemblies that ship with dotnet and don't have a folder or a csproj in our src\libraries. e.g: System.IO.Compression.FileSystem.dll.

Is it possible to remove more folders from libraries in a similar way?
In case is not possible, what makes System.IO.Compression.FileSystem.dll special?

In case of being possible we could be able to potentially remove all these folders (at least from the ones owned by my area pod):

• System.IO.FileSystem.Primitives
• System.IO.FileSystem
• System.IO.Pipes.AccessControl
• System.IO.UnmanagedMemoryStream
• System.IO
• System.Security.Cryptography.Algorithms
• System.Security.Cryptography.Cng
• System.Security.Cryptography.Csp
• System.Security.Cryptography.Encoding
• System.Security.Cryptography.OpenSsl
• System.Security.Cryptography.Primitives
• System.Security.Cryptography.X509Certificates

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

[vcsjones]

System.Security.Cryptography.Algorithms
System.Security.Cryptography.Cng
System.Security.Cryptography.Csp
System.Security.Cryptography.Encoding
System.Security.Cryptography.OpenSsl
System.Security.Cryptography.Primitives
System.Security.Cryptography.X509Certificates

All of these assemblies were collapsed in to System.Security.Cryptography. However, we need the ref assemblies for type forwarding to work. There is also the test consolidation work that is being tracked in #66338.

[jozkee]

However, we need the ref assemblies for type forwarding to work.

Yes, I'm asking if there's a better way to make type forwarding and why there's no ref project/source for System.IO.Compression.FileSystem.dll.

If there's no other way, we are meant to keep forever folders of old assemblies whose types were shifted. That may not be a bad thing but it will keep piling-up over the time.

[ViktorHofer]

If I browse through C:\Program Files\dotnet\shared\Microsoft.NETCore.App\7.0.0 I can see that there are assemblies that ship with dotnet and don't have a folder or a csproj in our src\libraries. e.g: System.IO.Compression.FileSystem.dll.

These assemblies are .NETFramework/.NETStandard shims and are still live built but hidden in a subdirectory under src/libraries/shims.

Is it possible to remove more folders from libraries in a similar way?

We need to keep both the reference and the source assembly building as the ref is exposed in the targeting pack and the lib is part of the runtime pack / shared framework. Removing either one is a breaking change. In general, it would be possible to move these into a subdirectory to hide them but that would require infrastructure adjustments.

[ViktorHofer]

With c0cca33, it should now be relatively straightforward to move pure facade libraries (typeforwards in both ref and src) under src/libraries/shims. When doing that, the tests should be moved to the location that the type forwards point to.

@jozkee feel free to start with https://github.com/dotnet/runtime/tree/main/src/libraries/System.IO.FileSystem.Primitives. For that, you would just need to do the following:

1. Move its tests to the reference source code location (System.Runtime/tests)
2. Move the reference source project to src/libraries/shims/System.IO.FileSystem.Primitives/src/ and add the StrongNameKey from the Directory.Build.props file directory into the project file. Remove the compile items from the project file as EnableDefaultItems is enabled for shim projects. Change the P2P from ref/System.Runtime.csproj to src/System.Runtime.csproj.
3. Move the src/libraries/System.IO.FileSystem.Primitives/ref/System.IO.FileSystem.Primitives.Forwards.cs to src/libraries/shims/System.IO.FileSystem.Primitives/src/System.IO.FileSystem.Primitives.cs
4. Delete all the other files (sln, README.md, Directory.Build.props, src/)
5. Make sure that no other project has a <Reference Include="System.IO.FileSystem.Primitives" /> item. A direct reference isn't necessary anymore as types exist directly in ref/System.Runtime.dll.
6. nit: format the project file so that it looks similar to the other shim project files (layout)

If that works well, we can move the other shim projects into there as well. Please let me know if the steps above work for you.