Document references peculiarities #8494
Conversation
JanKrivanek
force-pushed
the
doc/dependencies-behavior
branch
from
435ed6c to
aa7b9c8
Compare
There was a problem hiding this comment.
Thanks for writing this! There are many subtle behaviors and interconnected systems here so I have a bunch of nitpicky comments and clarifications but am very excited to have this.
cc @ghogen -- some of this could be customer facing at some point, though I think it's a bit too complex/confusing/detail-oriented at the moment.
| // This is allowed unless DisableTransitiveProjectReferences=true is passed into build. | ||
| // private Domain.PersonTable _tbl; |
There was a problem hiding this comment.
Unfortunately this is kind of a bad example; the C# compiler should see the full closure of dependencies in any case--and as analyzers and nullability analysis increase, is getting more persnickety about this. At some point in the future this type of library reference may be required to be transitive--but all of the MSBuild stuff and motivations will stay good.
There was a problem hiding this comment.
Does this still feel as bad example after this #8494 (comment)?
|
|
||
| **Notes:** | ||
|
|
||
| This will properly enforce the framework for the dependency chain. The output folder will contain proper version of the direct dependency - Repository Layer. The transitive dependencies might overbuild, and output folder of current project (Service Layer) might contain both versions of the transitive project dependency (Domain-net48.dll and Domain-netstd20.dll). This limitation can be workarounded by switching of the transitive project dependencies via `DisableTransitiveProjectReferences` (same as shown in [Access to transitive project references](#access-to-transitive-project-references)) |
There was a problem hiding this comment.
I'm not sure I understand this. Is it something like "once the first-level reference with overridden TF is hit, its references get normal TF resolution", so you might get different TFs on a transitive reference and have them both build?
There was a problem hiding this comment.
Based on this and above feedback I attempted to reformulate this: https://github.com/dotnet/msbuild/pull/8494/files#diff-b5dec84f84d1f113f1c8d8369daf2a8b4958736d3e02764f3bfbd42e42c4a917R243-R246
Review would be appreciate - to make sure it's accurate and understandable
Co-authored-by: Rainer Sigwald <raines@microsoft.com>
|
|
||
| For [.NET SDK projects](https://learn.microsoft.com/dotnet/core/project-sdk/overview) restore operation by default makes all transitive references accessible as if they were direct references. | ||
|
|
||
| This is required by the compiler and analyzers to be able to properly inspect the whole dependency or/and inheritance chain of types when deciding about particular checks. |
There was a problem hiding this comment.
Technically the full closure isn't required by the compiler today, but the compiler team wishes it was, and new analysis can cause not-required-today assembly references to be required tomorrow.
There was a problem hiding this comment.
Good point. I reworded (required by -> provided for), to prevent incorrect statement.
| } | ||
| ``` | ||
|
|
||
| ## Access to transitive package references | ||
|
|
||
| The transitive access to dependencies works by default for package dependencies as well. This can be opted out via `PrivateAssets=compile` on the `PackageReference` of the concern. (More details on [Controlling package dependency assets](https://learn.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files#controlling-dependency-assets)) | ||
| The transitive access to references works by default for package references as well. This can be opted out via `PrivateAssets=compile` on the `PackageReference` of the concern. (More details on [Controlling package dependency assets](https://learn.microsoft.com/nuget/consume-packages/package-references-in-project-files#controlling-dependency-assets)) |
There was a problem hiding this comment.
Is there actually a way to reference a package and not its transitive closure? PrivateAssets affects only things that reference you, so you would have to change the package you want to reference.
There was a problem hiding this comment.
Correct. It was ment so in the example, but the description was very unclear and ambiguous.
I attempted to clarify it and explicitly call out the behavior.
Co-authored-by: Rainer Sigwald <raines@microsoft.com>
rainersigwald
added
the
Documentation
JanKrivanek
added
the
merge-when-branch-open
Relates to:
#4795
#8405
Context
Documenting some aspect of tailoring behavior of references. Capturing as well resolution/workarounds for the listed comunity reported issues