ilproj's cannot be built outside of Windows

[mellinoe]

We need to start restoring the ilasm package for the correct RID (during init-tools), and then hook that path up into ilproj.targets.

[alexperovich]

A while back I tried to do this and the ilasm from the package was not working correctly. I will see if I can dig up the branch I had.

[mellinoe]

I remember having a similar issue, but it was so long ago that I'm hoping everything is fixed by now.

[alexperovich]

Well the package has a new version and my branch doesn't have any conflicts. I'll rebase and see if it works.

[alexperovich]

Yep, the issue still happens. The signing step fails with the following error:

E:\corefx\Tools\sign.targets(70,5): error : E:\corefx\bin/obj/AnyOS.AnyCPU.Debug/System.Reflection.TestModule/System.Reflection.TestModule.dll: PE file is not a delay-signed assembly. [E:\corefx\src\System.Runtime\tests\TestModule\System.Reflection.TestModule.ilproj]

And an analysis of the produced binary in ildasm reports the wrong metadata version on the assembly.
Inbox ilasm produces version: v4.0.30319 and the package version produces v4.0.22220

[weshaggard]

If it is just a signing issue we can disable signing for this test binary.

[alexperovich]

I don't think the binary would work unless the runtime supports loading PE files with a different metadata version.

[mellinoe]

So is this a bug in the .NET Core version of ilasm?

[alexperovich]

Yes.

[ericstj]

@mellinoe you mentioned that this should work now. When you bring over ilasm can you undo the workaround here: https://github.com/dotnet/corefx/blob/fbafeb42ea7488fa62240f03a233ddef9382a210/src/System.Runtime.CompilerServices.Unsafe/src/include/netstandard/coreassembly.h#L10-L20 and see if coreclr ilasm is broken in the same way desktop was? If so we need to open a coreclr bug.

[mellinoe]

This has been fixed.