ilasm cannot compile against different corlib names

[agocke]

For instance, compiling the following il:

.assembly '_0_89c370b1-0d11-4511-9273-3053e4dbf734' {} 

.assembly extern netstandard 
{
  .publickeytoken = (B7 7A 5C 56 19 34 E0 89)
  .ver 2:0:0:0
} 


.class public auto ansi beforefieldinit Class
       extends [netstandard]System.Object
{
} // end of class Class

Results in the following warning:

 warning : Reference to undeclared extern assembly 'mscorlib'. Attempting autodetect

And System.Object is retargeted to mscorlib and an mscorlib ref is added to the output assembly.

[agocke]

cc @gkhanna79 @jkotas

[gkhanna79]

CC @RussKeldorph

[RussKeldorph]

How urgent is fixing this? What is it blocking?

[agocke]

This will probably block us running a significant amount of Roslyn unit tests on CoreCLR.

[jkotas]

The fix should be to add another case for netstandard here: https://github.com/dotnet/coreclr/blob/52a816d3011f4d03b80b5940dc036b40d701f52d/src/ilasm/assembler.cpp#L279

[agocke]

It would be nice to support arbitrary corlib names. Roslyn currently uses the heuristic that an assembly with no references = the corlib. Is there a reason this couldn't be used by ilasm as well?

[agocke]

@RussKeldorph I unblocked us by using the netstandard.library 2.0 mscorlib ref and that seems to be working OK. So I'll let you know if this becomes blocking again.

[mellinoe]

This affects System.Runtime.CompilerServices.Unsafe, as well. For what it's worth, referencing "System.Runtime" is accepted by ilasm, and that's what we are doing for the time being.

https://github.com/dotnet/corefx/blob/master/src/System.Runtime.CompilerServices.Unsafe/src/include/netstandard/coreassembly.h#L10

@ericstj

[jkotas]

Roslyn currently uses the heuristic that an assembly with no references = the corlib. Is there a reason this couldn't be used by ilasm as well?

ilasm takes the IL text file as input, it does not take the ref assemblies as inputs. Thus, it cannot tell which assembly does not have any references.

[mletterle]

FWIW, if you alias netstandard as mscorlib it will do what you what:

.assembly '_0_89c370b1-0d11-4511-9273-3053e4dbf734' {} 

.assembly extern netstandard as mscorlib 
{
  .publickeytoken = (B7 7A 5C 56 19 34 E0 89)
  .ver 2:0:0:0
} 


.class public auto ansi beforefieldinit Class
       extends [mscorlib]System.Object
{
} // end of class Class

after ilasming, ildasm's to:

.assembly '_0_89c370b1-0d11-4511-9273-3053e4dbf734' {} 

.assembly extern netstandard
{
  .publickeytoken = (B7 7A 5C 56 19 34 E0 89)
  .ver 2:0:0:0
} 


.class public auto ansi beforefieldinit Class
       extends [netstandard]System.Object
{
} // end of class Class

It's fairly unintuitive, and can actually cause problems if you alias mscorlib to something else (or System.Runtime as it turns out, see dotnet/coreclr#10595), but I believe this is what the original BaseAsmRef method is meant to do in general. Continuously adding new "BaseAsmRef" names seems.... bad...

[mletterle]

The issue with System.Object being retargeted from netstandard -> mscorlib is because of dotnet/coreclr#10618

[daxian-dbw]

Sorry to leave a comment on this closed issue. I ran into this on Windows, the ilasm.exe I use is of version '4.7.2558.0' (Microsoft (R) .NET Framework IL Assembler version 4.7.2558.0). Is it possible that the fix doesn't make to that version of ilasm.exe?

[daxian-dbw]

To be more specific, ilasm.exe spits the warning "Reference to undeclared extern assembly 'mscorlib'. Attempting autodetect" at a reference to System.Enum, and the generated ref assembly has a reference to mscorlib.dll.

  .class private sealed 'Feature'
    extends ['netstandard']'System'.'Enum'
  {
    .field public rtspecialname specialname int32 'value__'
    .field static public literal valuetype 'Microsoft.Virtualization.Client.Common'.'Feature' 'QuickCreateOnlineTemplates' = int32(0x00000001)
  }

[ericstj]

Yeah, I think this issue is only addressing the ILasm built from coreclr. I'm guessing you are using the desktop ILAsm that comes from C:\Windows\Microsoft.NET\Framework\v4.0.30319\ilasm.exe? Tagged this as netfx-port-consider so that folks can look at backporting the fix to desktop.

[daxian-dbw]

@ericstj Thanks for the quick reply! Yes, I'm using the desktop ILAsm that comes with the full .NET framework. That explains. Thanks!