-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Investigate and list ProjectReference and PackageReference behavioral divergences #8507
Comments
At some point I did some digging about issues that contain this type of information and creating an issue for a future investigation. I don't think my issue has anything you don't know, but figured I'd share it:
|
I forwarded the e-mail my write-up references :) |
PackageReference Metadata Lists
ProjectReference Metadata Lists
|
Differences between PackageReference and ProjectReference
Appart from those metadata differences - other group of differences is nuget support for additional assets - especially Attach some examples for ExcludeAssets IncludeAssets and PrivateAssets in excel |
Hey @JaynieBai Excellent list! I think the NoWarn part for ProjectReference might not be 100% correct. Are you seeing anything different in your tests? |
Thanks for pointing it out. I didn't find any direct warnings about project reference currently. But it couldn't suppress transitive warning and referenced project warning now. So mark it not supported temporarily. |
Not sure what you mean by I think NoWarn is equivalent for ProjectReference and PackageReference. The lack of transitive support is a big change and it applies to more than just NoWarn. |
Taks an example from https://github.com/JanKrivanek/msbuild/blob/doc/dependencies-behavior/documentation/wiki/Controlling-Dependencies-Behavior.md#access-to-transitive-project-references
Build it and there will generate following warnings. In Service Project definition.
NU1701;NU1602 is transitive reference warning. I can't find a warning that is generated from projectReference. And in https://learn.microsoft.com/en-us/nuget/reference/errors-and-warnings. It specifies NoWarn scope as Project, PackageReference |
Attach some examples for ExcludeAssets IncludeAssets and PrivateAssets in excel |
If you take a project that targets net5.0 and add a project reference to a project that targets net472, you'll get a NU1702 which should be suppressible. I've created an issue to fix the doc to make it clearer: NuGet/docs.microsoft.com-nuget#3038. |
OK, so the bug for ProjectReference NoWarn is NuGet/Home#8093. |
Discussed offline with @JanKrivanek about transitive assembly references. From @JaynieBai From @JanKrivanek |
Assembly references in .NET are generally required to be transitive. At runtime, if you call code from B that uses a type from A, the .NET assembly loader will fail if A cannot be loaded. At build time, the compiler may or may not need the full transitive closure--it will definitely need to see A if the public API of B returns a type from A, but if the use of A is all internal implementation details of B, the compiler may be able to succeed without access to A. However, the contract of the compiler is that you should pass the full closure, and if you don't and a new compiler requires more assemblies to do deeper analysis on the same code, that is not considered a breaking change in the compiler. All of that has been the same for a very long time; there's no change introduced in .NET Core or the .NET SDK compared to (for example) a set of VS2010 projects. Prior to SDK-enabled transitive project references, the closure was computed entirely within In a fully old-school project what would happen is:
A big difference between this approach and the SDK's default transitive ProjectReferences is how |
@JaynieBai - do you plan any other work on this task? Or can this be closed? (Feels complete from my point of view. And thanks again for the help!) |
I don't have any plan for this work now. So, I think we can close that. |
Motivation
#8398 needs investigation of what we can support (and how) in converting between the two.
There might be possible inconsitencies between
PackageReference
andProjectReference
items metadata (and even behavior with same metadata - e.g.SetTargetFramework
has different behavior for the two: NuGet/Home#12436,PrivateAssets
as well: #4371 (comment), etc.).Expected outputs
PackageReference
andProjectReference
- stressing out the differencesThe text was updated successfully, but these errors were encountered: