Consider reducing code duplication across core assemblies

[eerhardt]

Similar to dotnet/runtime#36721, we should consider reducing code duplication for large chunks of code.

For example, the StackTrace code is currently compiled into 3 assemblies. 2 of these are used by default in the dotnet new api template. By combining this code into a single .dll, (see bed28aa), I was able to reduce the final app size by 30 KB.

before
9.66 MB (10,130,432 bytes)

after
9.63 MB (10,099,200 bytes)

From inspecting the mstat file, you can see that the Http.Extensions assembly got larger, but the Diagnostics and Hosting assemblies got smaller.

The drawback to this is we either need to:

• Make these APIs public
• Use InternalsVisibleTo

Using InternalsVisibleTo isn't that bad if the assemblies always ship together. If they ship in separate NuGet packages, which may version differently or get out-of-sync, this seems like a bad idea. For this instance though, the Diagnostics and Hosting assemblies only ship in the ASP.NET Core shared framework. So they version/update together.

cc @amcasey @halter73 @davidfowl

[halter73]

Using InternalsVisibleTo isn't that bad if the assemblies always ship together. If they ship in separate NuGet packages, which may version differently or get out-of-sync, this seems like a bad idea. For this instance though, the Diagnostics and Hosting assemblies only ship in the ASP.NET Core shared framework. So they version/update together.

💯 What do you think @davidfowl?

[pinkfloydx33]

I remember reading (a while back) an issue in the Runtime repo where someone mentioned that using IVT prevents the linker from removing unreachable code (I think). That had to have been a few years ago though. Is that still not the case?

[eerhardt]

using IVT prevents the linker from removing unreachable code (I think).

That would surprise me. @vitek-karas @sbomer - any thoughts on this?

[Tratcher]

Or this belongs in runtime?

[vitek-karas]

IVT should only have impact on trimming in library mode (which is what runtime uses internally for shared framework build), but it doesn't affect application trimming in any way. So this should not be a problem.

I don't know how ASP.NET handles ref assemblies, but another possibility would be to make the APIs public but don't include them in the ref assembly. Similar to what we do for several APIs in the BCL or similar reasons.

[adityamandaleeka]

Triage: this may be worth investigating in the future, but at this point there are more impactful changes for size we'll focus on.

Thanks for contacting us.

We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.