Open am11 opened 5 years ago
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?
With the current master, it seems to be building on Unix, e.g.:
we get coreclr/bin/Product/Linux.x64.Debug/ildasm
executable.
Ildasm (at least) is Windows specific right now
ildasm is not Windows specific. Did you mean to say platform specific?
@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?
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.
@jkotas ILVerify is the one in corert repo?Will be moved to new repo?
Yes, I think it would make sense. Opened https://github.com/dotnet/coreclr/issues/27939
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.
Moving this to 7.0.0 as I think we can meaningfully improve the customer experience here with small effort.
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.
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
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
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.
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?
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.
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.
We will not have time to do this in .NET9. Moving to .NET 10.
@amanasifkhalid, reassigned the ILAsm/ILDasm issue to you.
For example, acquisition and usage of https://www.nuget.org/packages/dotnet-format/ is quite simple:
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.