dotnet
Add 'Eliminate Duplicate SDK Files' one-pager
Do we need to consider AOT strategy? Which parts of the SDK are we going to AOT? E.g. if we AOT dotnet-watch we can't load Roslyn binaries from the shared location since they would be part of the dotnet-watch native binary.
Do we need to consider AOT strategy? Which parts of the SDK are we going to AOT?
@JeremyKuhne and @baronfel are working on the AOT strategy. They're aware of this effort.
Do we need to consider AOT strategy? Which parts of the SDK are we going to AOT? E.g. if we AOT dotnet-watch we can't load Roslyn binaries from the shared location since they would be part of the dotnet-watch native binary.
AOT is orthogonal. It has no relationship to this and doesn't need to be considered. This is inherently a CoreCLR targeted project.
Do we need to consider AOT strategy? Which parts of the SDK are we going to AOT? E.g. if we AOT dotnet-watch we can't load Roslyn binaries from the shared location since they would be part of the dotnet-watch native binary.
AOT is orthogonal. It has no relationship to this and doesn't need to be considered. This is inherently a CoreCLR targeted project.
Why is that? If we AOT dotnet-watch then dotnet-watch can't/won't be loading Roslyn assemblies from the shared location.
Why is that? If we AOT dotnet-watch then dotnet-watch can't be loading Roslyn assemblies from the shared location.
Let's unpack this. I think you are saying that if we did the AOT project now, it would be status-quo w/rt "duplication". If we do this project, then AOT re-creates duplication. In reality, it still has nothing to do with this project. It makes AOT more (relatively) expensive than it would have been.
I don't see a single design choice or tradeoff here that is influenced by the choice to AOT some fo the SDK, in this release or the future. Can you outline any design considerations?
Another way to look at this is that de-duplication is buying us some budget to spend on AOT. This is in fact how I've always seen this project.
I see what you mean. What I had on mind is that if we do deduplication now we will need to undo it later for projects that get AOT'd. Let's say there are only two components that share Roslyn: dotnet-watch and dotnet-format. We implement loading of Roslyn assemblies from shared location for both. Then we decide to AOT both. At that point we will remove loading the assemblies and also remove the shared assemblies from the shared location because they won't be loaded by any components anymore. In the limit - if we decide to AOT everything than we don't need sharing at all.
Ah. That context is useful. I didn't see that one as a design consideration.
That leaves two options:
- De-dupe now if switching trains is cheap
- Prove out the model now and wait for some components until we have more clarity.
Another question is why do we have some of these tools in the SDK. IMO, it would be great to remove all tools. My ideal experience is that there are tool packs, exactly like the VS Code extension packs. We could have a gesture to acquire common curated tools as a single gesture. And then much of this discussion goes away. Seems like a missing feature resolves a bunch of problems.
As a second or third phase, it should seek to remove all uses of Newtonsoft.Json from the SDK. We were talking about this at lunch. Some of the mechanical reasons why we have it were explained to me, but none of them make sense as a long-term plan. My understanding is that NuGet will be the primary concern. This is more than a size issue. For example, once the Memory Safety v2 project is fully-enabled, we should mandate that every single library and tool in the SDK is compiled with the new mode. This will put more pressure on legacy dependencies. Similarly, we should strongly encourage trim safety and discourage reflection. Some of this will likely require breaking changes.
@aortiz-msft @agocke
Triggered by a comment by @tmat, I re-evaluate using hard links to solve the duplication problem. I had originally dismissed it because of Windows. Discussing this with @baronfel, we feel there is a way that we can support hard links on windows by adding tarball archives. I pushed an update to the document that describes this new approach and decisions that make it feasible. Please review and provide your feedback.