ilasm/ildasm as dotnet global tools

[am11]

For example, acquisition and usage of https://www.nuget.org/packages/dotnet-format/ is quite simple:

dotnet tool install --global dotnet-format

dotnet-format --files MyModel.cs

It would be handy if IL-related tools are also packaged as .NET Core Global tools and following the installation instructions on nuget.org page (dotnet tool install ..) is sufficient.

[danmoseley]

Ildasm (at least) is Windows specific right now. If there were global tools ideally they’d be cross platform.

@safern didn’t you mention you wrote a cross platform ildasm?

[am11]

With the current master, it seems to be building on Unix, e.g.:

https://github.com/dotnet/coreclr/blob/a9f3fc16483eecfc47fb79c362811d870be02249/src/ildasm/exe/CMakeLists.txt#L12-L18

we get coreclr/bin/Product/Linux.x64.Debug/ildasm executable.

[jkotas]

Ildasm (at least) is Windows specific right now

ildasm is not Windows specific. Did you mean to say platform specific?

[danmoseley]

@jkotas I meant it’s a Win32 UI app isn’t it? At least the original one I’m used to. I guess I’m out of date?

[jkotas]

The .NET Framework one is a dual command line tool and Win32 UI app. The .NET Core one is a regular (unmanaged) command line tool. We did not bother to open source the Win32 UI.

[MarcoRossignoli]

@jkotas ILVerify is the one in corert repo?Will be moved to new repo?

[jkotas]

Yes, I think it would make sense. Opened https://github.com/dotnet/coreclr/issues/27939

[ericstj]

We can actually leverage this feature to package platform-specific tools: https://github.com/dotnet/sdk/blob/main/documentation/general/signing-global-tool-packages.md

@Petermarcu let me know that @wli3 came up with this suggestion for some Azure tools a few months back. It just occurred to me that it might be nice to use for ILAsm/ILDasm.

[ericstj]

Moving this to 7.0.0 as I think we can meaningfully improve the customer experience here with small effort.

[kant2002]

Hi guys, what specifically should be done here, I half time spend on Linux and even if I have that runtime built locally, I prefer have it as separate tool.

[akoeplinger]

As a workaround you can download and unzip this nuget package: https://www.nuget.org/packages/runtime.linux-x64.Microsoft.NETCore.ILDAsm (change the linux-x64 to match your RID).

It contains an ildasm binary in runtimes/<RID>/native/ildasm

[arizvisa]

Since they're a great pair, you can find ilasm similarly at: https://www.nuget.org/packages/runtime.linux-x64.Microsoft.NETCore.ILAsm If you want an explicit version (like if you're fetching with curl) just suffix it: https://www.nuget.org/packages/runtime.linux-x64.Microsoft.NETCore.ILAsm/6.0.0

[glenn-slayden]

We did not bother to open source the Win32 UI.

Is that expected to be the permanent state-of-affairs? That GUI was horrible, but useful nevertheless.

[TIHan]

Since there are workarounds for this, I don't see this as a priority.

However, @ericstj mentioned it would only be some small effort to do. Who is the right person/team to handle adding new global tools to the dotnet command-line?

[ericstj]

The owners of those tools (ILAsm/ILDasm). Global tools can be built by anyone. This can be fixed with just the right packaging in the dotnet/runtime repo.

Adding things to the official dotnet cli is different -- that's the SDK. I'm not seeing that as part of the ask here.

[TIHan]

The owners of those tools (ILAsm/ILDasm)

Well, that would be me. 😅

Adding things to the official dotnet cli is different -- that's the SDK. I'm not seeing that as part of the ask here.

Sure, that makes sense. I wasn't familiar with how global tools work in correlation with the CLI, but I think I understand now.

This can be fixed with just the right packaging in the dotnet/runtime repo.

I'll spend some time on this next month as I do think it would be useful. I'll up the priority.

[JulieLeeMSFT]

We will not have time to do this in .NET9. Moving to .NET 10.