Line Numbering option fails if IKVM.Runtime cannot be resolved

[Bobbias]

ilrepack does not indicate anywhere that line numbering depends on resolving IKVM.Runtime. It's not a dependency of ilrepack, so unless it just happens to be available to be resolved, you will get an error complaining it cannot be resolved. Tracking down why that's even a problem could be rather confusing, since it may not be a transitive dependency of your project. At least mentioning that line numbering relies on this being available would be nice. I only figured out what was going on when I started looking at the source and saw IKVMLineIndexer.cs was injecting references to it.

[KirillOsenkov]

do you have some repro or a test?

[KirillOsenkov]

you said 'you will get an error complaining it cannot be resolved'. It would be nice to get the exact text so I can find where the error is emitted.

[KirillOsenkov]

My understanding is that the entire feature should be deleted because what it does is now supported out of the box by embedding pdbs (setting <DebugType>embedded</DebugType> in the .csproj)

[Bobbias]

Ahh, ok that's good to know. As for reproduction, I don't have my repo up anywhere at the moment, but reproduction is as simple as ilrepack /index /out:packed.dll main.dll second.dll. If IKVM.Runtime is not present in that folder, or in a library path, and the /index option is used, then you get output that looks like this:

ilrepack /index /out:repack.dll .\ToggleEverything.dll .\Newtonsoft.Json.dll
------------- IL Repack Arguments -------------
/index /out:repack.dll .\ToggleEverything.dll .\Newtonsoft.Json.dll
-----------------------------------------------
Failed to resolve assembly: 'IKVM.Runtime, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'

I initially encountered this using the ILRepack MSBuild task, but it's the same with the standalone tool. But by the sounds of it it's probably worth removing the option now. Now, this exact command line would fail even if IKVM.Runtime.dll was resolved because it lacks the library paths for other assemblies I reference, but it's enough to reproduce the issue.