Make src/native/managed projects use Microsoft.DotNet.ILCompiler version from Version.props#100845
Conversation
|
Tagging subscribers to this area: @dotnet/area-infrastructure-libraries |
jkoritzinsky
left a comment
There was a problem hiding this comment.
We can start with this for now.
|
We switched ILCompiler project to use ILCompiler package from the flow because we needed a more recent fix at one point, but we don't have a hard dependency on using it. What's the reason to use the ILCompiler package reference here? The package reference can have potential codeflow problems (discussed in #89655 (comment) when ILCompiler was switched to this). We may need to switch to "whatever comes with dotnet we're using to build the repo" to work around if such codeflow problem is hit. I want to understand if such revert will be possible here too and the motivation for using the package in the first place. |
|
We hit build breaks when integrating into installer. This was a mix of source build support (#100807 (comment)) and the infrastructure for src/native/managed relying on old behaviour in targets which we would have caught earlier if it used a newer version. It seemed consistency with other things in the repo around the version being used would be best, so I went for the package like ILCompiler. Reverting should be possible and the same as what would need to happen for ILCompiler - remove the package reference and might need to (re-)disable in source build. |
…ion from Version.props (dotnet#100845) - Use the version of Microsoft.DotNet.ILCompiler specified in Version.props when producing runtime components in src/native/managed via NativeAOT - This is the same version that `ILCompiler.csproj` / `ilc` itself uses to publish as NativeAOT - Reduce the number of copies of the output by avoiding publishing and just running `LinkNative`
ILCompiler.csproj/ilcitself uses to publish as NativeAOTLinkNative- per Make InstallRuntimeComponentToFinalDestination use NativeOutputPath for copying to runtime output #100782 (comment)I also tried making it use the live build (elinor-fung/runtimeComponent-nativeaotLive). Works fine locally, but it would require having clr.aot+libs built before being able to build the cdac. We have cdac parented under the clr build now - I don't know that we'd want to pull it into a separate thing that requires subsets from multiple sub-partitions to have been built already.