Add cecil dependency to ILLink package

[sbomer]

Fixes #82597 by ensuring the Microsoft.DotNet.Cecil dependency shows up in the nuspec. Fixes #82611.

The ref project changes aren't strictly necessary since that project isn't used for packaging, but I removed PrivateAssets there for consistency. I removed Publish there because it should never be published in a package from that project.

I think this wasn't caught in #82407 because the package validation doesn't run as part of the clr.tools subset - we should fix that.

[ghost]

Tagging subscribers to 'linkable-framework': @eerhardt, @vitek-karas, @LakshanF, @sbomer, @joperezr
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Fixes #82597 by ensuring the Microsoft.DotNet.Cecil dependency shows up in the nuspec. Fixes #82611.

The ref project changes aren't strictly necessary since that project isn't used for packaging, but I removed PrivateAssets there for consistency. I removed Publish there because it should never be published in a package from that project.

Author:	sbomer
Assignees:	-
Labels:	linkable-framework
Milestone:	-

[stephentoub]

I assume this will also fix #82611?

[sbomer]

Yes, that's the intention. Do you know if there's a way to trigger the libraries build legs in this PR? I checked the .nuspec locally but ideally we would run package validation in this change.

[ViktorHofer]

I checked the .nuspec locally but ideally we would run package validation in this change.

I don't think there's an easy way todo with our current infrastructure setup. Did you consider changing the evaluate path triggers to make sure that the libraries allconfigurations leg (which invokes packagevalidation) runs when src/tools/illink changes?

[sbomer]

Did you consider changing the evaluate path triggers to make sure that the libraries allconfigurations leg (which invokes packagevalidation) runs when src/tools/illink changes?

I considered this, but I think we wanted to run only the illink validation legs when developing illink. Would it be feasible to run package validation in the clr.tools subset instead?

[ViktorHofer]

I considered this, but I think we wanted to run only the illink validation legs when developing illink. Would it be feasible to run package validation in the clr.tools subset instead?

Just to be clear, two "package validation" features exist:

1. Package Validation which is part of APICompat (shipping tool). This runs whenever we do a dotnet pack or a dotnet build + GeneratePackageOnBuild=true. We only do this in the Libraries Windows allconfigurations leg because doing a pack in every leg would end up generating duplicated package assets which will make the official build's Publish step fail (because it doesn't know which one to pick).
2. testPackages.proj. This is the infrastructure that does dependency closure verification and the component that emitted the error. I don't know of an easy way to enable this in the tools subset.

Just enabling the Libraries Windows allconfigurations would enable both components and just adds a single leg to the pipeline. I would advise doing that, especially as we want to run the live built linker at some point in the libraries partition anyway.

[sbomer]

That makes sense, thanks a lot for the explanation!

[agocke]

Looks like the libraries build passed, which is all we really need for this change. Merging.