[ILVerify] BadImageFormatGeneric when verifying a .netmodule

[z1c0]

Calling ILVerify.exe for a .netmodule results in a BadImageFormatGeneric error.
e.g.

ILVerify.exe "C:\Windows\Microsoft.NET\Framework\v4.0.30319\System.EnterpriseServices.Wrapper.dll" -r "C:\Windows\Microsoft.NET\Framework\v4.0.30319\mscorlib.dll"

results in:

Error: [TEMPORARY EXCEPTION MESSAGE] BadImageFormatGeneric:

[z1c0]

The problem occurs in EcmaModule.cs since containingAssembly is null in that case and the .netmodule is incorrectly opened as EcmaAssembly (instead of EcmaModule).

public static EcmaModule Create(TypeSystemContext context, PEReader peReader, IAssemblyDesc containingAssembly)
{
  MetadataReader metadataReader = CreateMetadataReader(context, peReader);

  if (containingAssembly == null)
    return new EcmaAssembly(context, peReader, metadataReader);
  else
    return new EcmaModule(context, peReader, metadataReader, containingAssembly);
}

[MichalStrehovsky]

Does it make sense to run the ILVerify on a .netmodule directly? We can't e.g. do proper access checks in this situation because we don't know whether an InternalsVisibleTo attribute on a referenced assembly is applicable to the module being verified (we don't know what assembly the verified module is part of). If not, we could just add an early check that reports a bad input.

[z1c0]

I agree that it does not make to much sense.
I only discovered the issue because in our use case we generically try to verify all files in a folder - some of them being netmodules.

However, currently the code takes a wrong turn and tries to resolve a netmodule as an EcmaAssembly.
Proper error handling would probably be the best choice.

(Alternatively, an additional command line argument could specify the containing assembly for the .netmodule)