Move the ILLink targets from the SDK repo to the linker repo#2837
Move the ILLink targets from the SDK repo to the linker repo#2837agocke merged 2 commits intodotnet:mainfrom
Conversation
In general, a task invocation in MSBuild and the task definition are inseparable. Adding parameters to the task will either result in errors if the target is updated and too new, or silently skipping the parameter if the target is too old. Best practice is to ship both as a pair to prevent this problem. Testing is harder, but we can add some limited testing if necessary to the linker repo.
|
Companion SDK change is dotnet/sdk#25993 |
| @@ -0,0 +1,365 @@ | |||
| <!-- | |||
There was a problem hiding this comment.
Should we also rename this file to Microsoft.NET.ILLink.Tasks.targets to match the props?
There was a problem hiding this comment.
That would cause it to be imported automatically, which is not what I think we want (I think we need to control the targets import order relative to other targets in publish).
I'm not sure how best to communicate the naming decisions here.
There was a problem hiding this comment.
So the idea is that when it's referenced as a nuget package, the props are imported per normal nuget semantics, but the targets are imported in the order defined by the SDK?
That would make sense to me, maybe just leave a comment in the header here to explain this.
…linker#2837) In general, a task invocation in MSBuild and the task definition are inseparable. Adding parameters to the task will either result in errors if the target is updated and too new, or silently skipping the parameter if the target is too old. Best practice is to ship both as a pair to prevent this problem. Testing is harder, but we can add some limited testing if necessary to the linker repo. Commit migrated from dotnet/linker@e6685e5
In general, a task invocation in MSBuild and the task definition are
inseparable. Adding parameters to the task will either result in errors
if the target is updated and too new, or silently skipping the parameter
if the target is too old.
Best practice is to ship both as a pair to prevent this problem. Testing is
harder, but we can add some limited testing if necessary to the linker repo.