The SDK should include runtimes common native tools

[Petermarcu]

There are many tools that we had with .NET Framework's SDK that would be useful to also include in the .NET Core SDK. This list is not exhaustive and we can add to it but I have heard requests for each:

• fuslogvw (something to see assembly binding logging)
• ildasm
• ilasm
• crossgen

[Petermarcu]

@gkhanna79 @RussKeldorph

[gkhanna79]

ILAsm/ILDasm/Crossgen are native tools and bundling them would make CLI platform specific (as opposed to the portable app it is right now). Given that, are you suggesting CLI all possible flavors of it?

Something that I have suggested in the past is for CLI to restore the required tools, from the CoreCLR nuget packages, corresponding to the RID of the platform CLI is running on.

Also, what is the user story for carrying them? How are they being exposed via CLI or is the intent to simply carry them and let users figure it out? It will be great if you can elaborate on some of these @Petermarcu.

CC @livarcocc @eerhardt @bleroy

[dasMulli]

Global tools (via nuget) would come in handy here..

[Petermarcu]

The SDK is built for a specific arch/platform. It has to be because it crossgen's things in it. These would just be more platform specific native components.

[gkhanna79]

In that case, SDK should be able to extract the crossgen from CoreCLR package and use the corresponding ILAsm/ILDasm packages to get the respective binaries.

There is no FusLogVw equivalent in .NET Core - the corresponding approach is to use COREHOST_TRACE=1 that displays equivalent information.

[dasMulli]

These would just be more platform specific native components.

Those would be specific to the runtime that the SDK is built for, right? So i won't be able to crossgen a .net core 2.0 dll if i use an sdk that uses a 2.1.0-somthing runtime, with a released 2.0 runtime being installed as well.

[eerhardt]

Does ilasm and ildasm work on OSX and Linux?

[RussKeldorph]

@eerhardt Yes, though, some work is needed to clean up the packages. We're willing to do that work, though we could use help determining exactly what needs to happen to best integrate with the CLI.

Edit: "CLI" -> "CLI and/or SDK"

[gkhanna79]

So i won't be able to crossgen a .net core 2.0 dll if i use an sdk that uses a 2.1.0-somthing runtime, with a released 2.0 runtime being installed as well.

Our current design will allow this to work, though any enhancements that we may have made in precompilation process unique to 2.1.0 may not get recognized by 2.0 runtime, resulting in JITting of the code.

[livarcocc]

cc @richlander we need to figure out how we want to do this. For instance, should we just carry the executables and let the user figure out how to find it? Should we put all these native tools in a particular folder under the SDK folder? Should we add this to the PATH? As part of first run? Only for installers?

[omajid]

Also may be worth considering making these dotnet subcommands.

• dotnet ilasm
• dotnet crossgen

And so on.

[eerhardt]

I'll echo @dasMulli's excellent point above:

Global tools (via nuget) would come in handy here..

[natemcmaster]

Global tools (via nuget) would come in handy here..

+1 like 1000x. Trying to 🔮 a list of all tools users might want is like whacking at the branches of the problem; acquisition for dotnet commands is the root issue.

FYI - DotNetCliToolReference is so riddled with problems that I've given up on creating new dotnet subcommands.

[ViktorHofer]

csc, vbc, ilasm - https://github.com/dotnet/cli/issues/7689

[stevenaw]

I came across this issue while searching for a relatively out-of-the-box way to use ilasm/ildasm via cli on .net core. I see a few ideas were suggested in the past. What's the current recommendation on how a developer could do this?

[omajid]

I use dotnet tool install -g dotnet-ildasm which is https://github.com/pjbgf/dotnet-ildasm

Edit: just to be clear, this is not an official recommendation. Just a personal opinion.

[stevenaw]

Thanks @omajid I'll give that a try

[RussKeldorph]

@cshung

[mletterle]

I've had success with manually downloading the runtime nuget packages for ildasm/ilasm and CoreClr and making sure they're all in the same directory, and I know there's upcoming updates to remove the CoreClr requirement.. would really like to see a global tool for this, it's a little surprising that they're not included with the SDK honestly.