[WIP] ILCompiler Package Multi-Runtime Package Support #5106
Conversation
| @@ -0,0 +1,66 @@ | |||
| <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> | |||
There was a problem hiding this comment.
This seems to be a copy of the files from src\BuildIntegration . Is it intentional?
There was a problem hiding this comment.
Yes. The versions in this folder have properties wrapped in targets with an explicit dependency on the "SetupProperties" target in the Microsoft.DotNet.ILCompiler.targets - this is to ensure that the name and location of the runtime package are resolved before the properties are defined and any build/publish steps which use their values are run. The reason for the copy is to avoid unnecessary bloating of the original BuildIntegration files, which will be used once the workaround can be removed.
Do you think modifying the original files is a better approach?
There was a problem hiding this comment.
Do you think modifying the original files is a better approach?
I think so. Just add comments around the workarounds so that we have a good way to find it.
| </PropertyGroup> | ||
| <Import Project="$(IlCompilerTargetsDir)/Microsoft.NETCore.Native.targets"/> | ||
|
|
||
| <!-- Everything below is a temporary hack to enable runtime package resolution. Should be deleted once MSBuild in .NET Core allows importing of build artifacts |
There was a problem hiding this comment.
Is there MSBuild issue that tracks this?
There was a problem hiding this comment.
Added : dotnet/msbuild#2807
Hopefully they can add some clarity to this.
A-And
force-pushed
the
ILCompilerPackageMultiRuntime
branch
from
101c3ae to
94ebbb7
Compare
2 participants
As it stands we only produce a Windows ILCompiler package. This work implements building and publishing of OS-specific runtime packages and spins off ILCompiler as a meta-package, which can be referenced when adding to a project.
Working on this, a quirk in MSBuild behavior under .NET Core popped up - build artifacts (i.e. .targets and .props files) are imported for direct project package references, but not for runtime-specific packages, defined as dependencies in the meta-package. This doesn't seem to be the case in vanilla MSBuild.
The below is a serious hack to work around this - during runtime, we find the resolved runtime package reference and define the path to it on disk, from which all OS-specific components are loaded and run. The motivation behind the workaround was to keep the package as small as possible, particularly because of the large intersection of components between OS implementations.
I don't think this is a particularly viable long-term solution, so feedback is welcomed.
@jkotas @MichalStrehovsky @nattress